Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

« Honte à ceux qui promettent aux gens qu'ils vont devenir dev pro en quelques semaines »


Sujet :

Débats sur le développement - Le Best Of

  1. #141
    Membre éprouvé
    Citation Envoyé par zecreator Voir le message
    Je ne suis pas tout à fait d'accord. Oui, au début ceux sont les clients qui ont poussé à "standardiser" les méthodes de développement. Mais par la suite, ces méthodes sont devenues les seules acceptables sur le marché du travail car les SSII, étant les premiers employés dans l'informatique, ont fini par ne plus accepter que ça. Et cela a eu un effet "dévastateur" sur le métier de développeur et son apprentissage, car toutes les formations en développement se basent sur ces méthodes, considérant sans doute qu'il n'y aura pas de boulot de développement ailleurs qu'en SSII et que l'avenir d'un développeur est là-bas.

    Tous ces facteurs ont fait que le développeur est devenu un outil de production, ne se différenciant pas d'un autre développeur dans sa manière de travailler. On a perdu la passion du métier et sa créativité. Il existe un tas de développeurs talentueux qui ne peuvent plus bosser autrement qu'en indépendant, juste parce qu'ils ne rentrent pas dans le moule des SSII (et donc des clients), et ne trouvent pas de boulot.

    J'ai jamais bossé en SSII, par choix, car j'ai toujours refusé d'être figé dans telle ou telle techno, ou telle ou telle méthode. J'ai besoin d'avoir un espace de recherche, d'expérimentation et de création. Et je suis heureux de faire ce choix depuis 20 ans.
    Ca a l'air de te travailler, parce que ça fait plusieurs fois que tu reviens sur la même idée.
    Ca ne te gênerait pas qu'il n'y ait pas de méthodes un peu standardisées pour concevoir avions, automobiles, réacteurs nucléaires, lanceurs spatiaux, etc. ?
    Dès que les projets prennent de l'ampleur, ça me parait tout simplement nécessaire, et il est quand même un peu normal que le client qui paye cherche à limiter les risques d'échec.
    Il est bien évident que je ne vais pas faire de l'Agile tout seul dans mon coin pour mon logiciel (et mes clients se fichent de la méthode, je vends un produit, sans le code source, je ne suis pas prestataire), ma méthode maison marche bien pour un projet pas non plus énorme (tout au plus quelques centaines de milliers de lignes de code), mais si je devais embaucher 10 personnes, j'essaierais de me rapprocher de standards mieux adaptés à une montée en puissance, qui ont bien une raison d'être, SSII ou non.

  2. #142
    Expert éminent sénior
    Citation Envoyé par zecreator Voir le message
    Je ne suis pas tout à fait d'accord. Oui, au début ceux sont les clients qui ont poussé à "standardiser" les méthodes de développement. Mais par la suite, ces méthodes sont devenues les seules acceptables sur le marché du travail car les SSII, étant les premiers employés dans l'informatique, ont fini par ne plus accepter que ça. Et cela a eu un effet "dévastateur" sur le métier de développeur et son apprentissage, car toutes les formations en développement se basent sur ces méthodes, considérant sans doute qu'il n'y aura pas de boulot de développement ailleurs qu'en SSII et que l'avenir d'un développeur est là-bas.
    Oui, c'est la suite de mon raisonnement. Je ne l'avais pas terminé, mais je vais le faire, puisque tu insistes : quand les seules SSII sollicitées ont été celle qui offraient des méthodes standardisées(et donc inadaptées), fatalement, le système s'est sclérosé en leur faveur exclusive, éliminant du marché tout intervenant plus adaptatif. Mais ça a juste, à mon sens, été une conséquence. Au final, ce n'est pas le plus important.

    Citation Envoyé par zecreator Voir le message
    Tous ces facteurs ont fait que le développeur est devenu un outil de production, ne se différenciant pas d'un autre développeur dans sa manière de travailler. On a perdu la passion du métier et sa créativité. Il existe un tas de développeurs talentueux qui ne peuvent plus bosser autrement qu'en indépendant, juste parce qu'ils ne rentrent pas dans le moule des SSII (et donc des clients), et ne trouvent pas de boulot.
    L'âgisme joue beaucoup, à ce sujet, aussi. Mais oui, on a un conflit culturel permanent. Je l'ai subi quand j'étais prestataire, spécialement dans le milieu bancaire. Un bon informaticien est un créatif, par définition. Un banquier créatif est un mauvais banquier, par définition. Et le métier du banquier, c'est le pognon. Et le pognon n'existe quasiment plus que sous forme électronique. Donc les incompatibles sont obligés de s'entendre, et ça cartonne souvent. Dans ce milieu, c'est inévitable. Dans d'autres milieux, beaucoup moins. Mais les banquiers étant très puissants dans ce pays, ils ont fortement influençé les SSII et ont institutionnalisé le conflit. A leur détriment, mais ils ne le voient pas comme ça - ils ne voient que l'aspect maitrise des couts, sans se rendre compte que réduire les couts journaliers de 10% pour réduire l'efficacité de l'équipe de 50%, ça n'est pas très efficient.

    Citation Envoyé par zecreator Voir le message
    J'ai jamais bossé en SSII, par choix, car j'ai toujours refusé d'être figé dans telle ou telle techno, ou telle ou telle méthode. J'ai besoin d'avoir un espace de recherche, d'expérimentation et de création. Et je suis heureux de faire ce choix depuis 20 ans.
    Encore faut-il avoir le choix. Pour ce qui est des méthodes, paradoxalement, j'ai eu plus de libertés en régie. Ca m'a valu quelques engueulades, mais le boulot était fait. J'ai pu me permettre, suivant les clients, de bouffer à minima quelques heures, parfois quelques jours chez certains, pour faire avancer les choses. Liberté que je n'aurais pas eu en forfait ou chaque heure compte.

    Citation Envoyé par wolinn Voir le message
    Ca a l'air de te travailler, parce que ça fait plusieurs fois que tu reviens sur la même idée.
    Ca ne te gênerait pas qu'il n'y ait pas de méthodes un peu standardisées pour concevoir avions, automobiles, réacteurs nucléaires, lanceurs spatiaux, etc. ?
    Dès que les projets prennent de l'ampleur, ça me parait tout simplement nécessaire, et il est quand même un peu normal que le client qui paye cherche à limiter les risques d'échec.
    Il est bien évident que je ne vais pas faire de l'Agile tout seul dans mon coin pour mon logiciel (et mes clients se fichent de la méthode, je vends un produit, sans le code source, je ne suis pas prestataire), ma méthode maison marche bien pour un projet pas non plus énorme (tout au plus quelques centaines de milliers de lignes de code), mais si je devais embaucher 10 personnes, j'essaierais de me rapprocher de standards mieux adaptés à une montée en puissance, qui ont bien une raison d'être, SSII ou non.
    Le truc, c'est que le développement informatique, c'est de la R&D. Produire le code, c'est juste le compiler(l'exploitation, c'est autre chose, mais c'est hors sujet). La difficulté est de le concevoir. Alors que ton Airbus, même parfaitement conçu, reste une gageure à fabriquer(d'ou d'ailleurs les déboires de Tesla - Elon Musk n'a pas saisi que fabriquer, en automobile, c'est un métier en soi).

    Après, il y a les méthodes de gestion de projet, qui ne sont pas scandaleuses en soi. Mais il y a aussi des exigences techniques fortes sur le style qui peuvent être adaptées chez Pierre et catastrophiques chez Paul. C'est plus ça dont parle Zecreator, je crois. Il confirmera(ou me flambera si je n'ai rien compris).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #143
    Membre éprouvé
    Citation Envoyé par el_slapper Voir le message

    ...
    Le truc, c'est que le développement informatique, c'est de la R&D. Produire le code, c'est juste le compiler(l'exploitation, c'est autre chose, mais c'est hors sujet). La difficulté est de le concevoir. Alors que ton Airbus, même parfaitement conçu, reste une gageure à fabriquer(d'ou d'ailleurs les déboires de Tesla - Elon Musk n'a pas saisi que fabriquer, en automobile, c'est un métier en soi).
    ...
    Je ne parlais pas de fabrication/production, mais bien de conception. Concevoir un nouvel avion, c'est aussi de la R&D.

  4. #144
    Membre expert
    J'essaye surtout pas de m'abrutir avec des concepts qui n'ont rien à voir avec mon métier. Si o. Vient me dire qu'une erreur dans mon code peut mettre en danger des vies, alors c'est une trop grande responsabilité pour moi, je changerai de métier. Comparer le développement informatique avec de l'ingénierie aéronautique, c'est peut-être surestimer son métier. C'est comme comparer Mac Do avec Le Notre. En tant que développeur, je n'irai pas me comparer aux ingénieurs de la Nasa. Je connais mes limites.

    Pourquoi standardiser le développement informatique ? En quoi est-il nécessaire que tous les développeurs utilisent les mêmes outils et méthodes ? Pour rassurer un client ? Pour être plus productif ? Et si d'autres méthodes donnent le même e résultat, en quoi sont-elles à proscrire ?

    Que l'on m'explique pourquoi il y a 30 ans, on pouvait développer des systèmes IT avec juste la connaissance de la syntaxe d'un langage, alors qu'aujourd'hui personne n'est plus capable de coder sans frameworks et IDE.?
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  5. #145
    Expert confirmé
    Programmer en entreprise sans IDE ? Sérieusement ? zecreator, te passes-tu tout le temps d'IDE ? Si oui, pourquoi ?

    De mon côté, en C++ (par exemple), je sais programmer avec un éditeur de texte sans extensions et gérer la compilation avec un makefile, mais je ne vois pas l'intérêt de me restreindre à cela alors qu'un IDE m'offre des fonctionnalités bien pratiques comme passer directement d'un bout de code qui appelle une fonction vers le code qui définit cette fonction.

    En C et C++, obliger les étudiants à savoir programmer sans IDE, c'est bien pour essayer de les forcer à comprendre la chaîne de compilation. Mais, après, pourquoi se priver des avancées technologiques ?

    Par contre, quand je code un petit script, je n'utilise pas d'IDE. Notepad++ s'ouvre vite et convient bien.

  6. #146
    Membre éprouvé
    zecreator:
    Quand on voit l'importance prise par les logiciels partout, ce que tu écris me fait un peu peur. Même lorsqu'il n'y a pas de vies en jeu, les défaillances logicielles peuvent avoir des conséquences économiques lourdes.
    Dans ces conditions, il n'y a simplement plus de place pour les amateurs, et il est bien normal de chercher à standardiser les méthodes de travail et les outils, pour réduire les risques d'échec, tout en respectant des contraintes de productivité.
    Que ça plaise ou non, en 20-30 ans, le développement logiciel a évolué en une activité quasi-industrielle, avec ses méthodes, ses normes, ses outils, même si elle conserve quelques spécificités et que les pratiques ne sont peut-être pas aussi stabilisées que dans d'autres domaines.
    Mes clients sont essentiellement des industriels, mon logiciel est un petit rouage dans la chaine de conception, mais des erreurs de calcul peuvent coûter cher, induire des mois de retard dans la conception, qui se retrouvent à l'arrivée dans la production et ont donc un coût économique, ou même flanquer des projets par terre.
    Ce n'est jamais arrivé parce que je suis rigoureux, même si je me suis déjà fait quelques frayeurs, mais si j'embauchais pour développer à ma place, j'imposerais des gardes fous pour que cela ne se produise pas, ce qui implique des contraintes sur la gestion de projet et aussi à un niveau technique plus basique. Et comme je n'ai pas la science infuse, et que je n'ai jamais géré de projet impliquant plus de 5-6 développeurs, je penserais à me rapprocher des standards.
    Je ne sais pas ce que font les SSII, ni si elles le font bien en général, mais sur le principe, pour toutes ces raison, je ne suis pas spécialement choqué et attristé par l'évolution vers une standardisation des pratiques, étant donné que je ferais pareil si je recrutais.

  7. #147
    Membre expert
    Citation Envoyé par Pyramidev Voir le message
    Programmer en entreprise sans IDE ? Sérieusement ? zecreator, te passes-tu tout le temps d'IDE ? Si oui, pourquoi ?
    En fait, j'utilise parfois Eclipse (pour le dev Java surtout). Un peu Android Studio, mais surtout pour compiler mes PWA. Sinon, j'arrive très bien à faire mon métier avec Notepad++. Mes collègues utilisent également Sublime Text. Chacun ses goûts.

    Citation Envoyé par Pyramidev Voir le message
    En C et C++, obliger les étudiants à savoir programmer sans IDE, c'est bien pour essayer de les forcer à comprendre la chaîne de compilation. Mais, après, pourquoi se priver des avancées technologiques ?
    Comme me dit mon garagiste, un bon vieux mécano de 60 ans : "Aujourd'hui, sans ordinateur, les mecs ils ne sauraient même pas changer une courroie de distribution.". Les IDE et autres frameworks n'ont qu'une seul objectif : se focaliser sur la production, et laisser le reste aux process automatisés. L'homme étant faillible, je ne sais pas si c'est un mal, mais une chose est sûr, le développeur n'apprend plus rien et le métier se restreint à être sur un maillon de la chaîne de montage, sans avoir une vision de l'ensemble.

    Citation Envoyé par wolinn Voir le message
    zecreator:
    Quand on voit l'importance prise par les logiciels partout, ce que tu écris me fait un peu peur. Même lorsqu'il n'y a pas de vies en jeu, les défaillances logicielles peuvent avoir des conséquences économiques lourdes.
    Dans ces conditions, il n'y a simplement plus de place pour les amateurs, et il est bien normal de chercher à standardiser les méthodes de travail et les outils, pour réduire les risques d'échec, tout en respectant des contraintes de productivité.
    Que ça plaise ou non, en 20-30 ans, le développement logiciel a évolué en une activité quasi-industrielle, avec ses méthodes, ses normes, ses outils, même si elle conserve quelques spécificités et que les pratiques ne sont peut-être pas aussi stabilisées que dans d'autres domaines.
    Mes clients sont essentiellement des industriels, mon logiciel est un petit rouage dans la chaine de conception, mais des erreurs de calcul peuvent coûter cher, induire des mois de retard dans la conception, qui se retrouvent à l'arrivée dans la production et ont donc un coût économique, ou même flanquer des projets par terre.
    Ce n'est jamais arrivé parce que je suis rigoureux, même si je me suis déjà fait quelques frayeurs, mais si j'embauchais pour développer à ma place, j'imposerais des gardes fous pour que cela ne se produise pas, ce qui implique des contraintes sur la gestion de projet et aussi à un niveau technique plus basique. Et comme je n'ai pas la science infuse, et que je n'ai jamais géré de projet impliquant plus de 5-6 développeurs, je penserais à me rapprocher des standards.
    Je ne sais pas ce que font les SSII, ni si elles le font bien en général, mais sur le principe, pour toutes ces raison, je ne suis pas spécialement choqué et attristé par l'évolution vers une standardisation des pratiques, étant donné que je ferais pareil si je recrutais.
    C'est pas possible que tu es choisi ce métier par passion. Aucun développeur passionné ne peut accepter de travailler dans de telles conditions et avoir des propos aussi tristes sur le métier. Au moins de n'avoir connu que ce système ou d'avoir un GROS salaire, je ne comprends pas comment on peut être développeur "à la chaîne". Où est l'intérêt ? Quel épanouissement perso cela t'apporte ? Tu pourrais avoir les mêmes mots pour un automatique chez Renault.

    C'est franchement triste.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  8. #148
    Membre expert
    En fait, il faut différencier l'artisant qui fait le produit de A à Z avec ses propres outils, et le même produit fabriqué de manière industrielle. Moi, je serai plutôt un développeur "artisant", qu'un développeur sur "chaîne de production".
    Malheureusement, on voit comment finissent beaucoup d'artisans, face à l'industrie.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  9. #149
    Membre expert
    Ce message n'a pas pu être affiché car il comporte des erreurs.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  10. #150
    Membre éprouvé
    Citation Envoyé par zecreator Voir le message

    ...
    C'est pas possible que tu es choisi ce métier par passion. Aucun développeur passionné ne peut accepter de travailler dans de telles conditions et avoir des propos aussi tristes sur le métier. Au moins de n'avoir connu que ce système ou d'avoir un GROS salaire, je ne comprends pas comment on peut être développeur "à la chaîne". Où est l'intérêt ? Quel épanouissement perso cela t'apporte ? Tu pourrais avoir les mêmes mots pour un automatique chez Renault.
    Je suis ingénieur par vocation, et en activité depuis 25 ans. Et j'ai un peu évolué depuis 1990, je ne suis plus un geek prenant son pieds juste en écrivant des lignes de code et en faisant un peu ce qu'il veut en jouant les divas, ce stade est dépassé depuis longtemps.
    De plus, ma valeur ajoutée est surtout dans l'analyse physique et l'algorithmique.
    Ma satisfaction est de voir des projets qui aboutissent chez mes clients grâce au logiciel que je leur fournis.
    C'est même plus large que ça. Si la fusion nucléaire marche un jour, j'y aurais apporté ma petite brique, en simulation. Lorsque les véhicules autonomes rouleront, j'y aurais aussi participé, à ma modeste échelle, également en simulation.

    Citation Envoyé par zecreator Voir le message

    ...
    Je ne sais pas de quel genre de clients tu parles, mais si tu acceptes, en tant qu'expert, que ce soit le client qui te dicte comment bosser, alors il n'a pas besoin de toi. Change de client ou change de métier. Un client peut avoir des exigences en termes de sécurité et maintenance, c'est normal, mais en aucun cas il ne peut t'expliquer comment bosser.
    ...
    Relis attentivement ce que j'ai écrit. Mes clients ne me dictent pas ma façon de travailler. En logiciel, je ne suis pas prestataire, je vends un produit standard fini, les clients se fichent des méthodes de développement utilisées, ça n'intéresse personne, et je reste toujours propriétaire du code source.
    J'ai tout au plus parfois des demandes d'éclaircissement sur l'analyse physique, l'algorithmique, et la façon dont les résultats produits par le logiciel ont été validés.
    Par contre, il y a des obligations de fiabilité, qui font que si je devais gérer des projets plus importants, je réévaluerais sérieusement mes pratiques pour me rapprocher de standards dans les méthodes de développements. Ce n'est pas une demande explicite des clients, j'ai simplement conscience des limites de mes méthodes actuelles un peu hors normes.

    Pas trop le temps de réponde au reste, mais il y a aussi des points sur lesquels je suis d'accord.
    Pour finir, si tu as suivi, tu auras compris que je suis aussi un artisan

  11. #151
    Membre extrêmement actif
    Citation Envoyé par zecreator Voir le message
    J'essaye surtout pas de m'abrutir avec des concepts qui n'ont rien à voir avec mon métier. Si o. Vient me dire qu'une erreur dans mon code peut mettre en danger des vies, alors c'est une trop grande responsabilité pour moi, je changerai de métier. Comparer le développement informatique avec de l'ingénierie aéronautique, c'est peut-être surestimer son métier. C'est comme comparer Mac Do avec Le Notre. En tant que développeur, je n'irai pas me comparer aux ingénieurs de la Nasa. Je connais mes limites.

    Pourquoi standardiser le développement informatique ? En quoi est-il nécessaire que tous les développeurs utilisent les mêmes outils et méthodes ? Pour rassurer un client ? Pour être plus productif ? Et si d'autres méthodes donnent le même résultat, en quoi sont-elles à proscrire ?

    Que l'on m'explique pourquoi il y a 30 ans, on pouvait développer des systèmes IT avec juste la connaissance de la syntaxe d'un langage, alors qu'aujourd'hui personne n'est plus capable de coder sans frameworks et IDE.?
    on utilisait déjà des IDE il y a 30 ans (plus exactement 20 ans): Visual Basic, Visual FoxPro, Turbo Pascal, VisualAge et j'en passe. Et des frameworks, que cela soit ATL ou MFC.
    Aujourd'hui les linuxiens utilisent encore des vim et nano pour leurs code C et C++. Et automake.

    Donc la chaîne de compilation voir de développement est standardisée.

    On va utiliser le même IDE et si possible la même version car la simple ouverture ou compilation du projet par cet IDE peut être comprise dans le cas contraire. Si d'autres méthodes donnent le même résultat, elles sont dépendantes du développeur et donc on court le risque que personne ne puisse ouvrir ou reprendre ton projet, en tout cas à court terme.
    Imaginons que tu partes en vacances et sois enlevé par des martiens finissant leur mémoire d'anatomie comparé pour septembre, et bien ton code ne pourra pas être repris rapidement. Et en général quand le code d'un tiers doit être repris rapidement, c'est qu'il y a un souci en production. Et il n'est pas toujours simple d'expliquer au client final ou à la direction qu'on a perdu 3 jours parce que l'on ne sait pas compiler le projet en question.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  12. #152
    Expert confirmé
    Citation Envoyé par ddoumeche Voir le message
    on utilisait déjà des IDE il y a 30 ans (plus exactement 20 ans): Visual Basic, Visual FoxPro, Turbo Pascal, VisualAge et j'en passe.
    En fait, smalltalk avait déjà un IDE, il y a 40 ans...

    Citation Envoyé par ddoumeche Voir le message

    Aujourd'hui les linuxiens utilisent encore des vim et nano pour leurs code C et C++. Et automake.
    Tu as appris à dire n'importe quoi en autodidacte ou tu as un diplôme pour ça ?

    Citation Envoyé par ddoumeche Voir le message

    On va utiliser le même IDE et si possible la même version car la simple ouverture ou compilation du projet par cet IDE peut être comprise dans le cas contraire. Si d'autres méthodes donnent le même résultat, elles sont dépendantes du développeur et donc on court le risque que personne ne puisse ouvrir ou reprendre ton projet, en tout cas à court terme...
    Une méthode de développement ne se résume pas à une partie des outils qui permettent de l'appliquer.

  13. #153
    Membre extrêmement actif
    Citation Envoyé par SimonDecoline Voir le message
    En fait, smalltalk avait déjà un IDE, il y a 40 ans...
    Mais VisualAge était un IDE pour smalltalk.

    Citation Envoyé par SimonDecoline Voir le message


    Tu as appris à dire n'importe quoi en autodidacte ou tu as un diplôme pour ça ?
    J'ai un diplôme (bidon bien sur), et de l'expérience, en plus d'avoir roulé ma bosse et travaillé avec de multiples développeurs dont pas mal dans l'embarqué. Ce qui n'est pas donné à tout le monde j'en conviens.
    Tu n'as sans doute jamais fais de développement Linux avec des IDE ni avec vim à contrario ?

    Ici par exemple un développeur C++ de chez VMWare expliquant comment leur software est codé avec vim : https://www.reddit.com/r/vim/comment...mp;sh=bab56a69
    Mais bon qu'est-ce que VMWare hormis un petit freeware, n'est ce pas.


    Citation Envoyé par SimonDecoline Voir le message
    Une méthode de développement ne se résume pas à une partie des outils qui permettent de l'appliquer.
    Quelle agressivité. Tu devrais plutôt nous apprendre des choses qu'on ne sache pas encore.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  14. #154
    Membre expert
    Je vois les IDE comme des outils utiles, mais pas indispensables à partir du moment où l'(on est capables de développer sans. Et c'est bien là le problème, c'est que le développeur d'aujourd'hui n'a plus à connaitre les chaines de compilation, tout est automatisés par les IDE. pareil, qui est capables aujourd'hui de coder sans déboggeur ?

    Je suis toujours impressionné par les démomakers qui continue aujourd'hui à coder sur Amstrad ou Amiga, avec juste un éditeur ASM extrêmement dépouillé de fonctionnalités, et qui arrivent tout de même à produire des merveilles. Le développeur VS ou Eclipse peut-il en faire autant ? Et j'entends déjà la réponse : "Pourquoi faire ?". Juste pour votre culture perso en développement déjà. Savoir qu'avant tous vos outils, il n'y avait rien et qu'il fallait bien coder tout de même. Et aussi, pour que mes collègues pro-frameworks cessent de m'appeler pour débloquer leurs erreurs parce que leurs outils sont plombés d'erreurs et d'incohérences de conception, et qu'ils sont incapables de comprendre leur code.

    Etre développeur, c'est un peu plus que savoir maîtriser des outils pour être plus productif. C'est aussi être curieux de toutes les manières de développer, des autres technologies (développeurs J2EE, c'est pour vous ça). Sortez un peu le nez de votre "chaîne de montage" et vous vous apercevrez qu'il y a d'autres mondes dans le développement que ce que vous avez toujours connus, et c'est BIEN.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  15. #155
    Expert confirmé
    Citation Envoyé par ddoumeche Voir le message
    Mais VisualAge était un IDE pour smalltalk.
    Visual Age était un IDE écrit en smalltalk mais utilisable pour différents langages.

    Citation Envoyé par ddoumeche Voir le message

    Ici par exemple un développeur C++ de chez VMWare expliquant comment leur software est codé avec vim : https://www.reddit.com/r/vim/comment...mp;sh=bab56a69
    C'est effectivement une preuve irréfutable que "les linuxiens utilisent encore des vim et nano pour leurs code C et C++". D'ailleurs c'est bien connu que eclipse, netbeans, qtcreator, clion, code-blocks et autres n'existent pas sous linux... c'est bien la preuve que "les linuxiens" n'utilisent pas d'IDE.

  16. #156
    Expert éminent sénior
    Citation Envoyé par zecreator Voir le message

    Je suis toujours impressionné par les démomakers qui continue aujourd'hui à coder sur Amstrad ou Amiga, avec juste un éditeur ASM extrêmement dépouillé de fonctionnalités, et qui arrivent tout de même à produire des merveilles. Le développeur VS ou Eclipse peut-il en faire autant ? Et j'entends déjà la réponse : "Pourquoi faire ?". Juste pour votre culture perso en développement déjà. Savoir qu'avant tous vos outils, il n'y avait rien et qu'il fallait bien coder tout de même. Et aussi, pour que mes collègues pro-frameworks cessent de m'appeler pour débloquer leurs erreurs parce que leurs outils sont plombés d'erreurs et d'incohérences de conception, et qu'ils sont incapables de comprendre leur code.
    Amstrad, Amiga, toute ma jeunesse... et ce qui m'a donné envie de faire de l'informatique (dans sa plus pure définition: théorie,hardware,code,...)
    Cordialement.

  17. #157
    Membre émérite
    Citation Envoyé par ddoumeche Voir le message
    Aujourd'hui les linuxiens utilisent encore des vim et nano pour leurs code C et C++. Et automake.
    On ne peut pas trop dire ca sans donner de chiffres. Je suis d'accord avec Simon sur le fait que balancer ca comme ca n'est pas assez rigoureux.

    Pour info, vu que j'ai les downloads stats d'Eclipse IDE sous la main:
    * Eclipse IDE for C++ developers represent en tout 10% des telechargements d'Eclipse IDE.
    * On estime entre 4 et 6 millions le nombre d'utilisateurs reguliers d'Eclipse IDE; donc on peut estimer entre 400,000 et 600.000 le nombre d'utilisateurs reguliers d'Eclipse IDE for C++ developers.
    * Eclipse IDE, en general, c'est dans les 10% de telechargements sous Linux; or pour Eclipse IDE for C++ developers c'est 25% (linux est plus populaire); donc on peut estimer entre 100.000 et 150.000 le nombre d'utilisateurs reguliers d'Eclipse IDE for C++ developers sur Linux.
    * On estime a 35.000 (5.000 en direct download du zip + 30.000 par l'installer) le nombre de telechargement de Eclipse IDE for C++ developpeurs entre le 27 juin et aujourd'hui; ca ne compte pas les mises a jours ni les utilisateurs qui n'ont pas migres.
    Et si a ca, tu ajoutes les autres IDEs listes par Simon et d'autres encore (pour lesquels je n'ai pas acces a des stats assez fines), je pense qu'on peut etre pas loin du million, voire de 2. Ce qui je pense est assez massif pour ne pas permettre de laisser passer ce genre de commentaire trop facilement
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  18. #158
    Membre extrêmement actif
    Ce message n'a pas pu être affiché car il comporte des erreurs.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  19. #159
    Membre éprouvé
    Citation Envoyé par zecreator Voir le message
    Je vois les IDE comme des outils utiles, mais pas indispensables à partir du moment où l'(on est capables de développer sans. Et c'est bien là le problème, c'est que le développeur d'aujourd'hui n'a plus à connaitre les chaines de compilation, tout est automatisés par les IDE. pareil, qui est capables aujourd'hui de coder sans déboggeur ?

    Je suis toujours impressionné par les démomakers qui continue aujourd'hui à coder sur Amstrad ou Amiga, avec juste un éditeur ASM extrêmement dépouillé de fonctionnalités, et qui arrivent tout de même à produire des merveilles. Le développeur VS ou Eclipse peut-il en faire autant ? Et j'entends déjà la réponse : "Pourquoi faire ?". Juste pour votre culture perso en développement déjà. Savoir qu'avant tous vos outils, il n'y avait rien et qu'il fallait bien coder tout de même. Et aussi, pour que mes collègues pro-frameworks cessent de m'appeler pour débloquer leurs erreurs parce que leurs outils sont plombés d'erreurs et d'incohérences de conception, et qu'ils sont incapables de comprendre leur code.

    Etre développeur, c'est un peu plus que savoir maîtriser des outils pour être plus productif. C'est aussi être curieux de toutes les manières de développer, des autres technologies (développeurs J2EE, c'est pour vous ça). Sortez un peu le nez de votre "chaîne de montage" et vous vous apercevrez qu'il y a d'autres mondes dans le développement que ce que vous avez toujours connus, et c'est BIEN.
    J'ai longtemps utilisé un déboggeur, mais depuis quelques années, j'ai quasiment abandonné cet outil. Maintenant, je tends à considérer que c'est un outil utilisé abusivement par des débutants et programmeurs peu rigoureux, et que le recours fréquent à un déboggeur signale un problème dans le processus de développement. Cet outil a bien sa place dans l'environnement de développement, mais y recourir devrait être exceptionnel.
    Pour ce qui est de l'IDE, je sais bien ce qu'il y a en dessous, et j'ai écrit mes premiers programmes à la fin des années 70, avant que ça existe.
    Là, par contre, dans mon contexte, il ne me viendrait pas à l'idée de m'en passer, étant donné le gain de productivité apporté.

    Pour le reste, je suppose (mais n'en suis pas certain, c'est vrai), que les plus jeunes, en niveau ingénieur, entendent parler des couches inférieures pendant leur formation, pour la culture générale, et se dépêchent ensuite d'oublier, pour se concentrer sur ce qui est vraiment utile aujourd'hui dans la plupart des situations.

  20. #160
    Membre émérite
    Citation Envoyé par ddoumeche Voir le message
    Vous sortez une phrase de son contexte
    Pas vraiment. Je pense juste qu'on a ete touches par le manque de rigueur de la phrase qui semblait trop absolue dans un monde tres relatif. Tu aurais dis "De nombreux linuxiens utilisent encore principalement Vim et Nano pour faire du dev C ou C++", on aurait pas reagi. Mais juste ignorer 1 a 2 millions de developpeurs qui font du C++ sous Linux avec un IDE, c'est pas vraiment acceptable dans un debat. Donc on vient porter cette voix de 1 a 2 millions de developpeurs.

    ...de mon équipe...
    Voila un gros biais de vision du marche.
    Le monde est infiniment plus grand qu'un individu, qu'une equipe ou qu'une entreprise. On ne peut en rien inferer de la popularite ou des tendances a partir d'une equipe. Faire ca c'est clairement s'exposer a de mauvaises conclusions. Des nombres et des stats fiables (ie pas base sur des sondages qui ne touchent qu'une infime partie de l'ecosysteme) sont la seule source sure; sans ca, il vaut mieux ne meme pas chercher a tirer la moindre idee generale.
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter