Discussion :

[Bruno]

Les petits langages sont-ils l'avenir de la programmation ?
oui, selon Christoffer Ekeroth, développeur d’applications web et de systèmes distribués

De l’avis de Christoffer Ekeroth, développeur d’applications web et de systèmes distribués, les petits langages sont l'avenir de la programmation. « J'ai acquis la conviction que les "petits langages" conçus pour résoudre des problèmes très spécifiques sont l'avenir de la programmation, en particulier après avoir lu The end of history for programming de Gabriella Gonzalez et regardé Programming and Scaling talk d'Alan Kay », a déclaré Christoffer Ekeroth sur son blog. Toutefois, certains développeurs ont une expérience contraire.

Les langages spécifiques à un domaine, communément appelés petit langage ou langages orientés problèmes, se spécialisent dans un domaine problématique particulier et n'inclut pas de nombreuses fonctionnalités que l'on trouve dans les langages conventionnels. Par exemple, SQL est un petit langage pour décrire les opérations des bases de données. Les expressions régulières sont un petit langage pour la mise en correspondance de textes. Dhall est un petit langage pour la gestion de la configuration, et ainsi de suite.

« La plupart des logiciels d'aujourd'hui ressemblent beaucoup à une pyramide égyptienne avec des millions de briques empilées les unes sur les autres, sans aucune intégrité structurelle, mais simplement réalisées par la force brute et des milliers d'esclaves », extrait de A Conversation with Alan Kay. Pour Ekeroth, nous avons un réel problème dans la communauté du génie logiciel : la complexité croissante d'une application s'accompagne d'une augmentation de la taille de son code source.

Cependant, notre capacité à comprendre les grandes bases de code reste largement fixe. Selon The Emergence of Big Code, une enquête réalisée en 2020 par Sourcegraph, la majorité des personnes interrogées ont déclaré que la taille de leur base de code était à l'origine d'un ou plusieurs des problèmes suivants :

• difficulté à intégrer les nouvelles recrues ;
• le code se casse à cause d'un manque de compréhension des dépendances ;
• les modifications du code deviennent plus difficiles à gérer.

La plupart des personnes interrogées dans le cadre de l'enquête de Sourcegraph ont estimé que leur base de code avait été multipliée par 100 à 500 au cours des dix dernières années. À titre d'exemple concret, le noyau Linux comptait au départ environ 10 000 lignes de code en 1992. Vingt ans plus tard, il pèse environ 30 millions de lignes.

Lorsqu'on examine les logiciels actuels, il est essentiel de noter la prolifération de langages de programmation, de dépôts, de systèmes de contrôle de version, d'architectures, de services, de dispositifs pris en charge, d'outils et d'API différents qui contribuent à la complexité et au volume du code.

Selon certains analystes, un run-time pour un petit langage convivial qui fait correspondre des requêtes HTTP à des requêtes SQL peut être beaucoup plus rapide qu'un langage qui fait la même chose en mettant ensemble des API. « Un moteur d'exécution personnalisé peut analyser une chaîne de requête HTTP directement en code opérationnel SQLite, tandis que le développeur JS écrit du code qui nécessite des ordres de grandeur de mémoire et de temps CPU supplémentaires. » La manière dont les organisations de développement créent du code a nettement évolué. « C'est l'ère du Big Code », écrit sourcegraph.

• Volume : augmentation exponentielle de la quantité de code ;
• Variété : complexité croissante des langages, des outils et des processus utilisés pour fournir des logiciels ;
• Vélocité : cycles de livraison accélérés, ce qui signifie que le code change plus rapidement et qu'il est délivré pratiquement tous les jours ;
• Valeur : la réimagination des modèles et pratiques d'entreprise grâce à des logiciels de haute qualité.

Le développement serait beaucoup plus complexe aujourd'hui qu'il y a 10 ans, révèle l'enquête de sourcegraph. Les équipes de développement sont confrontées à de nombreuses difficultés en raison de la complexité croissante. Si l'entreprise devient de plus en plus complexe, sa base de code suivra, puisque le développement est le miroir de l'entreprise et de ses processus clés. Lorsqu'on a interrogé les acteurs du développement logiciel sur la complexité de leurs logiciels, 77 % ont répondu qu'ils étaient beaucoup plus complexes aujourd'hui qu'il y a dix ans.

Les langages généraux apportent des satisfactions

« Les petits langages sont l'avenir de la programmation », les gens avancent cet argument depuis les années 80 et peut-être même avant. Toutefois, certains développeurs ont une expérience contraire. Les tâches de programmation sont des « espaces vastes », pleines d'interactions potentielles entre les fonctionnalités. De plus, le code écrit dans un langage spécifique au domaine doit être compris par d'autres personnes. Il faut alors s'investir massivement dans une documentation et des outils appropriés.

Les spécialistes qui travaillent dans différents domaines tels que la finance ou l'assurance utilisent les « langages généraux » pour améliorer par exemple leurs performances grâce à l'automatisation. L'automatisation de toutes les activités ennuyeuses et répétitives telles que l'affichage, la copie, le renommage, le téléchargement de fichiers vers un serveur, le téléchargement de sites Web ou l'analyse des données peut être réalisée à l'aide de ces langages.

Aujourd'hui, presque tous les programmes sont développés à l'aide de ces langages. Nous pouvons développer une variété d'applications en utilisant des langages tels que : le Java, Python, C# et bien plus. Ils sont utilisés pour développer des applications de bureau, des sites Web, des logiciels système, des logiciels utilitaires et bien d'autres encore.

Source : Christoffer Ekeroth's blog

Et vous ?

Trouvez-vous pertinente l'analyse de Christoffer Ekeroth ?

« Les petits langages sont l'avenir de la programmation », pourquoi cette affirmation pose-t-elle problème ?

Voir aussi :

Unison : un langage de programmation qui propose une nouvelle approche de la programmation distribuée, il est statiquement typé et purement fonctionnel

Java, Python, Kotlin et Rust connaissent une croissance rapide, mais JavaScript reste le langage de programmation le plus populaire, selon une enquête de SlashData

[gangsoleil]

Bonjour,

Je comprends bien que les gros logiciels ont des inconvénients, mais pour moi ce n'est pas inhérent aux langages, mais plus à l'architecture générale et aux "bidouilles" ajoutées sans refaire proprement.

la majorité des personnes interrogées ont déclaré que la taille de leur base de code était à l'origine d'un ou plusieurs des problèmes suivants :

difficulté à intégrer les nouvelles recrues ;
le code se casse à cause d'un manque de compréhension des dépendances ;
les modifications du code deviennent plus difficiles à gérer.

Imaginons maintenant un logiciel fait de pleins de petits langages.

• Intégrer de nouvelles recrues --> il faut qu'ils apprenne le langage spécifique pour chaque implémentation, chaque correction de bug
• Le code se casse à cause d'un manque d compréhension des dépendances --> tes "petits" programmes vont bien s'appeler les uns les autres, donc tu as exactement les mêmes dépendances ; sauf qu'en plus ton dev ne sait pas lire le code de certaines parties
• Les modifications du code deviennet plus difficile à gérer --> Si c'est un langage que tu ne maîtrises pas ou peu, ça sera mieux ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
La plupart des personnes interrogées dans le cadre de l'enquête de Sourcegraph ont estimé que leur base de code avait été multipliée par 100 à 500 au cours des dix dernières années. À titre d'exemple concret, le noyau Linux comptait au départ environ 10 000 lignes de code en 1992. Vingt ans plus tard, il pèse environ 30 millions de lignes.

Le code fait-il la même chose ? Bien sûr que non.
Peut-être est-il devenu trop gros, mais là encore la taille n'est pas liée à un langage, mais à un soucis ou un besoin d'architecture. Le noyau linux gère aujourd'hui énormément de choses nativement, alors qu'avant il faillait que chaque éditeur fournisse ses drivers plus ou moins bien faits.

Mieux ? Moins bien ? Il n'y a pas de réponse, mais en tout cas ce n'est pas lié au langage.

[Mograine]

Le billet de blog de Christoffer Ekeroth mélange deux concepts totalement différent : la taille de la base de code & l'utilisation de langage ultra spécialisés. Cela rend la lecture au mieux difficile, au pire c'est totalement mensongé.

On ne peut pas dire que "language spécialisé = avenir" juste parce que "taille de la base de code trop importante", l'un n'a rien à voir avec l'autre.

la majorité des personnes interrogées ont déclaré que la taille de leur base de code était à l'origine d'un ou plusieurs des problèmes suivants :

Pour la taille de la base de code, une des solutions en vogue c'est les micro-services : découper sa base de code en une myriade de petits services indépendants afin de rationaliser les couts de maintenance & d'amélioration. C'est tout, pas de notion de langage ici, et donc aucun rapport avec le sujet initial.

Si on choisi cette solution, alors effectivement se pose la question : est-ce qu'on choisi le langage le plus adapté pour chaque micro-service, ou un seul langage global généraliste ? Mon avis c'est que comme toujours, le mieux reste la modération. Il ne sert à rien de forcer un seul langage, et il ne sert à rien de toujours en choisir un nouveau. Choisir 2/3 langages assez distincts (pas Java & C# ensemble) pour améliorer les performances des services qui en demandent, tout en maintenant un langage généraliste principal pour les services moins critiques.

On a alors le bénéfice de ne pas avoir trop de langage à gérer en interne, un recrutement facilité, tout en conservant une possibilité de langage ultra-spécifique selon un besoin identifié (R pour de la stat par exemple).

Mais encore une fois, ce choix de mono/multi langage intervient une fois qu'on a déjà choisi de "dé-monolithiser" son application, pas avant, ça ne résout donc rien en lui-même.

[commandantFred]

Je suis en désaccord avec l'explication donnée.
J'ignore si les petits langages sont aussi utiles que les gros mais les grands langages compilés ont parfaitement intégré la phénomène de croissance des externalités.
L'utilisation de librairies compilées permet de s'affranchir complètement des dépendances de compilation. C'est le principe du procédural et à fortiori de l'objet que de cloisonner les dépendances pour les "oublier". Ce qu'on peut faire avec un langage spécialisé, on peut le faire avec le langage principal.
Il y a bien des exceptions, SQL, langage interprété, rend de grands services en C compilé, on peut construire des requêtes dynamiquement en concaténant des chaines et des variables converties en string.
On peut aussi préférer lancer une tâche parallèle par shell exec plutôt qu'une dll, ne serait-ce que pour avoir une garbage collection distincte ou l'installer comme service ou encore dialoguer avec du remote hardware en temps réel. Ca simplifie le développement mais complique (un peu) le script d'installation.

Bon, il est possible que je ne connaisse pas toutes le subtilités introduites par tous les langages. certains peuvent se spécialiser dans du hardware comme le GPU, avec un paradigme différent et des contraintes de communication avec le CPU...

[GLDavid]

Bonjour

Il n'y a pas si longtemps, au début des années 2000, lors de la bulle Internet, on demandait non pas des petits langages mais des profils bien spécifiques pour créer un site ou logiciel: webmaster, web designer, database admin, system admin, testeur, développeur... Aujourd'hui, tout cela est résumé par "Full Stack", comprenez bien 1 poste pour tout ceux cités précédemment. Une manière parmi tant d'autres de réduire les coûts.
Avec cet article, j'ai l'impression qu'on revient en arrière. Pourquoi segmenter à mort avec des "petits langages" ? Et qu'entend t'on par petits langages ? SQL est un petit langage parce que j'ai besoin d'une couche base de données ? Certainement pas ! Oh, j'ai besoin d'une regexp donc je vais me fendre d'un script Perl ? Mauvaise idée !
L'auteur pense que c'est dans la diversité des langages que l'on rencontre le succès logiciel. Je ne pense pas car cela reviendrait à chercher des spécialités ou des niches dans les profils. Se spécialiser dans nos métiers dans un langage seul et sur une particularité de ce langage, c'est se condamner.
De mon côté, on privilégie quelques langages couteaux suisses comme C# ou Java. SQL est aussi dominant car on a besoin de bases de données. On a besoin aussi de C/C++ pour nos instruments. Sortie de cela, je ne vois pas pourquoi j'aurais besoin de langages autres ou ultra-spécifiques sauf peut être pour du prototypage.

@++

[floyer]

Le cas SQL est un peu particulier, il s’agit de déporter un traitement sur un processus tier (voir un serveur tier), avec un language assez simple pour permettre des optimisations selon les index présents. Rares sont les languages qui sont retraités de la sorte. (On a aussi des langages orientés analyse syntaxique/lexicale : regex/lex/yacc qui sont traités de façon particulière) Pour des usages généraux, un language généraliste suffirait. Il pourrait presque n’y en avoir qu’un, mais il y a différents facteurs à prendre en compte : performances (compilé/interprété), bibliothèque disponibles selon le domaine (Python pour le machine learning ou la présentation de données par exemple, R pour les statistiques par exemple), typage statique/dynamique. Gestion de la mémoire…

Depuis peut-être LISP, on peut considérer des données comme un programme. Aujourd’hui, les S-Exp ne sont plus à la mode, JSON et sa déclinaison YAML ont pris le relais, ce qui est pris en compte dans les scripts (pardon collections) Ansible, ou les descriptions Terraform. Dans ce dernier cas, il y a (un peu comme avec SQL) un retraitement pour comparer un état initial et un état cible et programmer des actions (et ne pas exécuter bêtement une série d’action).

[rubyonrails]

sujet intéressant..

tout d'abord qu'appelle-t-on "petit langage spécialisé" ? l'exemple du SQL me parait mal choisi car au dela d'un CRUD, je ne vois pas ce que ce langage permettrait de faire sur un sujet plus poussé .. gestion de fichiers, calcul mathématique, machine learning, langage bas niveau ? SQL couplé à un ORM permet justement de pallier aux défauts de ce petit langage, si tant est que ce soit un défaut car il fait ce pour quoi il a été créé..

pour moi, ces langages (souvent propriétaire, pour ne pas utiliser l'exemple de SQL) sont créés par un éditeur dans le but d'avoir une mainmise sur tous les aspects de développement de son produit final.

Cela n’empêche en rien un haut niveau de complexité, d'imbrications et de besoin de maintenance.. Les avantages d'un éditeur à utiliser "son petit langage" mais sur son applicatif : mainmise sur le code , réuse des devs internes (selon les mentions des contrats) pour réinclure dans le produit final, rareté = vendre plus cher son service (TMA et autres presta de consulting), pas de docs donc double mainmise sur le périmètre .. je parle ici d'exemple vécu (un prolog objet notamment)

pour ce qui est de l'urbanisation des SI, ces petits langages vont complexifier l'ensemble comme dit dans un autre commentaire, il faudra autant de ressources que de langages utilisés.. Une vieille appli sous access, un branchement via un ETL, déverser de la donnée dans un datamart.

je dirais qu'un langage doit etre choisit en fonction de son objectif. Du bas niveau (OS, réseau, ..) un langage compilé qui a fait ses preuves (printf "hello world\n"), une appli desktop avec n'importe quel langage de scripting couplé à une librairie dédiée style GTK, du web idem avec un framework qui englobe toutes les nécessités (BDD, front et back)..

en fait j'ai du mal à saisir la subtilité du message de l'auteur au final .. SQL sur HTTP sera rapide mais très limité, d'ou l'utilisation d'autres stacks .. bref merci pour l'article quoiqu'il en soit

[floyer]

Dans certains cas, il peut être intéressant d’avoir des logiciels ouverts à la programmation. Un exemple type est Excel et ses formules (SI(A1=42;"ok";"pas ok")… on peut donc utilement avoir des langages dédiés. Mais si on veut intégrer un langage dans un progiciel, il existe déjà des choses pour éviter de réinventer la roue (Guile, Lua, embedded Python, Tcl, BeanShell, Rhino…) mais qui peuvent restreindre les language dans lequel sont programmé le programme hôte.

[thamn]

Pour moi, l’intérêt d'un langage spécialisé arrive uniquement quand tu ne peux pas exprimer ou décrire ou visualiser de façon efficace un algorithme, un truc a faire avec le langage generaliste utilisée pour le projet.
Le cas d'envoyer un fichier sur un serveur est l'un des cas ou je ne voudrais vraiment pas utiliser un langage "spécialisé", je préfère utilise un langage generaliste qui va très bien faire le boulot, bien sur ce ne sera peut être pas une seule ligne de code contenant un seul mot clef, mais tout le monde sera en mesure de comprendre ce que je veux faire en lisant le code, la plupart des EDIs pourront colorer ce code, le debugger (LE DEBUGGER!), et même dans 5 ans quand qu'on aura un problème, et que le gars qui aura eu l'idée de ce langage sera parti depuis 6 mois on sera capable de comprendre, modifier, augmenter ou dégager le truc sans faire de nuit blanche ou de l’archéologie.

[el_slapper]

Vision trop technique, qui ne prend pas en compte des aspects plus macro, plus managériaux. Prenons par exemple le JAVA. Dans aucun domaine, le JAVA n'est le meilleur. Sauf que c'et un langage qui sait à peu près tout faire, et pour lequel il est très facile de trouver des gens qui savent faire. Donc, si on se met dans les pantoufles du dirigeant ou de la RH, une solution tout JAVA - malgré ses faiblesses évidentes dans des domaines spécifiques - est bien plus facile à gérer.

Je dis JAVA, mais ça vaut pour tous les "grands" langages. Les inconvénients de la généralité deviennent des avantages dès qu'on quitte la base de code.

[yotta]

Bonsoir à tous, et avant tout, bonnes fêtes de fin d"année à vous.
Je ne suis qu'un amateur solitaire complètement autodidacte qui n'a jamais suivit un cours d'ingénierie informatique.
Pour autant, je me suis régaler de lire cette discussion fort intéressante.
Cependant, vous utilisez tous un terme qui m'échappe et qui semble être le cœur de la discussion : "Bas de code".
Pourriez-vous me dire très précisément ce que vous entendez par "Base de code" ?
Merci.

[rubyonrails]

Bonsoir à tous, et avant tout, bonnes fêtes de fin d"année à vous.
Je ne suis qu'un amateur solitaire complètement autodidacte qui n'a jamais suivit un cours d'ingénierie informatique.
Pour autant, je me suis régaler de lire cette discussion fort intéressante.
Cependant, vous utilisez tous un terme qui m'échappe et qui semble être le cœur de la discussion : "Bas de code".
Pourriez-vous me dire très précisément ce que vous entendez par "Base de code" ?
Merci.

hello

quand tu va créer une application, tu va faire des lignes de codes, structurées en methodes, en class, en module, en fichiers
l'ensemble c'est ta base de code