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

50

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.

Andrea
la source
3
xkcd2.heroku.com/297
Michelle Tilley
5
Steel Bank (common) LISP est en réalité plus populaire que vous ne pouvez l’imaginer. Les macroprocesseurs de type LISP (par exemple, M4) sont également largement utilisés. Vous ne le verrez peut-être pas dans votre domaine de prédilection, mais c'est toujours là (pour le meilleur ou pour le pire).
Tim Post
8
Le récent tremblement de terre et le tsunami ont détruit l’usine de parenthèses au Japon. :-(
oosterwal
1
Quelle version de Lisp devrions-nous utiliser? Rappelez-vous que les dialectes Lisp sont plus ou moins incompatibles.
2
LISP (ou les dialectes de) sont utilisés partout. Par exemple, AutoLISP est un dialecte de LISP utilisé par Autocad en.wikipedia.org/wiki/AutoLISP ou EMACS en.wikipedia.org/wiki/Emacs_Lisp
Jaydee

Réponses:

69

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.

dbyrne
la source
25
L'objection sur la difficulté de trouver des programmeurs qualifiés est un peu un chien qui court derrière sa queue. Si Lisp était plus répandu, il serait plus facile de trouver de bons programmeurs.
Andrea
3
@Andrea C'est certainement vrai. Il est cependant plus difficile d’apprendre le feu follet, ce qui contribue également au problème. Je me rends compte que cela pourrait être un avis controversé, car de nombreux professeurs enseignent les schémas comme première langue.
dbyrne
9
Oui, APL est un excellent exemple de langage expressif. En outre, un bon exemple de la raison pour laquelle l'expressivité n'est pas la chose la plus importante;)
dbyrne
9
Je ne pense pas que cette définition exprime réellement ce que signifie expressif Personnellement, avant d'appeler un langage expressif, je m'assurais de pouvoir lire ce que j'ai écrit. Par exemple, l'utilisation d'une logique non triviale dans l'initialiseur de boucle en C peut vous faire économiser des lignes de code, mais cela n'est pas facilement compréhensible. D'autre part, une compréhension de liste en Python peut économiser quelques lignes et être plus lisible. Vous avez donc trouvé le moyen d’exprimer ce que vous vouliez dire de manière plus concise. Si ce n'est pas lisible, vous n'avez pas trouvé le moyen d'exprimer quoi que ce soit.
Andrea
3
Je pense que je suis peut-être devenu quelqu'un qui n'aime pas le lisp. En vérité, je l'aime. Clojure est une langue incroyable. Je pense que c’est un choix très viable pour un certain type d’entreprise. Je souligne simplement qu'il y a beaucoup d'entreprises où cela n'aurait aucun sens, et utiliser quelque chose comme Scala est un choix beaucoup plus pratique.
dbyrne
17

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, ...)

Jörg W Mittag
la source
3
Là où j'habite (Italie), je doute qu'une seule société Lisp existe ...
Andrea
1
Quelles grandes entreprises poussent Ruby, Python et JavaScript? JS est certes un cas à part, mais les deux autres semblent être très populaires sans un soutien massif des entreprises et des fournisseurs
Ben Hughes
Oui, c'est vrai aussi pour les autres langues. La plupart des bons codeurs COBOL ont déjà des emplois et ne lisent pas les annonces de toute façon. Pourquoi embêter la publicité?
Bo Persson
Quoi vraiment? Je coderai dans n’importe quelle langue qui ne soit pas courante, même si Haskell me dépasse. La petite quantité de code que j'ai codée est extrêmement belle, mais sans un bon mentor, je ne sais pas quand utiliser chaque Monade et les foncteurs applicatifs.
aoeu256
9

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.

Jsternberg
la source
1
PLT Racket (anciennement PLT Scheme) fonctionne bien sous Linux et Windows.
Larry Coleman
Intéressant, je m'attendrais à ce que Common Lisp soit beaucoup plus standard et utilisable pour des applications réelles que Scheme. (Je lis Practical Common Lisp en ce moment.)
Giorgio
Je vous félicite d'avoir choisi Haskell (qui est une meilleure langue à mon avis), mais qu'en est-il de Clojure? Il fonctionne sur la machine virtuelle Java. Il doit donc être portable et avoir accès à toutes les bibliothèques dont vous avez besoin.
Andres F.
Les arguments de ligne de commande sont difficiles à utiliser en C ++? Vraiment?
Nick Keighley
N’est-il pas trivial de construire un système de compatibilité croisée qui change Lisp en Scheme en Clojure? Pourquoi les gens ne les utilisent-ils pas?
aoeu256
8

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.

donkey_lz
la source
1
"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 gens habitués à Eclipse et à Visual Studio.": Encore et encore, j'ai l'impression que Lisp est réservé à une élite.
Giorgio
2
"Vous devez également apprendre à travailler et à penser de manière totalement différente. Si cela est acceptable si vous le pratiquez à titre de loisir, on peut se demander si cela vaut la peine de le faire dans une entreprise." assez bonne raison?
Giorgio
Cette "productivité accrue" a-t-elle été démontrée? Ce n'est certainement pas clair pour moi (oui, j'ai programmé dans un dialecte Lisp). Il n'y a pas de balles d'argent.
Nick Keighley
5

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.

Andy Canfield
la source
7
La résolution de problèmes est tout ce que nous faisons. Manipuler des données n'est pas facile en Java ou en C. Manipuler des données dans des cellules est beaucoup plus facile avec Lisp et d'autres langages fonctionnels. La plupart des opérations sur les données sont exactement les mêmes et peu importe l'ordre dans lequel vous les traitez. Elles se font facilement avec un appel à la carte et un pointeur de fonction. Je dirais également qu'il est plus facile de penser à une fonctionnalité imbriquée qu'à une fonctionnalité procédurale (l'une détaillant votre objectif et l'autre expliquant comment atteindre ledit objectif), mais je n'ai aucune preuve de cela. Quoi qu'il en soit, je ne dirais pas que c'est la raison pour laquelle LISP n'est pas utilisé.
Jsternberg
4
La programmation ne concerne pas la résolution de problèmes? Je ne pense pas. Et au fait, je ne pense pas non plus que vous puissiez apprendre une langue au collège.
Adam Arold
+1, cela semble très plausible pour moi qui ne connais aucun Lisp. Je dirais la même raison pour laquelle C / Java est meilleur que Python pour les solutions d'entreprise.
Jonas Byström
C’est la seule réponse jusqu’à présent qui ait soulevé l’énorme sujet de la fonctionnalité et de la procédure, mais n’oublions pas que la pensée procédurale a tendance à plaire aux bricolages de données dans des vars partout où vous pouvez toucher à partir de nombreux endroits et threads, ce qui crée des problèmes de synchronisation. Fonctionnel ne souffre pas aussi rapidement de cela, fonctionnel bien écrit ne souffre pas du tout.
Maxpolk
1
Un programmeur m'a déjà demandé quel était le meilleur moyen d'exprimer une boucle for en utilisant un diagramme de flux de données. Pour de telles personnes, les langages non procéduraux sont inutiles. La pensée en Fortran.
Nick Keighley
5

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.

CodexArcanum
la source
2
Common Lisp, du moins, est explicitement un langage OO: le système d'objets Lisp commun fait partie de la norme.
Frank Shearar
C'est vrai, et si je comprends bien, c'est très puissant, mais cela me semble être une caractéristique secondaire du langage. Ce n'est pas comme Java où il est nécessaire de comprendre les objets dès le premier jour. Practical Common Lisp ne touche au CLOS qu'au chapitre 16. Je peux aussi être enclin à privilégier le typage statique, bien que je n'aime pas les langages à typage dynamique. .
CodexArcanum
Lisp vous permet d’utiliser des fermetures (let-over-lambda) au lieu d’objets pour une POO légère, mais j’estime qu’il est facile de passer à la POO via CLOS.
aoeu256
2

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.

6502
la source
+1 pour "Je pense que la solution au problème de la complexité réside dans des outils et une éducation puissants."
Giorgio
Après 50 ans, l'excuse de "l'ignorance" est plutôt mince
Nick Keighley
1
@ NickKeighley: dépend. Même aujourd'hui, la plupart des programmeurs ne savent vraiment rien de Lisp (par exemple, la plupart du temps, Lisp est décrit comme un langage fonctionnel). Même parmi ceux qui "connaissent" Lisp, presque personne n’a jamais vu l’idée macro avec suffisamment de détails (je ne parle pas de la version simplifiée du schéma, mais de la puissance algorithmique complète avec la commodité de quasi-cotation lorsque cela convient mieux).
6502
@ 6502: Bien qu'il ne soit pas purement fonctionnel, IMO Lisp supporte beaucoup mieux la programmation fonctionnelle que de nombreux langages traditionnels tels que C #, Java, C ++, etc. Pour beaucoup de programmeurs, FP signifie simplement utiliser une expression lambda de temps en temps: ces programmeurs ne manqueront pas Lisp, Clojure ou Haskell. J'ajouterais donc que (1) Lisp supporte assez bien la PF et que les programmeurs fonctionnels en profiteraient, mais (2) l'ignorance à propos de la PF et ses avantages sont l'une des raisons pour lesquelles Lisp n'est pas utilisé plus souvent.
Giorgio
1
@ 6502: Avoir des listes comme structure de données de base et les fonctions habituelles d'ordre élevé sur les listes est également une fonctionnalité qui manque en Javascript. Et, autant que je m'en souvienne, Javascript possède également la déclaration / expression de la dualité. Je placerais certainement Lisp (Common Lisp) quelques pas plus loin dans la direction de FP que Javascript ou Python. Par cela, je ne veux pas dire que Common Lisp est un langage purement fonctionnel, je conviens que c'est un multi-paradigme, mais il supporte la PF beaucoup mieux que d'autres langages multi-paradigmes.
Giorgio
1

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.

Nemanja Trifunovic
la source
2
Ce n'est plus vrai. Quicklisp a résolu ce problème.
2
Il est également intéressant de noter qu'avec CFFI, toute bibliothèque C peut être utilisée à partir de Common Lisp. CFFI est bien documenté et fonctionne bien. Par contre, si passer quelques heures à écrire des wrappers pour les fonctions C a un impact majeur sur votre projet, Lisp n’est probablement pas le bon choix.
Larry Coleman
J'ai fait un projet non-trivial dans Scheme et connais une société qui utilise Scheme (Chicken Scheme) pour plusieurs produits.
Giorgio
1

Ê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.

kamaal
la source
+1 pour citer le principe "Optimiser pour le cas commun".
Giorgio
Oui, mais les fermetures de LISP sont une optimisation pour le cas courant des objets. Je me demandais également si quelqu'un modifiait sa base de code LISP en le considérant comme un arbre et en exécutant des requêtes telles que JQuery pour HTML.
aoeu256
1

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.

Gcbenison
la source
0

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).

Jerry Coffin
la source