Pourquoi LISP n'est-il pas plus répandu?
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 elle disent qu'elle a 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 à la place, il est presque impossible de trouver, par exemple, des offres d'emploi LISP.
J'espère que ce n'est pas seulement la parenthèse, car ce n'est pas un gros problème après un petit moment.
L'expressivité n'est pas toujours un trait de langage positif dans un environnement d'entreprise. Java est extrêmement populaire en partie parce qu'il est facile à apprendre, à é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 expert Java peut refactoriser rapidement du code mal écrit. Plus le langage est expressif, plus la compréhension et la refactorisation du code horrible deviennent difficiles. Les macros LISP en sont un bon exemple. Les macros sont de puissants outils à droite Entre de mauvaises mains, elles peuvent entraîner un code déroutant et difficile à déboguer.
LISP est un choix risqué pour la haute direction. Si les choses tournent mal, personne ne blâmera la direction d'avoir choisi un langage orienté objet populaire soutenu par une grande entreprise comme Oracle ou Microsoft. Il est beaucoup plus facile d'embaucher des programmeurs ayant de l'expérience dans des langues populaires et faciles à apprendre.
Même les entreprises progressistes désireuses d'utiliser un langage plus puissant ne choisissent généralement pas LISP. En effet, de nombreuses langues plus récentes essaient de faire des compromis en empruntant des fonctionnalités puissantes à LISP, tout en restant faciles à apprendre pour les masses. Scala et Ruby suivez 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 en profiter des fonctionnalités les plus avancées pour écrire du beau code.
Les parenthèses ne sont pas le problème. Haskell est un langage incroyablement puissant et expressif avec une syntaxe similaire à Python ou Ruby et il n'a pas n'a pas été largement adopté pour bon nombre des mêmes raisons que LISP.
Malgré tout cela, j'espère ...
Clojure a une chance de devenir populaire. Il fonctionne sur la JVM, a une grande interopérabilité avec Java et rend la programmation simultanée beaucoup plus simple. Ce sont toutes des choses importantes pour de nombreuses entreprises.
* C'est mon point de vue en tant que programmeur JVM professionnel avec une expérience en Java, Clojure, JRuby et Scala.
Pourquoi le LISP n'est-il pas plus répandu? Si c'est vraiment aussi puissant, les gens devraient l'utiliser partout,
Si vous croyez que les langues sont choisies pour leurs mérites techniques, vous êtes dans une déception écrasante.
Ces décisions sont prises en fonction de Strippers And Steaks . Microsoft peut se les permettre. Oracle peut. Sun a dépensé tellement d'argent en faisant de la monnaie 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 entreprises 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 de travail pour une vraie entreprise, mais je sais pourquoi LISP a été difficile à utiliser.
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 "quelle LISP". Je travaille habituellement sur Linux comme plate-forme principale, mais les choses que je fais doivent être compatibles avec Windows. Cela signifie que lorsque j'évalue une technologie à utiliser, cela 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 langues qui ne prennent pas très bien en charge Windows pour mes propres projets personnels, mais comme je n'ai jamais la possibilité d'y écrire un grand 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 LISP commun. Cela semblait la bonne chose à faire. J'ai commencé à lire Practical Common LISP comme un 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 dans LISP. Les expressions S étaient belles et faciles. Toutes ces parenthèses étaient incroyablement belles pour moi car il était clair comme le jour exactement ce qui se passait dans le code.
J'essaie donc d'écrire mon premier programme en LISP en dehors du livre. Je voulais un outil de ligne de commande qui compterait les lignes de code et supprimerait les lignes triviales du nombre de codes. Pas l'outil le plus utile, mais amusant à faire. Cela implique l'accès aux fichiers, un peu d'analyse et de comptage. J'avais implémenté le même outil dans Python environ une semaine plus tôt.
J'ai besoin d'accéder aux arguments de la ligne de commande. Ensuite, j'apprends qu'il n'y a aucun moyen standard d'obtenir des arguments de ligne de commande. Ce sont toutes des fonctionnalités non standard. Ce n'est pas du tout multiplateforme. La plupart du temps, cela empire car le langage n'a pas beaucoup de bibliothèques intégrées. J'ai fini par passer à Haskell et je ne suis pas allé très loin dans Common LISP (donc mes plaintes peuvent même ne pas être valides).
Ce genre de chose non standard a toujours été une douleur pour moi dans le passé. C++ a ce 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 autre que les expressions S soit un peu moche.
OMI, c'est principalement dû à:
- Prise en charge médiocre de la bibliothèque. Bien sûr, il y a maintenant Quicklisp, ce qui facilite l'installation des bibliothèques, mais cela ne compense pas qu'elles soient encore assez peu nombreuses, et beaucoup sont mal documentées ou pas très bien entretenues. Par rapport à Python, il y a de fortes chances que l'écriture d'une application LISP non triviale (quel que soit le dialecte particulier) impliquera probablement de réinventer au moins une partie d'une roue ou deux.
- Manque de familiarité avec le modèle adopté par les outils de développement. La plupart des gens que je connais sont assez intimidés par le fait d'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 il y a quelques années et c'était assez buggé. L'ensemble de l'écosystème LISP semble être coincé à mi-chemin entre le jour où il faisait partie d'un système LISP à part entière et le standard moderne de oh-c'est-une autre langue. Apprendre LISP ne se limite pas à apprendre une nouvelle langue - vous devez également apprendre une façon complètement différente de travailler et de penser, et bien que ce soit bien si vous le faites comme un passe-temps, il est discutable s'il vaut la peine de le faire dans un Entreprise.
Les choses commencent à s'améliorer légèrement, surtout avec Clojure.
J'ai appris LISP il y a un milliard d'années au collège.
LISP, comme FORTH, est idéal pour la logique. Mais la plupart de la programmation ne concerne pas la logique, il s'agit de manipuler des données de manière mécanique ennuyeuse. Par exemple, à l'époque, il n'y avait aucun moyen de justifier à droite la sortie numérique.
LISP concerne les fonctionnalités imbriquées, et les gens ne pensent 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 prête à confusion. À l'exception des tâches prédéfinies comme "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 dominent aujourd'hui.
Par conséquent, le code produral liks Java et C peuvent être facilement traduits en anglais. Le code LISP ne peut pas; aucun langage humain n'est structuré de cette façon.
C'est donc idéal pour la résolution de problèmes, mais la résolution de problèmes n'est pas très importante dans la programmation. Saisie de données, validation, formatage de sortie, tout cela était très faible pour LISP.
Je pense qu'un problème avec LISP non encore mentionné est que pour un programmeur médiocre ou novice (comme moi, j'admets librement), il peut être difficile de voir comment vous transformez le code LISP en un gros programme. Il est facile à écrire mais difficile à concevoir. Je ne pense pas que l'un des concepts soit particulièrement difficile, mais la mentalité de bricolage est si forte que je me sens souvent perdu par où commencer.
Avec un langage OOP comme Java ou C #, vous pouvez utiliser le système de type pour vous propulser vers un modèle de travail 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 OOP, faites votre propre système OOP! Excepté de faire votre propre système La POO, ou l'apprentissage de quelqu'un d'autre, est une nouvelle barrière au-dessus de la langue avant d'obtenir des programmes utilisables. De plus, j'ai toujours l'impression que le OOP dans LISP ou Lua n'est pas vraiment là, comme je pourrait juste l'ignorer si je le voulais vraiment, alors à quoi ça sert?
En bref, je pense que la programmation dans LISP nécessite beaucoup de discipline, et c'est très difficile à trouver. Les langages fortement typés et les langages OOP offrent tous deux une sorte de discipline intégrée, de sorte que le programmeur peut concentrer ses réserves limitées sur la finition des projets au lieu de peaufiner le langage.
EDIT: Par analogie qui vient de me frapper, c'est comme si vous avez besoin de faire du bois et que deux personnes vous proposent leurs boîtes à outils. Les outils d'une personne sont plutôt minables, mais feraient essentiellement le travail avec un peu d'effort. L'autre personne a un grand bac de pièces, mais promet que vous pouvez combiner ces pièces pour fabriquer les meilleurs outils que vous aurez jamais utilisés, parfaitement adaptés à votre prise et de la meilleure qualité. Il vous suffit de les construire en premier.
Je me pose la même question depuis longtemps, et je suis même allé à des conférences LISP pour essayer de comprendre quel est ce "côté obscur" LISP qui empêche tout le monde de l'adopter.
Je n'ai trouvé aucune réponse décente complète.
L'ignorance peut être la raison de la popularité manquante, mais ce qui me dérange le plus, c'est que même ceux qui connaissent le LISP (par exemple, Google - Peter Norvig travaille pour eux) ne l'utilisent pas.
La seule explication partielle que je trouve est que la plupart des grandes idées LISP sont désormais monnaie courante, la seule qui manque vraiment (une IMO extrêmement importante) est la facilité de métaprogrammation.
Malheureusement, je ne vois pas de moyen facile d'adsorber ce concept pour d'autres langues car la métaprogrammation pour être agréable nécessite un langage homoiconique et régulier (je parle de métaprogrammation générale, pas de la version abrégée de modèle uniquement). En d'autres termes, cela nécessite essentiellement l'approche LISP de la syntaxe: le code est des données et les données sont du code. Écrire du code dans un langage riche en syntaxe qui manipule un AST est plus difficile car vous devez connaître deux langues: comment écrire le code et comment écrire l'AST. Ceci est particulièrement difficile si votre AST est fixe et également complexe et irrégulier avec beaucoup de types de nœuds différents. LISP a plutôt un format assez régulier (et extensible!) AST et vous avez déjà normalement code en écrivant directement l'AST.
La métaprogrammation est également intrinsèquement plus difficile (et méta-métaprogrammation encore plus et ainsi de suite) et la plupart des programmeurs et des gestionnaires préfèrent apparemment simplement la réponse "personne n'aurait besoin de cette".
Je trouve particulièrement triste que de "nouveaux" langages comme go aient fini par utiliser une métaprogrammation basée sur du texte quand cela est nécessaire (des générateurs de code externes écrivant des fichiers texte) et "magique" (c'est-à-dire que le compilateur peut faire ce que les programmeurs ne peuvent pas faire) .
Je pense que la solution au problème de la complexité sont des outils puissants et l'éducation. La tendance est apparemment plutôt émoussée et prétendre 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 certains schémas et j'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 avant la médiocrité, s'il est assuré de manière cohérente, c'est beaucoup mieux pour les gens que les gros succès avec de nombreux échecs entre eux.
Ce n'est pas seulement le cas avec LISP, mais avec beaucoup de technologies. Une bonne touche sur les outils de traitement de texte Unix, awk, sed, Perl peut vous faire économiser des jours de programmation. Malheureusement, j'ai vu des gens prendre des jours à faire ce genre de tâches dans d'autres outils mal ce qui aurait pu faire avec ces outils plus efficacement en quelques minutes. Mais si l'on passe toute sa vie à Eclipse, il ne pourra jamais apprécier la valeur de ces choses. Vous pouvez écrire un énorme programme avec lisibilité et maintenabilité et tout cela, mais quel est l'intérêt d'écrire un tel programme sans l'écrire aurait pu facilement faire le travail.
Un autre aspect lors de la conception d'outils de nos jours est combien ils sont utiles pour les utiliser directement pour résoudre un problème. Vous ne pouvez pas construire quelque chose de trop générique et dire ensuite que vous couvrirez tout cela à travers des bibliothèques et des frameworks. C'est un peu difficile de régler les choses de cette façon. Un bon outil se gélifie bien avec l'environnement et les problèmes qui l'entourent. C'est pourquoi des outils comme php, Perl et awk restent pertinents malgré la pêche à la traîne et le dénigrement sans fin, car ils sont trop utiles pour les jeter et souvent ils font beaucoup de travail qu'un langage général avec de nombreuses bibliothèques et frameworks boulonnés.
De même, vous verrez que les langages comme Java/Python sont très bons et je dirais que c'est 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 de terminaison de données sont standard. Une sorte de base de données ou un XML ou des données de ce type. Fondamentalement données structurées.
LISP sera là depuis longtemps, mais pas nécessairement répandu. Comme vous le verrez, chaque outil a sa niche. Et ils résolvent très bien certains problèmes dès le départ. Je pense et je suis sûr que LISP fait du bien dans des domaines et des problèmes pour lesquels il est bien conçu pour résoudre.
Pour le développement Web avec les dialectes LISP, il peut y avoir un petit problème de poulet et d'oeufs - parce que peu de gens utilisent LISP, les hôtes ne le permettent pas ou ne le rendent pas facile, et parce que ce n'est pas facile, peu de gens utilise le. Mais en fait, 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 leur service prêt à l'emploi PHP service le fait. J'ai récemment obtenu guile Les applications du schéma fonctionnent ici avec juste un petit effort.
OMI, c'est surtout une question de mauvais timing: LISP était vieux (et presque par définition plus excitant) bien avant qu'il ne devienne pratique pour la plupart des gens ou des utilisations. Clojure (par exemple) a de bien meilleures chances. Son succès dépendra beaucoup plus d'être perçu comme nouveau, à la mode et cool que quoi que ce soit aussi pratique que l'interopérabilité avec Java (et tout ce qui fonctionne sur la JVM) cependant.