Attention
La version initiale de cette publication a reçu une excellente réponse sur Reddit sous la forme de plus de 300 commentaires. Après cela, j'ai décidé d'y ajouter une petite mise à jour afin de répondre à certaines critiques des nombreuses reçues.
Un langage de programmation visuel est celui qui permet à un programmeur de créer des programmes en manipulant des éléments graphiques plutôt qu'en tapant des commandes de texte. Un exemple célèbre est
Scratch , un langage de programmation visuel originaire du MIT qui est utilisé pour éduquer les enfants. Ses avantages sont qu'il rend la programmation plus accessible aux débutants et aux non-programmeurs.
Dans les années 1990, il y avait un mouvement très populaire pour introduire la programmation visuelle dans l'environnement d'entreprise en utilisant les outils dits
CASE , où les systèmes d'entreprise pouvaient être définis en utilisant
UML et générés [leur code] sans avoir besoin d'attirer des développeurs de logiciels qualifiés. Cela est dû au concept de «déclenchement aller-retour» («aller-retour»), où le système peut être modélisé visuellement, le code du programme sera généré à partir des modèles reçus et toute modification du code peut être renvoyée au modèle. Hélas, de tels outils n'ont jamais pu remplir leur mission, et la plupart des expériences [sur leur mise en œuvre] sont actuellement largement abandonnées.
Ainsi, la programmation visuelle n'a pas gagné en popularité, sauf dans certains domaines très limités. Cette situation est largement due aux idées fausses suivantes sur la programmation:
- Les langages de programmation de texte confondent ce qui est essentiellement un processus simple.
- L'abstraction et le découplage ( découplage, réduction de la connectivité ) jouent un petit rôle périphérique dans la programmation.
- Les outils conçus pour faciliter la programmation ne sont pas importants.
La première idée fausse insiste sur le fait que le développement de logiciels a un seuil d'entrée élevé, car les langages de programmation de texte compliquent la vraie nature de la programmation. La popularité de Scratch parmi les enseignants universitaires joue avec cette idée fausse. L'idée est que la programmation est en fait assez simple, et si nous ne pouvions la présenter que dans un format graphique clair, cela réduirait considérablement la courbe d'apprentissage et l'effort mental requis pour créer et lire le code du programme.
Je suppose que cette erreur provient de l'incapacité de lire réellement un programme typique écrit dans le langage de programmation de texte standard et d'imaginer comment il est converti en éléments graphiques à partir de «cubes» et de flèches. Si vous pouvez toujours imaginer cela, alors il deviendra immédiatement évident qu'une seule ligne de code est souvent associée à plusieurs «blocs». Étant donné que même pour le programme le plus simple, la présence de centaines ou de deux lignes de code n'est pas inhabituelle, son code se transformera en centaines, voire en milliers d'éléments graphiques. Une tentative d'analyse mentale d'une image aussi complexe sera beaucoup plus difficile que la simple lecture du texte du programme équivalent.
La solution pour la plupart des langages de programmation visuels est de rendre les «blocs» plus complexes afin que chaque élément visuel soit équivalent à un gros bloc de code texte. Les outils visuels du workflow sont une pierre d'achoppement immédiate.
Le problème est que le code doit encore être défini quelque part. Par conséquent, le processus de codage [sur les grands éléments visuels] se transforme en «propriétés de dialogue de programmation». Les éléments visuels eux-mêmes ne représentent que le niveau le plus élevé de mouvement du programme pendant l'exécution, et la plupart du travail est désormais effectué en code texte standard caché dans des «cubes» visuels. En conséquence, nous avons pris le pire des deux mondes et obtenu une programmation de texte qui n'est pas prise en charge par les outils modernes.
Les boîtes de dialogue de propriétés sont généralement des environnements de développement non standard et imposent un choix spécifique de langage, généralement un langage de script d'un certain type. Les éléments visuels de base eux-mêmes ne peuvent être créés que par des programmeurs expérimentés et ils ne peuvent être parfaitement compris qu'en lisant leur code de base, de sorte que la plupart des avantages allégués de la présentation visuelle sont perdus ici.
Il existe un décalage d'impédance entre le «code» visuel et le code texte (un
ensemble de difficultés conceptuelles et techniques ), et le programmeur doit naviguer dans l'interface entre eux, consacrant souvent plus d'efforts à l'amélioration de l'outil de programmation graphique lui-même qu'à la résolution de la tâche originale [d'écriture du programme].
Et maintenant, nous arrivons à la deuxième idée fausse selon laquelle l'abstraction et la décuplication jouent un petit rôle dans la programmation. La programmation visuelle est basée sur l'hypothèse que la plupart des programmes sont de simples séquences procédurales, quelque peu similaires à un organigramme. En règle générale, la plupart des programmeurs novices pensent que les logiciels fonctionnent exactement comme ça.
Cependant, dès que le programme deviendra plus qu'un exemple plutôt banal, sa complexité submergera bientôt le programmeur novice. Les débutants trouvent très difficile de parler d'une grande base de code procédural et sont souvent enlisés dans les tentatives de création de logiciels à grande échelle stables et efficaces. La principale innovation dans les langages de programmation a été la tentative de contrôler la complexité, généralement par l'abstraction, l'encapsulation et la connectivité réduite. Tous les systèmes de types et les constructions de langages de programmation orientés objet et fonctionnels ne sont en fait qu'une tentative pour prendre le contrôle de la complexité de ces langages.
La plupart des programmeurs professionnels résumeront et découpleront constamment le code. En fait, la différence entre le bon et le mauvais code est essentiellement la mesure dans laquelle le programmeur a réussi à le faire. Les outils de programmation visuels ont très rarement des mécanismes efficaces pour de telles choses, par conséquent, le développeur «visuel» est piégé dans les capacités disponibles, équivalentes à BASIC des années 1970.
La dernière idée fausse est que les programmeurs visuels peuvent se passer de tous les outils de support de programmation qui ont été développés au fil des décennies. Jetez un œil à la longue évolution des éditeurs de code et des IDE. Par exemple, Visual Studio prend en charge un outil intellisense efficace qui vous permet de jeter un œil aux milliers d'API disponibles dans la bibliothèque de classes de base uniquement. Le manque d'un bon contrôle de version est un autre défaut majeur de la plupart des outils de programmation visuels.
Même s'ils enregistrent leur mise en page au format texte, les «diffs» n'ont aucune ou presque aucune signification. Il est très difficile de faire un «blâme» (pour trouver le commit et responsable de changer une ligne particulière) dans un grand bloc de XML ou JSON. Des choses qui n'ont aucune signification pour l'exécution fonctionnelle d'un programme, comme la position et la taille des éléments graphiques, conduisent constamment à des changements dans les métadonnées, ce qui rend le diff encore plus difficile à analyser.
Les langages de programmation de texte ont appris à séparer les blocs structurels de code en fichiers source distincts, il est donc facile de fusionner un changement dans une partie d'un système avec un changement dans une autre. Les outils visuels enregistrent généralement le résultat selon le principe «un diagramme par fichier», ce qui signifie que la fusion devient problématique, et encore plus difficile si la signification sémantique de «diff» est difficile à analyser.
Mettre à jourJe me suis probablement trompé lorsque j'ai pris une capture d'écran Scratch et que je l'ai utilisée comme exemple principal dans mon premier paragraphe. Je ne suis pas enseignant et je n'ai pas ma propre opinion sur l'efficacité de Scratch en tant qu'outil d'apprentissage. Beaucoup de gens disent qu'il est extrêmement utile dans l'enseignement des programmes, en particulier pour les enfants. Tout ce qui aide les gens à entrer dans le monde merveilleux et passionnant de la programmation ne doit être que loué. Je n'avais vraiment pas l'intention de critiquer spécifiquement Scratch maintenant, ce n'est qu'un exemple d'un système de programmation visuelle, qui, il me semble, la plupart de mes lecteurs auraient dû entendre au moins.
Un autre contre-exemple fourni par Reddit était les outils de structure statique tels que les concepteurs d'interface utilisateur, les concepteurs de schéma de base de données ou les concepteurs de classe. Je suis d'accord qu'ils peuvent être très utiles. Tout ce qui aide à visualiser la structure de données ou la structure d'échelle du programme est un bonus. Mais ils ne suffisent jamais. Cela est démontré par l'échec complet des outils des années 90, tels que Power Builder, qui étaient basés sur des visualisations graphiques pour créer un environnement de développement sans avoir besoin de travailler avec du code.
À propos de l'auteur:
Notes, pensées à voix haute, apprentissage à la vue, malentendus, erreurs, opinions non diluées. Je suis Mike Hadlow, un développeur prêcheur. J'habite près de Brighton sur la côte sud de l'Angleterre.
La traduction a été prise en charge par EDISON Software, une société professionnelle de développement et de test de logiciels .