J'ai programmé en LISP ; j'ai trouvé élégant le paradigme code <=> data qui permet de coder ses fichiers de conf en LISP.
Mais j'ai l'objection principale que Uncle Bob souligne lui même :
But it’s dynamically typed!
But it’s dynamically typed[2]!!
But, Dammit, it’s dynamically typed!!!
À laquelle il répond par un "t'as qu'à faire des tests unitaires". Comme son argument principal est la concision du code LISP, ça veut dire qu'il ne compte pas les tests unitaires dans la quantité de code à écrire … c'est un peu mesquin.
En ce moment, je suis plus convaincu par Haskell, qui a une belle expressivité et qui permet de détecter énormément de bug à la compilation grâce au typage fort.
D'autre part, j'aimerai aussi que Uncle Bob nous explique comment faire du DDD en LISP ; sans typage, on va rire …
J'ai lu beaucoup à propos de LISP dans ma recherche d'un nouveau langage à pratiquer. Le message des LISP fans est souvent "si tu ne vois pas la beauté de LISP c'est que tu n'as pas comprise". Moui, ou alors que ça brille pas autant que ce qu'ils le croient.
Bref, IMHO, LISP c'est très bien mais ce n'est pas la panacée vendue par ses fans.
Tu semble confondre typage dynamique (les types t'ont vérifiés à l'exécution) et absence de typage (les types ne sont pas vérifiés).
À laquelle il répond par un "t'as qu'à faire des tests unitaires". Comme son argument principal est la concision du code LISP, ça veut dire qu'il ne compte pas les tests unitaires dans la quantité de code à écrire … c'est un peu mesquin.
Pas forcément. Tu dois faire des tests, même avec haskel, ocaml ou des languages à types dépendant. La seule alternative c'est la preuve de programme (au lieu de tester ton fonctionnel, tu le prouve).
Et comme pour ton code de production, tu écrira moins de code de test. D'une part parce que le langage est concis. D'autres part parce que comme tu as moins de boiler plate tu as moins a tester.
Je n'ai pas essayé clojure encore, mais leur transducers me font vraiment de l'œil. J'ai essayé un langage avec une syntaxe haskel (elm). Je trouve ça cool, mais il y a certaine chose que je ne comprend pas (c'est peut être pareil avec lisp), quand j'ai une ligne :
foo bar 42
Il faut obligatoirement connaître tous les types pour pouvoir dire ce que c'est ("un appel de foo qui prend 2 arguments", "un appel de bar dont le résultat est donné à foo"…).
# moui
Posté par steph1978 . Évalué à 3.
J'ai programmé en LISP ; j'ai trouvé élégant le paradigme code <=> data qui permet de coder ses fichiers de conf en LISP.
Mais j'ai l'objection principale que Uncle Bob souligne lui même :
À laquelle il répond par un "t'as qu'à faire des tests unitaires". Comme son argument principal est la concision du code LISP, ça veut dire qu'il ne compte pas les tests unitaires dans la quantité de code à écrire … c'est un peu mesquin.
En ce moment, je suis plus convaincu par Haskell, qui a une belle expressivité et qui permet de détecter énormément de bug à la compilation grâce au typage fort.
D'autre part, j'aimerai aussi que Uncle Bob nous explique comment faire du DDD en LISP ; sans typage, on va rire …
J'ai lu beaucoup à propos de LISP dans ma recherche d'un nouveau langage à pratiquer. Le message des LISP fans est souvent "si tu ne vois pas la beauté de LISP c'est que tu n'as pas comprise". Moui, ou alors que ça brille pas autant que ce qu'ils le croient.
Bref, IMHO, LISP c'est très bien mais ce n'est pas la panacée vendue par ses fans.
[^] # Re: moui
Posté par barmic 🦦 . Évalué à 2.
Tu semble confondre typage dynamique (les types t'ont vérifiés à l'exécution) et absence de typage (les types ne sont pas vérifiés).
Pas forcément. Tu dois faire des tests, même avec haskel, ocaml ou des languages à types dépendant. La seule alternative c'est la preuve de programme (au lieu de tester ton fonctionnel, tu le prouve).
Et comme pour ton code de production, tu écrira moins de code de test. D'une part parce que le langage est concis. D'autres part parce que comme tu as moins de boiler plate tu as moins a tester.
Je n'ai pas essayé clojure encore, mais leur transducers me font vraiment de l'œil. J'ai essayé un langage avec une syntaxe haskel (elm). Je trouve ça cool, mais il y a certaine chose que je ne comprend pas (c'est peut être pareil avec lisp), quand j'ai une ligne :
Il faut obligatoirement connaître tous les types pour pouvoir dire ce que c'est ("un appel de foo qui prend 2 arguments", "un appel de bar dont le résultat est donné à foo"…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.