Pourquoi Lisp n'est-il pas plus répandu? [fermé]

Je commence à apprendre Scheme par les vidéos SICP, et je voudrais passer à Common Lisp ensuite.

La langue semble très intéressante, et la plupart des gens qui écrivent des livres sur ce thème affirment qu’elle possède un pouvoir expressif inégalé. CL semble avoir une bibliothèque standard décente.

Pourquoi Lisp n'est-il pas plus répandu? S'il est vraiment aussi puissant, les gens devraient l'utiliser partout, mais il est presque impossible de trouver, par exemple, des offres d'emploi Lisp.

J'espère que ce n'est pas juste la parenthèse, car ils ne sont pas un gros problème après un petit moment.

L'expression n'est pas toujours un trait de langue positif dans un environnement d'entreprise. Java est extrêmement populaire en partie parce qu’il est facile à apprendre, facile à écrire et à lire. Les programmeurs médiocres peuvent toujours être très productifs en Java, même si leur code est verbeux et inélégant.

De plus, il est facile d’abuser des langages expressifs. Un programmeur expert en java peut refactoriser rapidement un code mal écrit. Plus le langage est expressif, plus la compréhension et la refactorisation d'un code horrible deviennent difficiles. Les macros LISP sont un bon exemple. Les macros sont des outils puissants entre de bonnes mains. Entre de mauvaises mains, ils peuvent générer du code source de confusion et difficile à déboguer.

Le LISP est un choix risqué pour la haute direction. En cas de problème, personne ne va reprocher à la direction de choisir un langage populaire orienté objet, soutenu par une grande entreprise comme Oracle ou Microsoft. Il est beaucoup plus facile d'engager des programmeurs expérimentés dans les langues populaires et faciles à apprendre.

Même les entreprises progressistes souhaitant utiliser un langage plus puissant ne choisissent généralement pas LISP. En effet, nombre des langues les plus récentes tentent de trouver un compromis en empruntant de puissantes fonctionnalités à LISP, tout en restant faciles à apprendre pour les masses. Scala et Ruby suivent ce modèle. Les mauvais programmeurs peuvent les récupérer rapidement et continuer à écrire le même code médiocre qu’ils l’ont fait en Java. Les bons programmeurs peuvent tirer parti des fonctionnalités plus avancées pour écrire du code magnifique.

Les parenthèses ne sont pas le problème. Haskell est un langage incroyablement puissant et expressif, dont la syntaxe est similaire à celle de Python ou de Ruby et qui n’a pas été largement adopté pour les mêmes raisons que LISP.

Malgré tout cela, j'espère ...

Clojure a une chance de devenir populaire. Il fonctionne sur la machine virtuelle Java, interagit très bien avec Java et simplifie beaucoup la programmation simultanée. Ce sont toutes des choses importantes pour de nombreuses entreprises.

* C’est mon point de vue en tant que programmeur professionnel JVM avec une expérience de Java, Clojure, JRuby et Scala.

Pourquoi Lisp n'est-il pas plus répandu? Si elle est vraiment aussi puissante, les gens devraient l’utiliser partout,

Si vous croyez que les langues sont choisies pour leurs mérites techniques, vous serez submergé par une déception déchirante.

Ces décisions sont prises sur la base de Strippers And Steaks . Microsoft peut se les payer. Oracle peut. Sun a dépensé tellement d’argent en faisant jaillir Java qu’ils ont fait faillite. Deux fois. Une communauté de bénévoles décentralisée et hétérogène ne peut rivaliser avec cela.

mais au lieu de cela, il est presque impossible de trouver, par exemple, des offres d’emploi Lisp.

Curieusement, les sociétés Lisp disent exactement le contraire: elles ont constamment des offres d’emploi mais ne trouvent pas assez de personnes pour les combler. (Il en va de même pour Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Je n'ai aucune expérience professionnelle dans une vraie entreprise, mais je sais pourquoi LISP a été difficile à utiliser pour moi.

Tout d’abord, cela me rappelle ce billet de blog: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Le principal problème que j'ai avec Lisp est la question "quel Lisp". Je travaille habituellement sous Linux comme plate-forme principale, mais ce que je fabrique doit être compatible avec Windows. Cela signifie que lorsque j'évalue une technologie à utiliser, elle doit me faciliter la vie lorsque je travaille sur deux systèmes d'exploitation radicalement différents. Je n'aime pas cette exigence, mais l'utiliser sur un vrai projet, c'est une exigence. Maintenant, je vais utiliser des langages qui ne supportent pas très bien Windows pour mes projets personnels, mais comme je n'ai jamais la chance d'écrire un gros projet logiciel, je n'ai pas l'expérience nécessaire.

Maintenant, quand j'essayais d'apprendre un langage fonctionnel, je voulais vraiment apprendre le Common Lisp. Cela semblait la bonne chose à faire. J'ai commencé à lire Practical Common Lisp comme point de départ, car je ne connaissais vraiment pas les fonctions intégrées et j'avais besoin d'un projet sur lequel travailler à Lisp. Les expressions S étaient belles et faciles. Toutes ces parenthèses étaient incroyablement belles pour moi car il était clair au jour le jour exactement ce qui se passait dans le code.

J'essaye donc d'écrire mon premier programme en Lisp en dehors du livre. Je voulais un outil de ligne de commande qui compte les lignes de code et supprime les lignes triviales du nombre de codes. Ce n'est pas l'outil le plus utile, mais c'est amusant à faire. Cela implique un accès aux fichiers, un peu d’analyse et de comptage. J'avais implémenté le même outil en Python environ une semaine plus tôt.

J'ai besoin d'accéder aux arguments en ligne de commande. Ensuite, j'apprends qu'il n'y a pas de moyen standard d'obtenir des arguments en ligne de commande. Ce sont toutes des fonctionnalités non standard. Ce n'est pas du tout multiplateforme. La situation ne fait qu'empirer, à partir du moment où la langue ne comprend pas beaucoup de bibliothèques. J'ai fini par basculer sur Haskell et je ne suis pas allé très loin dans Common Lisp (mes plaintes risquent donc de ne pas être valables).

Ce genre de chose non standard a toujours été une douleur pour moi dans le passé. C ++ a le même problème, mais avec des bibliothèques comme Boost, vous pouvez contourner ces faiblesses.

Cela n'aide pas non plus que la syntaxe Lisp pour tout ce qui est autre que les expressions S soit un peu moche.

OMI, c'est principalement dû à:

• Support médiocre de la bibliothèque. Bien sûr, il existe maintenant Quicklisp, ce qui facilite l’installation des bibliothèques, mais cela ne compense pas le fait qu’elles sont encore assez peu nombreuses, et nombre d’entre elles sont mal documentées ou mal entretenues. Par rapport à Python, il est fort probable que l'écriture d'une application Lisp non triviale (quel que soit le dialecte utilisé) impliquera probablement encore de réinventer au moins une partie d'une roue ou deux.
• Manque de connaissance du modèle adopté par les outils de développement. La plupart des gens que je connais sont plutôt intimidés de devoir utiliser SLIME et Emacs, ce qui est compréhensible pour les personnes habituées à Eclipse et à Visual Studio. Il y a deux plugins Eclipse je pense, je n'en ai essayé qu'un seul il y a quelques années et c'était plutôt bogué. L’ensemble de l’écosystème Lisp semble s’être bloqué à mi-chemin entre l’époque où il faisait partie d’un système à part entière fonctionnant avec Lisp et le standard moderne de l’autre langue. Apprendre Lisp ne se limite pas à l’apprentissage d’une nouvelle langue. Vous devez également apprendre à travailler et à penser de manière totalement différente. Si vous le faites comme passe-temps, c’est douteux que cela vaille la peine de le faire dans un environnement différent. Entreprise.

Les choses commencent à paraître un peu mieux, surtout avec Clojure.

J'ai appris le LISP il y a un milliard d'années à l'université.

LISP, comme FORTH, est idéal pour la logique. Mais la plupart des programmes ne concernent pas la logique, mais la manipulation de données de manière mécanique ennuyeuse. Par exemple, à l’époque, il n’y avait aucun moyen de justifier une sortie numérique.

LISP concerne les fonctionnalités imbriquées, et les gens ne pensent tout simplement pas de cette façon. Ils pensent en termes de DO A, B, C, D, puis E. Ne pas faire A, ce qui implique de faire B et C, puis D et E. Cela implique une sorte de concurrence qui crée de la confusion. À l'exception des tâches prédéfinies telles que «Produire une déclaration de revenus», les gens ne pensent pas simultanément, ils pensent de manière séquentielle. C'est pourquoi les langages procéduraux sont dominants aujourd'hui.

En conséquence, le code produral lie Java et C peut être traduit en anglais facilement. Le code LISP ne peut pas; aucun langage humain n'est structuré de la sorte.

C'est donc très bien pour la résolution de problèmes, mais la résolution de problèmes n'est pas très importante en programmation. La saisie de données, la validation, le formatage de la sortie, autant de choses sur lesquelles LISP était terriblement faible.

Je pense qu’un problème avec Lisp qui n’a pas encore été mentionné est que, pour un programmeur médiocre ou débutant (comme moi, je l’avoue volontiers), il peut être difficile de voir comment transformer le code Lisp en un gros programme. C'est facile à écrire mais difficile à créer. Je ne pense pas qu'aucun des concepts soit particulièrement difficile, mais la mentalité de bricolage est si forte que je me sens souvent mal à l'aise.

Avec un langage OOP tel que Java ou C #, vous pouvez utiliser le système de types pour vous inciter à adopter un modèle opérationnel et à en tirer parti. Avec Lisp (ou Lua, ou javascript, d'ailleurs), il y a cette notion que vous pouvez sortir et le faire comme vous le souhaitez. Si vous voulez la POO, créez simplement votre propre système de POO! Sauf que faire sa propre POO ou apprendre celle de quelqu'un d'autre est une nouvelle barrière au-dessus de la langue avant que vous obteniez des programmes utilisables. De plus, j'ai toujours l'impression que la POO à Lisp ou à Lua n'y est pas vraiment, comme si je pouvais simplement l'ignorer si je le voulais vraiment, alors à quoi ça sert?

En bref, je pense que la programmation en Lisp nécessite beaucoup de discipline, et c'est très difficile à trouver. Les langages fortement typés et les langages POO offrent tous deux une sorte de discipline intégrée. Le programmeur peut ainsi concentrer ses réserves limitées sur la finition des projets au lieu de peaufiner le langage.

EDIT: Comme analogie qui m’a frappé, c’est comme s’il fallait travailler le bois et que deux personnes vous offrent leurs boîtes à outils. Les outils d'une personne sont un peu moche, mais feraient le travail avec un peu d'effort. L’autre personne dispose d’un grand nombre de pièces, mais elle vous promet que vous pourrez combiner ces pièces pour obtenir les meilleurs outils jamais utilisés, parfaitement adaptés à votre prise en main et de la meilleure qualité. Vous devez juste les construire en premier.

Je me demandais la même chose depuis longtemps et je suis même allé à des conférences Lisp pour essayer de comprendre quel est ce "côté obscur" de Lisp qui empêche tout le monde de l'adopter.

Je n'ai trouvé aucune réponse complète et décente.

L'ignorance est peut-être la raison de la popularité manquante, mais ce qui me surprend le plus, c'est que même ceux qui sont au courant de Lisp (par exemple, Google - Peter Norvig travaille pour eux) ne l'utilise pas.

La seule explication partielle que je propose est que la plupart des bonnes idées Lisp sont maintenant monnaie courante, le seul élément qui manque vraiment (une très importante, OMI) est la facilité de métaprogrammation.

Malheureusement, je ne vois pas de moyen facile d'adsorber ce concept pour d'autres langues, car métaprogrammer pour être agréable nécessite un langage homoiconique et régulier (je parle de métaprogrammation générale, et non de la version dépourvue de modèles uniquement). En d'autres termes, cela nécessite fondamentalement l'approche de la syntaxe Lisp: le code est une donnée et la donnée est un code. Écrire du code dans un langage riche en syntaxe qui manipule un AST est plus difficile car vous devez connaître deux langages: comment écrire le code et comment écrire l'AST. Cela est particulièrement difficile si votre AST est fixe, complexe et irrégulière avec de nombreux types de nœuds. Lisp a plutôt un AST raisonnablement régulier (et extensible!) Et vous codez déjà normalement en écrivant directement l'AST.

La métaprogrammation est aussi intrinsèquement plus difficile (et la méta-métaprogrammation encore plus et ainsi de suite) et la plupart des programmeurs et des gestionnaires préfèrent apparemment simplement que "personne n’aurait besoin de cette réponse".

Je trouve particulièrement triste que de "nouveaux" langages, tels que la gométaprogrammation textuelle, aient été utilisés à la demande (générateurs de code externes écrivant des fichiers texte) et "magiques" (le compilateur peut faire ce que les programmeurs ne peuvent pas faire).

Je pense que la solution au problème de la complexité réside dans des outils et une éducation puissants. La tendance est apparemment à la place des outils émoussés et prétendant que le problème n’est pas présent.

Il semble que même CL ne dispose pas d’un très bon support de bibliothèque. Au moins selon les personnes qui sont passées de Lisp à Python:

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

Personnellement, je connais un schéma et aime jouer avec, mais je ne peux pas imaginer faire un projet non trivial dans cette langue.

Être puissant n'implique pas nécessairement une utilisation généralisée. Avez-vous entendu parler du terme «Optimiser pour le cas commun»? Malheureusement, comme beaucoup l'ont dit auparavant, la médiocrité, si elle est assurée systématiquement, est bien meilleure pour les gens que les grands succès qui comptent de nombreux échecs.

Ce n'est pas juste le cas avec Lisp, mais avec beaucoup de technologies. Un bon contact avec les outils de traitement de texte Unix, awk, sed, perl peut vous faire économiser des jours de programmation. Malheureusement, j'ai vu des gens passer des jours à faire ce genre de tâches dans d'autres outils, ce qu'ils auraient pu faire avec ces outils plus efficacement en quelques minutes. Mais si l’on passe toute sa vie dans une éclipse, il n’arrivera jamais à apprécier la valeur de ces choses. Vous pouvez écrire un programme énorme avec lisibilité et facilité de maintenance et tout le reste, mais quel que soit le but de l'écriture d'un tel programme sans l'écrire, il aurait facilement pu faire le travail.

Un autre aspect de la conception des outils actuels est combien il est utile de les utiliser directement pour résoudre un problème. Vous ne pouvez pas construire quelque chose de trop générique et ensuite vous dites que vous allez couvrir tout cela à travers des bibliothèques et des frameworks. C’est un peu difficile de résoudre ce problème de la sorte. Un bon outil convient parfaitement à l’environnement et aux problèmes qui l’entourent. C’est pourquoi des outils tels que php, perl et awk continuent d’être pertinents malgré les interminables attaques, car ils sont trop utiles pour les jeter et font souvent beaucoup plus de travail qu’un langage général avec de nombreuses bibliothèques et frameworks encombrés.

De même, vous verrez que des langages comme Java / Python sont très bons et je dirais mieux pour certaines tâches. Python en particulier est très bon et facile à apprendre et à écrire. De plus, ces langues font vraiment du bien si vos points d'extrémité de données sont standard. Une sorte de base de données ou un fichier XML ou des données de ce type. Données fondamentalement structurées.

Lisp sera là pendant longtemps, mais pas nécessairement largement. Comme vous le verrez, chaque outil a sa place. Et ils résolvent très bien certains problèmes en sortant de la boîte. Je pense et je suis sûr que Lisp se débrouille bien dans les domaines et les problèmes pour lesquels il est conçu pour résoudre correctement.

Pour le développement Web avec des dialectes Lisp, il peut y avoir un problème d’œuf et de poule - parce que peu de gens utilisent Lisp, les hôtes ne le permettent pas ou ne facilitent pas les choses, et parce que ce n’est pas facile, peu de gens utilise le. Mais en réalité, faire fonctionner Lisp sur un hôte peut être plus facile que vous ne le pensez, même si cela nécessite un peu plus de travail que ne le nécessite leur service PHP prêt à l'emploi. J'ai récemment eu fraude Scheme applications fonctionnent ici avec juste un peu d' effort.

OMI, c’est surtout un problème de timing: Lisp était vieux (et par définition n’était plus excitant) bien avant qu’il devienne pratique pour la plupart des gens ou pour d’autres utilisations. Clojure (pour un exemple) a de bien meilleures chances. Son succès dépendra beaucoup plus du fait qu’il sera perçu comme nouveau, à la mode et cool que tout ce qui est aussi pratique que l’interopérabilité avec Java (et tout ce qui se passe sur la JVM).