J'appuie avec un exemple tout droit sorti de l'industrie. Dans beaucoup de secteurs, l'industrie a des préoccupations à des années-lumières des considérations développées ici. Beaucoup – trop – de code est écrit pour être jetable, et ce de façon tout à fait volontaire : la course effrénée à la nouveauté dans certains domaines (le web, les applications mobiles, qui sont deux secteurs très pourvoyeurs de codes et d'emploi informatique) fait qu'il est souvent plus rentable, en termes financiers, de sortir un produit au code crade, buggué, mais qui fait en gros le boulot, que de concevoir quoi que ce soit d'élégant. Parce que de toutes façons tout sera refait, avec un cycle de vie qui va de quelques mois à quelques années selon les parties du programme.
Les besoins d'une grosse partie de l'industrie, aujourd'hui, ce n'est pas un langage mathématiquement élégant, ou qui a un quelconque rapport avec la recherche même d'il y a 40 ans.
Ce que veut une grosse partie des « consommateurs » de langages de programmation, c'est un langage qui permet de :
Écrire du code vite.
Éviter les bugs triviaux.
Soit simple à comprendre pour qu'on puisse mettre n'importe qui dessus avec le minimum de formation possible.
Or si les langages qui plaisent aux chercheurs peuvent remplir 1 et 2, le 3 est généralement très loin d'être évident, surtout quand on parle d'introduire des paradigmes fonctionnels dans une industrie qui y touche assez peu, ce qui impliquerait une grosse quantité de formation pour le faire admettre.
Un bel exemple concret de l'effet du pragmatisme dans l'utilisation des langages de programmation, c'est le couple Kotlin/Scala, deux langages conçus en réaction aux problèmes de Java et qui ont pour cible de tourner sur la JVM, tout en étant interopérable avec Java.
Scala est intéressant conceptuellement, et a été inventé à l'École polytechnique fédérale de Lausanne. Il a son petit succès dans le monde des langages à JVM, mais n'a jamais été massivement adopté par d'énormes institutions et se traine une réputation de complexité d'approche et conceptuelle.
Kotlin a été conçu par une industrie (JetBrains) et son approche est 100 % pragmatique : « si ça aide le développeur, on prends, sinon tant pis ». Il ressemble donc beaucoup plus à un gros tas de sucre syntaxique sur Java ; mais en dépit de concepts assez inintéressants et de qualité variable, il se développe dans le monde des langages à JVM comme aucun avant lui : https://trends.google.fr/trends/explore?date=all&q=%2Fm%2F0_lcrx4,%2Fm%2F091hdj,%2Fm%2F02js86
Je ne dis pas que l'un est meilleur que l'autre. Mais déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche, c'est faire une erreur d'appréciation monumentale qui ignore une part énorme des besoins et contraintes qui régissent l'utilisation desdits langages. Et c'est une erreur que je croise depuis des années dans la recherche en informatique ou même dans pas mal de communautés qui font des langages fonctionnels ( = censément meilleurs mathématiquement).
[^] # Re: go 2.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 9.
J'appuie avec un exemple tout droit sorti de l'industrie. Dans beaucoup de secteurs, l'industrie a des préoccupations à des années-lumières des considérations développées ici. Beaucoup – trop – de code est écrit pour être jetable, et ce de façon tout à fait volontaire : la course effrénée à la nouveauté dans certains domaines (le web, les applications mobiles, qui sont deux secteurs très pourvoyeurs de codes et d'emploi informatique) fait qu'il est souvent plus rentable, en termes financiers, de sortir un produit au code crade, buggué, mais qui fait en gros le boulot, que de concevoir quoi que ce soit d'élégant. Parce que de toutes façons tout sera refait, avec un cycle de vie qui va de quelques mois à quelques années selon les parties du programme.
Les besoins d'une grosse partie de l'industrie, aujourd'hui, ce n'est pas un langage mathématiquement élégant, ou qui a un quelconque rapport avec la recherche même d'il y a 40 ans.
Ce que veut une grosse partie des « consommateurs » de langages de programmation, c'est un langage qui permet de :
Or si les langages qui plaisent aux chercheurs peuvent remplir 1 et 2, le 3 est généralement très loin d'être évident, surtout quand on parle d'introduire des paradigmes fonctionnels dans une industrie qui y touche assez peu, ce qui impliquerait une grosse quantité de formation pour le faire admettre.
Un bel exemple concret de l'effet du pragmatisme dans l'utilisation des langages de programmation, c'est le couple Kotlin/Scala, deux langages conçus en réaction aux problèmes de Java et qui ont pour cible de tourner sur la JVM, tout en étant interopérable avec Java.
Je ne dis pas que l'un est meilleur que l'autre. Mais déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche, c'est faire une erreur d'appréciation monumentale qui ignore une part énorme des besoins et contraintes qui régissent l'utilisation desdits langages. Et c'est une erreur que je croise depuis des années dans la recherche en informatique ou même dans pas mal de communautés qui font des langages fonctionnels ( = censément meilleurs mathématiquement).
La connaissance libre : https://zestedesavoir.com