Les programmeurs savent-ils encore développer avec un éditeur de texte ?

Les programmeurs savent-ils encore écrire un code avec un éditeur de texte ?
Certains ingénieurs stars de Microsoft pensent que non et le regrette fortement


Les programmeurs "stars" de Microsoft préfèrent les anciennes méthodes pour écrire leurs codes. Ces superstars ne quitteraient pour rien au monde leur éditeur de texte.

Don Box par exemple, qui travaille aujourd'hui sur la programmation déclarative, avoue avec humour qu'il serait "prêt à tuer" si on l'empêchait de travailler avec cet outil.


http://www.microsoft.com/presspass/i...de/Box_bio.jpg


Il comprend que la nouvelle génération de programmeur veuille des outils graphiques. Il explique cependant qu'il n'a pas grandi avec eux et que ces habitudes sont donc toutes différentes. Il va plus loin : si les programmeurs ne savent plus faire leur travail avec un éditeur, alors la profession serait en danger.

Jeffrey Snover va plus loin. Beaucoup plus loin.


http://www.microsoft.com/presspass/i...Snover_bio.jpg


Jeffrey Snover est le créateur de PowerShell, "un interpréteur de commandes et un langage de script pour l'administration des systèmes, développé sur .NET Framework, qui permet aux informaticiens de contrôler et d'automatiser l'administration de Windows et des applications".

Pour lui, les environnements graphiques de programmation ne servent à rien. Ou plus exactement, ils deviennent inutiles quand on en aurait le plus besoin. "Quand vous avez 5 trucs à gérer, l'environnement graphique fonctionne", admet-il dans une interview lors du PDC, "mais quand vous en avez 500, vous n'arrêtez plus de zoomer puis de dé-zoomer. Vous ne savez plus ce que vous faites. Pour moi, ce sont des écrans de fumée".

Pourtant Microsoft est fortement impliqué dans les VPL (Visual Programming Language) notamment avec MVPL. Qu'à cela ne tienne : les langages graphiques ne sont pas plébiscités en interne par ces super-stars, comme ButlerW. Lampson.


http://research.microsoft.com/en-us/...n/Image115.gif


Butler W. Lampson est le lauréat du Association for Computing Machinery's A.M. Turing Award 1992 et le co-auteur de 9 langages de programmation.

Pour lui, si les environnements graphiques permettent d'apprendre plus vite, ils permettraient surtout d'apprendre "à se mentir" (sic) : "personne ne peut jamais vous dire ce que signifie un diagramme UML !", rigole-t-il.

Et tous de prédire un retour en force de l'éditeur de texte selon la bonne vieille loi des cycles de mode qui stipule que ce qui est démodé aujourd'hui sera la tendance de demain.

Lire aussi

:fleche: Le pire bout de code que vous ayez vu : Qui l'a fait ? Pourquoi ? Pourquoi était-il si horrible ?
:fleche: Souhaiteriez-vous reprogrammer en C/C++ après des années d'utilisation de .NET/C# et Java ? Pour ou contre le low level ?

Les rubriques (actu, forum, tutos) de Développez.com
:fleche: .NET
:fleche: Langages
:fleche: Conception
:fleche: Développement Web


Et vous ?

:fleche: Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?
:fleche: Pour vous, n'est-on programmeur que si l'on sait développer avec un éditeur de texte ?

Citation:

---

Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?

---

Un développeur qui ne sait pas ce qui est fait derrière va droit au mur, ex : mon collègue qui sait pas faire une requête SQL sans le générateur de requête de SSMS ==> perf de merde a souhait.

Citation:

---

Pour vous, n'est-on programmeur que si l'on sait développer avec un éditeur de texte ?

---

Non, ces outils aident a la productivité si comme j'ai dit avant, on sait ce qui est généré derrière : par exemple pour créer des interface desktop c'est utlra chiant de faire que compiler / modifier le code pour caller au pixel pres le cadre ou on doit entrer un texte.


Personnellement je déteste la plupart de ces outils et ils sont en général source a des problème de perf et de maintenabilité Ex : Dreamwaver, la pire bouse de l'humanité depuis celle d'un mammouth qui parait il faisait 500 tonnes, le rendu est acceptable mais le code source est pire que tout et au final on est dépendant de l'éditeur graphique car quand on veut aller voir le code (ce qui arrive tout le temps si on fait une appli particulière) on en a des boutons.

Ces outils c'est le grand truc des conférence microsoft : "Regardez je fait une appli en 5 drag n drop, genial la techno non ?" et ben non en fait.

De manière générale un développeur doit toujours savoir ce qui se passe dans son appli, au niveau les plus bas possible , un développeur qui ne connait rien a l'assembleur va avoir du mal a comprendre la notion de handler en programmation objet et fera toujour des return d'objet qui sont en paramètre par exemple.

Citation:

---

si les programmeurs ne savent plus faire leur travail avec un éditeur, alors la profession serait en danger.

---

Tout est dit :ccool:

Si un programmeur ne sais pas ce qu'il se passe quand il clic sur "compiler", alors on va droit dans un mur. Quid de la mémoire ? de l'ASM ? ...

Après, les environnements graphiques permettent une bien meilleur ergonomie et au final, des gains de productivité...

Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?
Je suis partagé. D'un coté, cela permet de gagner du temps. Mais un développeur doit connaitre ce qu'il se passe "derrière".

Pour vous, n'est-on programmeur que si l'on sait développer avec un éditeur de texte ?
Les environnements visuelles ne sont intéressant que pour les gains de productivité qu'ils amènent. Mais un bon programmeur doit pouvoir se passer de ce genre d'outils. J'ai utilisé il y a quelques années un éditeur graphique pour créer des interfaces Swing...Le code généré était affreux, et la ré-écriture était souvent obligé...
De même pour des outils comme Dreamweaver...Obligé de mettre le nez dans le HTML pour supprimer le superflus.


Pour ma part, selon les langages, j'utilise ou pas ces environnements visuels.
Pour du web, un simple editeur de texte, style Notepad++ (pour la coloration syntaxique...au moins), me suffit.

Pour des applis Desktop, j'aime utiliser VS pour générer rapidement une maquette de l'interface. Mais je préfère la coder moi-même après. De cette manière, le code est mieux organisé et plus facilement maintenable.

Moi je suis pour le bête éditeur de texte basique, genre vim :mrgreen:
Avec la coloration syntaxique c'est tout de même propre...
Mais bon je ne fais pas de java et j'imagine que gérer un projet java sous vim doit être moins évident que sous eclipse !!! 8O
Et en effet, la contrepartie c'est qu'au bout d'un moment, sans ton interface graphique, tu ne sais même plus ce qu'il faut mettre en tête d'un script pour qu'il fonctionne !!!

Don Box : Ce qui met la profession en danger c'est SOAP dont il est à l'origine plutôt que les outils graphiques.

Jeffrey Snover : il a créé un shell (avec 20 ans de retard), que sait-il du développement ? Qui gère 500 trucs à la fois ? Une pieuvre ? Quelqu'un qui ne sait pas s'organiser ? Obiwan Kenobi ?

Butler W. Lampson : (66 ans quand même...). Superbe exemple que celui d'UML... Que préconise-t-il alors pour faire de l'UML ? le papier ? Peut-être le problème vient-il d'UML, non ?

Le retour de l'éditeur de texte... ben voyons. Ce n'est pas parce que les outils graphiques de Microsoft sont tous plus nuls les uns que les autres qu'il faut généralisé à l'ensemble du marché.

Ils sont bien beaux tous ces "chercheurs" et "experts" mais il y a un truc qui s'appelle la productivité, dans la vrai vie c'est important. Et puis, même si j'apprécie les éditeurs de texte, pour atteindre la même productivité que les outils graphiques modernes (si tant est que cela soit possible) il faut bien 20 ans de manipulation de la configuration de l'éditeur.

Bonjour, je ne suis pas un développeur ayant 15 ans d'expérience, à vrai dire 6/7 et pourtant je préfère amplement taper mon code java sous eclipse (même pour du swing si! si!).

Attention je ne suis pas contre l'ergonomie, je suis tout à fait pour les scripts et les assistants permettant par exemple de générer des" beans entity" à partir d'un SGBD plutôt que de tout retaper à la mano ou permettant de faire un projet JEE vierge pré-configuré.

S'il est vrai qu'utiliser des outils graphiques afin de développer peut être parfois plus rapide, je constate également que le code généré ressemble souvent à une bonne usine à gaz et la maintenance n'est pas toujours évidente (J'avoue que netbean sort son épingle du jeu concernant les Wysiwyg).

Un exemple tout bête, quand j'ai commencé le développement WEB il y a qq années en arrière (7 ans) j'utilisais le grand et magnifique FRONT PAGE (Beurk)
qui faisait un code tout à fait exécutable sur IE et IIS, mais quand je regardais le code généré: "Ouch!" à n'y rien comprendre... et c'est précisément où je veux en venir: Beaucoup de développeurs adorent le graphique, mais s'ils ne sont pas capable de pouvoir développer en ligne de code, je pense que leur compréhension du langage ne sera pas bonne, voir inexistante s'ils ne se donnent pas la peine de regarder le code que produit l'AGL.

Bon je prends comme exemple l'HTML, ce n'est pas un langage de programmation me direz-vous...Bon il fallait bien commencer par quelque chose et le QBasic (mes premiers pas dans le développement) n'avait pas d'outils de développement graphique

Cependant étant maintenant un développeur NTIC (Java, php...) j'avais constaté la même chose pendant mon année de licence entre les étudiants qui faisaient leurs IHM avec Swing en ligne de code et ceux qui utilisaient des outils graphiques.
Résultat: à la main zéro problème d'affichage quand on redimensionnait la fenêtre alors qu'en graphique, les étudiants (ne sachant pas utiliser correctement les différents Grid, GridBagLayout et j'en passe) pour palier au problème d'affichage faisaient un taille fixe inchangeable...

Enfin, voici juste mon opinion...

Pour moi si un programmeur ne sait pas ce qui se passe quand il clique sur "compiler" ben c'est pas un programmeur...

Enfin bon c'est bien pratique un IDE pour faire des applications fenêtrées, encore que maintenant avec WPF c'est du XAML donc plus besoin d'IDE ;)

Ou alors juste VIm :p (troll inside)

Citation:

---

Don Box : Ce qui met la profession en danger c'est SOAP dont il est à l'origine plutôt que les outils graphiques.

---

SOAP met en danger notre profession ? Sans SOAP je passerai la moitié de ma journée à rien faire ^^ Tu peux développer stp ? (même si c'est pas le débat ça peut intéresser).

Citation:

---

Envoyé par Bourgui

Code:

---

Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?

---

Un développeur qui ne sait pas ce qui est fait derrière va droit au mur, ex : mon collègue qui sait pas faire une requête SQL sans le générateur de requête de SSMS ==> perf de merde a souhait.

Code:

---

1 2	Pour vous, n'est-on programmeur que si l'on sait développer avec un éditeur de texte ?

---

Non, ces outils aident a la productivité si comme j'ai dit avant, on sait ce qui est généré derrière : par exemple pour créer des interface desktop c'est utlra chiant de faire que compiler / modifier le code pour caller au pixel pres le cadre ou on doit entrer un texte.


Personnellement je déteste la plupart de ces outils et ils sont en général source a des problème de perf et de maintenabilité Ex : Dreamwaver, la pire bouse de l'humanité depuis celle d'un mammouth qui parait il faisait 500 tonnes, le rendu est acceptable mais le code source est pire que tout et au final on est dépendant de l'éditeur graphique car quand on veut aller voir le code (ce qui arrive tout le temps si on fait une appli particulière) on en a des boutons.

Ces outils c'est le grand truc des conférence microsoft : "Regardez je fait une appli en 5 drag n drop, genial la techno non ?" et ben non en fait.

De manière générale un développeur doit toujours savoir ce qui se passe dans son appli, au niveau les plus bas possible , un développeur qui ne connait rien a l'assembleur va avoir du mal a comprendre la notion de handler en programmation objet et fera toujour des return d'objet qui sont en paramètre par exemple.

---

:ccool:

Citation:

---

Envoyé par chriscoolletoubibe

S'il est vrai qu'utiliser des outils graphiques afin de développer peut être parfois plus rapide, je constate également que le code généré ressemble souvent à une bonne usine à gaz et la maintenance n'est pas toujours évidente (J'avoue que netbean sort son épingle du jeu concernant les Wysiwyg).

---

:ccool:


Tout est dit de mon opinion dans ces 2 posts...

Citation:

---

Envoyé par Bourgui

SOAP met en danger notre profession ? Sans SOAP je passerai la moitié de ma journée à rien faire ^^ Tu peut développer stp ? (même si c'est pas le débat ça peut intéresser).

---

Bah vu que c'est un standard respecté par personne de la même manière, qui est très en retrait en termes de performances et qui est utilisé 90% du temps parce que c'est hype et pas parce que c'est justifié comparé à d'autres protocoles plus légers et plus interopérables.

Mais c'est pas le débat :-)

parait qu'ils vont sortir un package Vi avec un code pour se pendre. :ccool:

bref c'est comme la scarification et autre auto-mutilation c'est réservé aux ados qui se cherchent... mince ils n'ont pas l'air d'ados sur les photos. :aie:

:dehors:

J'ai oublié mon point de vue sur UML:
Je m'en sert toujours pour une nouvelle application quelque soit la taille.
essentiellement du Usecase, pour être sure de rien oublier
et des DCA et DCC. Pour le développement objet cela me parait indispensable.

Bon après bien sure s'il s'agit de modifier une application juste pour ajouter une fonction à deux sous... c'est pas forcement utile.
Mais pour une application de gestion type ERP, je demande à voir le résultat d'une personne qui à négliger l'analyse.

Si 7 ans en arrière nous avions demander à un type de faire un logiciel de gestion utilisant un base de données... il aurait à coup sûre fait une analyse en merise (mcd, etc...)

Je ne vois pas pourquoi les "vieux de la profession" (désolé j'avais presque envie de mettre "root's" à la place de vieux) qui ne comprennent pas l'objet critique à tout va les diagrammes uml...

Citation:

---

Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?

---

Tout dépend du comment on utilise ce genre d'outils: si on l'utilise comme d'un assistant ou si on l'utilise pour faire ce que l'on ne sait pas faire.

Personnellement j'utilise Dreamweaver car il m'aide à naviguer plus rapidement dans mon code. Mais je tape intégralement mon html, css, php ... car c'est vrai que le code généré est loin d'être optimisé.

C'est vrai aussi qu'ils ont raison d'une part car le sens du mot codeur tend à perdre sens. Avec les editeurs graphiques comme netbean ou VS on a tendance à confondre un developpeur à un dessinateur.

D'autre part, nous sommes dans un monde pressé,ou le temps et le resultat compte beaucoup. Dans une entreprise on a rarement besoin la qualité du code mais plutot la qualité du resultat. Le client s'enfou de ce qui se trouve derriere l'ecran mais plutot que son besoin est satisfait. D'ou la necessité des environnement graphiques avec completion.


Je me rappelle tres bien que j'ai developpé mon premier siteweb avec bloc note et appris à le langage C++ avec kwrite de ubuntu. Je remarque labas le manque de productivité. Certe le code est bien structuré mais le resultat n'est pas satisfaisant.

Alors je reviens alors à poser une question: Que preferez vous entre la qualité du code avec un mois de durée de travail et le resultat avec une semaine de durée?

SIDIBE Ali-Broma

[MODE FRANCIS CABREL]
C'étAIt mIeux Avant
[/MODE FRANCIS CABREL]
:mouarf:

Citation:

---

Envoyé par luxifer

Enfin bon c'est bien pratique un IDE pour faire des applications fenêtrées, encore que maintenant avec WPF c'est du XAML donc plus besoin d'IDE ;)

---

Il ne faut pas confondre IDE et RAD. Et premier est rarement nuisible, pratique voir indispensable pour éviter la multiplication des fenêtres (éditeur de texte, console, aide, ...), le second est beaucoup plus discutable.

Bonjour,

Désolé mais pour moi les gars de Microsoft c'est pas trop une référence...

Pour ma part j'ai découvert la programmation en cours via emacs et cie, et c'est vrai que pour comprendre ce qu'il se passe derrière c'est le mieux.
Par contre quand le projet commence à devenir important, Eclipse je ne pourrai pas m'en passer.
Et je pense que la puissance d'un tel outil est justement que le code n'est pas caché, à tout moment on y a accès. Là où un tel outil est indispensable à mon sens, c'est pour compiler le code, gérer des builds, importer des paquets, tout cela rapidement.

Du coup je pense que pour apprendre à bien coder il faut mettre la main à la pate (avec un éditeur) mais ensuite il faut savoir se faire aider afin de gagner du temps et de la productivité.

50% de mes développements faits sous vi, le reste, dans un éditeur de texte classique (pspad)

Ca se résume à ça et c'est au combien suffisant !

Pour une petite boutique je fais une application en quelques jours, pas besoin de coder toutes les interfaces "à mains nues". Mais pour une applic d'un grand restaurant qui tourne sur terminal de vente POS à ecran tactile, je prend le soin de coder de bonnes interfaces conviviales.

Il faut bien dans certains cas aller rapidement. Mais connaitre seulement les outils pour faire les choses rapidement cest ne pas être professionnel du métier (programmeur). :aie: