déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche
Attention, un langage peut être simple tout en ayant de bonnes propriétés mathématiques. Kotlin a une sémantique des bindings à peu près raisonnable (pas comme nonlocal en Python qui est cassé, ou Coffeescript, cf. ailleurs), on comprend bien la sémantique de l'héritage en Java (ça a été formalisé plusieurs fois selon l'approche de ma communauté), etc. Un autre exemple de Java-amélioré est Ceylon, un peu dans la même niche que Kotlin, et qui a été regardé de près par (le chercheur) Ross Tate qui a fait des choses intéressantes avec. Avoir une sémantique formelle pour un langage de programmation, et corriger les verrues que cela révèle, ne veut pas dire qu'il faut forcément lui ajouter des types dépendants de la mort.
(D'ailleurs j'ai travaillé pendant un moment sur un langage jouet (le lambda-calcul simplement typé) qui n'a même pas de génériques / de polymorphisme, pour y comprendre des questions de base qui ne mettent pas en jeu ces aspects.)
Il ne faut pas croire que "étudier les langages comme des objets mathématiques" veut forcément dire "cracher sur tout ce qui ne ressemble pas à Haskell". On a identifié des problèmes à plein de niveaux simples (comme la portée des variables, ou les tableaux covariants en Java) qui s'appliquent à tous les langages, et on peut très bien formaliser et étudier (et améliorer !) des langages impératifs ou objets assez simples.
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Attention, un langage peut être simple tout en ayant de bonnes propriétés mathématiques. Kotlin a une sémantique des bindings à peu près raisonnable (pas comme
nonlocalen Python qui est cassé, ou Coffeescript, cf. ailleurs), on comprend bien la sémantique de l'héritage en Java (ça a été formalisé plusieurs fois selon l'approche de ma communauté), etc. Un autre exemple de Java-amélioré est Ceylon, un peu dans la même niche que Kotlin, et qui a été regardé de près par (le chercheur) Ross Tate qui a fait des choses intéressantes avec. Avoir une sémantique formelle pour un langage de programmation, et corriger les verrues que cela révèle, ne veut pas dire qu'il faut forcément lui ajouter des types dépendants de la mort.(D'ailleurs j'ai travaillé pendant un moment sur un langage jouet (le lambda-calcul simplement typé) qui n'a même pas de génériques / de polymorphisme, pour y comprendre des questions de base qui ne mettent pas en jeu ces aspects.)
Il ne faut pas croire que "étudier les langages comme des objets mathématiques" veut forcément dire "cracher sur tout ce qui ne ressemble pas à Haskell". On a identifié des problèmes à plein de niveaux simples (comme la portée des variables, ou les tableaux covariants en Java) qui s'appliquent à tous les langages, et on peut très bien formaliser et étudier (et améliorer !) des langages impératifs ou objets assez simples.