La programmation visuelle est un type de langage de programmation qui permet aux humains de décrire des processus à l’aide d’illustrations. Alors qu’un langage de programmation textuel typique fait penser le programmeur comme un ordinateur, un langage de programmation visuelle permet au programmeur de décrire le processus en termes qui ont un sens pour les humains.
L’ampleur de l’écart entre la programmation visuelle et la programmation traditionnelle dépend de l’outil de programmation visuelle. À un extrême, l’outil protège le programmeur presque entièrement de l’espace béant entre la pensée humaine et les ordinateurs qui brassent des bits dans la mémoire.
Voici un exemple. Pour créer une liste de tâches avec un outil de programmation visuelle, le programmeur dessine le flux de l’application. L’organigramme qui en résulte décrit les écrans, les interactions avec l’utilisateur et ce qui arrive aux données à chaque étape. L’outil transforme ensuite tout cela en logiciel.
En tant que développeurs, nous savons que les langages de programmation textuels se concentrent entièrement sur la mise en œuvre : il s’agit des étapes précises que l’ordinateur doit suivre pour créer l’expérience que nous voulons offrir à l’utilisateur. Bien sûr, les langages de niveau supérieur et les frameworks modernes nous offrent des raccourcis pratiques. Mais, le travail du développeur consiste à traduire les besoins humains en processus adaptés aux capacités limitées de l’ordinateur.
Les autres outils de codage visuel suivent les mêmes processus et paradigmes que la programmation en mode texte. Imaginez dessiner une classe et sa relation avec les objets que vous instanciez, plutôt que de taper tout cela dans un éditeur de texte.
Tout cela semble formidable ! Mais, vous pourriez vous demander, où sont tous les programmeurs visuels ? Pourquoi écrivons-nous encore du code à la main ? Cela signifie-t-il que la programmation visuelle est une mauvaise idée ?
Avant de répondre à ces questions et de plonger dans l’état de la programmation visuelle aujourd’hui, nous devons comprendre ce qu’est vraiment la programmation visuelle : d’où elle vient, comment elle a évolué, et pourquoi.
Découvrez la prochaine génération d’outils de développement visuel
Un bref historique des logiciels de programmation visuelle
Bien que l’histoire semble le montrer, il n’est pas juste de dire que la programmation visuelle dans les années 1990 était confinée aux kits de création de jeux, aux outils multimédia et aux bases de données. Rational Software (qui a été acquis par IBM en 2003) avait construit un IDE Ada sans interface graphique depuis le milieu des années 1980. En outre, ils se sont également attelés à la définition du processus de développement logiciel. Les travaux sur leur Rational Unified Process et les efforts connexes ont finalement abouti au langage de modélisation unifié, qui avait le potentiel de documenter chaque élément d’un système sans jamais écrire une ligne de code. Cela ressemblait à de la programmation visuelle mais sans produire de logiciel exécutable.
UML a fourni un langage standardisé et complet pour décrire les systèmes orientés objet. Cependant, la fièvre d’UML a frappé certains architectes. Le coauteur de The Pragmatic Programmer, Andy Hunt, raconte l’histoire d’un projet de logiciel où un architecte a passé deux ans à créer des diagrammes UML avant même qu’une ligne de code ne soit écrite.
Au moment où l’agilité prenait de l’ampleur, UML semblait permettre tous les pires aspects des anciennes façons de construire des logiciels : trop de planification et trop peu de mise en œuvre. UML exécutable était une tentative d’ajouter cette pièce manquante – le logiciel exécutable. Plusieurs implémentations ont fait surface, mais sans avoir trop d’impact sur un monde qui se tournait rapidement vers PHP, Ruby on Rails, et d’autres langages de script dynamiques.
Intéressant, une forme d’UML exécutable qui s’est maintenue est également issue de Rational Software. Rational Rose est une suite d’outils permettant de créer des logiciels à l’aide d’UML et de générer du code exécutable dans un langage cible, tel que C++ ou Java.
Retour vers le futur : L’état de la programmation visuelle aujourd’hui
Sur la base de ce que l’histoire nous montre, vous pourriez vous demander : la programmation visuelle est-elle morte ? Les passionnés de programmation visuelle vous diront qu’elle est loin d’être morte. Demandez-leur « qu’est-ce que la programmation visuelle ? » et ils vous citeront d’abord un obscur outil spécifique à un domaine. Ensuite, ils vous diront que cet outil est la preuve que la programmation visuelle est bien vivante. Pendant ce temps, vous le rechercherez frénétiquement sur Google. En conséquence, vous apprendrez non seulement sur l’outil qu’ils ont mentionné, mais aussi sur le monde hautement spécialisé dans lequel il existe.
Sans aucun doute, la programmation visuelle a son rôle, qu’il s’agisse de programmer des synthétiseurs ou de donner aux amateurs d’UML un sentiment d’accomplissement. Pour les logiciels à usage général, cependant, le monde est tout simplement trop complexe pour être modélisé purement visuellement. Lorsque votre « code » ressemble à un schéma de circuit de CPU, il est peut-être temps de repenser l’adéquation de la programmation visuelle à la tâche.
De même, les logiciels de programmation visuelle ont tendance à être limités par l’imagination du créateur d’une manière qui n’entrave pas les langages de programmation textuels à usage général.
Et pourtant, des outils comme Visual Basic, Delphi, et leurs descendants nous ont montré que la construction de logiciels visuellement peut être énormément efficace ; c’est juste qu’il y a un compromis pragmatique où, parfois, le code écrit à la main est la bonne solution.
Superstars contre équipes : Une nouvelle vie pour les langages de programmation visuelle ?
Ces premiers jours de la programmation étaient difficiles, c’est sûr. Mais une seule personne pouvait comprendre et être experte dans tout ce qui était nécessaire pour créer ce logiciel. Si vous êtes assez vieux, repensez aux titres de logiciels des années 1980. Il était courant qu’un seul programmeur devienne une marque à part entière.
Sid Meier, Mitch Kapor et Jeff Minter ont acquis un certain niveau de célébrité en créant des applications ou des jeux connus, seuls ou, au maximum, avec un autre collaborateur. À l’époque, les cycles de mise à jour des logiciels et du matériel duraient des années. Aujourd’hui, nous plaisantons en disant qu’il y a une nouvelle bibliothèque JavaScript tous les jours. Pourtant, il y a une part de vérité dans l’idée que le développement de logiciels modernes évolue à un rythme que beaucoup d’entre nous ne peuvent suivre.
Aujourd’hui, les logiciels sont largement construits par des équipes de spécialistes. Alors que les premiers développeurs faisaient tout eux-mêmes, une équipe de développement de logiciels modernes peut compter une personne dont le seul travail consiste à s’occuper de l’outil de CI. Les développeurs passent des carrières entières à se concentrer sur un framework ou une plate-forme. Les développeurs iOS sont des développeurs iOS, pas des développeurs mobiles. Une ou deux fois par décennie, peut-être, un développeur web peut changer de framework. Très peu de personnes écrivent manuellement du langage d’assemblage de manière professionnelle.
Ce n’est pas seulement que la portée du logiciel a changé. Dans une certaine mesure, les développeurs eux-mêmes ont changé, aussi. Ingénieur logiciel est juste une autre carrière de nos jours. Dans les décennies passées, c’était une passion détenue par quelques personnes qui avaient le dévouement nécessaire pour apprendre un système entièrement nouveau afin de pouvoir écrire le portage sur Atari ST, par exemple, de leur jeu à succès sur Amiga. Mais c’est compréhensible : l’informatique n’est plus une niche.
Aujourd’hui, nous avons un monde où le développement logiciel est constitué de parties de plus en plus complexes et où les développeurs sont des gens ordinaires avec des spécialisations extraordinaires. Cette complexité et cette spécialisation sont mal adaptées à la programmation visuelle pure de ces premiers outils, mais elles rendent également de plus en plus difficile la constitution d’équipes d’ingénierie logicielle rondes.
Là où les environnements de programmation visuelle pure ont échoué, il existe toute une cache d’outils similaires qui prennent le meilleur de la programmation visuelle et le combinent avec le codage en mode texte. Alors que la programmation visuelle était « no-code », ces nouveaux outils sont « low-code ».
Des outils comme OutSystems permettent aux développeurs de créer des logiciels visuellement en dessinant les flux d’interaction, les interfaces utilisateur et les relations entre les objets, mais en les complétant avec du code écrit à la main lorsque c’est la meilleure chose à faire.
Ce mélange pragmatique de programmation visuelle et de programmation textuelle est bien adapté aux besoins du développement de logiciels modernes. Les plateformes low-code réduisent la complexité du développement logiciel et nous ramènent à un monde où un seul développeur peut créer des systèmes riches et complexes, sans avoir à apprendre toutes les technologies sous-jacentes.
La prochaine génération de programmation visuelle : Delivering on the Promise
La programmation visuelle a tenu tant de promesses et les problèmes qu’elle voulait résoudre n’ont pas disparu. En fait, ils sont plus pertinents que jamais.
Mais les problèmes du monde réel exigent une plus grande flexibilité que la programmation visuelle pouvait offrir. Le Low-code prend cette promesse et l’applique pour réduire la complexité que nous trouvons dans le développement de logiciels modernes. Donc, ne demandez pas « qu’est-ce que la programmation visuelle ? ». Demandez plutôt « qu’est-ce que le low-code ? ». Vous pouvez également programmer une démo en ligne ou même essayer OutSystems (c’est gratuit).