Utiliseriez-vous (un dialecte de) LISP pour une application réelle? Où et pourquoi? [fermé]

31

LISP (et les dialectes tels que Scheme, Common LISP et Clojure) n'ont pas gagné beaucoup de soutien de l'industrie même si ce sont des langages de programmation assez décents. (Pour le moment, il semble qu'ils gagnent du terrain).

Maintenant, ce n'est pas directement lié à la question, qui utiliseriez-vous un dialecte LISP pour un programme de production? Quel genre de programme et pourquoi? Les utilisations du type d'être intégré dans un autre code (par exemple C) sont également incluses, mais notez que c'est ce que vous voulez dire dans votre réponse. Les concepts généraux sont préférés, mais les applications spécifiques sont également acceptables.

Anto
la source
6
Emacs compte-t-il comme une application "du monde réel"? gnu.org/software/emacs/emacs-lisp-intro
S.Lott
1
@ S.Lott: Oui. Si vous utilisez elisp pour créer des extensions pour Emacs, ça va et une application d'un dialecte LISP
Anto
GNU Guile est destiné exactement à cette fin.
1
Bien qu'intéressant, je ne pense plus que cette question soit adaptée à ce site. Plusieurs raisons: 1- trop large, 2- elle invite à une liste de réponses, 3- pas de moyen clair de décider quelle est la "bonne" réponse, 4- trop localisée dans le temps ("n'a pas gagné beaucoup de soutien de l'industrie"), 5- il invite à la discussion et au débat.
Andres F.

Réponses:

18

Souhaitez-vous utiliser un dialecte LISP pour un programme de production?

Absolument

Quel genre de programme et pourquoi?

Lisp est un langage dynamique à usage général. Aujourd'hui, il a les mêmes difficultés de base que les autres langages dynamiques à usage général qui ne sont pas publiés par Microsoft: threads natifs, intégration GUI, fonctionnement déterministe du GC et petites empreintes de mémoire.

Les threads natifs sont réalisés par LispWorks et SBCL, je crois. Peut-être d'autres? Je n'ai pas enquêté complètement.

LispWorks et Franz Common Lisp - produits commerciaux - s'intègrent dans l'interface graphique à des degrés de réussite. N'ayant pas le $$ pour les acheter, je ne sais pas comment ça marche. Je pense qu'ils fonctionnent assez bien ...

Une opération GC déterministe peut être effectuée (elle est effectuée en Java avec un certain niveau de succès), mais je ne sais pas si les systèmes Lisp existants (maintenus) ont du code pour le faire.

Je crois que la petite empreinte mémoire est atteinte par certains Lisps.

Mon point de base est que Common Lisp est techniquement prêt à fabriquer des systèmes de production. Et c'est le cas .

La grande majorité des développeurs sont flippés par (en choisir un) les langages dynamiques, les macros, les parenthèses, le manque d'IDE préféré, la mauvaise expérience au collège, peu d'emplois, puis ne l'utilisent pas.

Personnellement, je sauterais sur la construction d'un système de production à part entière en Common Lisp à partir de zéro dans un environnement d'équipe.

edit: Je n'ai pas vraiment répondu pourquoi Lisp par opposition aux autres langues.

Dans mon expérience Lisp - pas significatif, mais beaucoup plus que «bonjour le monde» - j'ai trouvé que la langue était extrêmement utilisable après les premières douleurs de «Argh new language». La majorité de la langue s'assemble de manière très régulière et assez évidente, je ne trouve pas vraiment d'autres langues comme celle-ci. Cela tient en partie à la fusion d'expressions et d'instructions. Une partie de cela est le type de données de la liste principale. Une partie de cela est le système de type. Une partie de cela est le système macro. Ne vous méprenez pas, cependant, il y a des points douloureux. Mais ils ne me frappent pas autant au visage que les points douloureux des autres langues.

Un exemple simpliste est la routine de longueur de liste de Python. L'approche Python consiste à appeler len(mysequence). Mais, si on y réfléchit, une longueur est une propriété d'une séquence. C'est donc mysequence.len()une idée plus appropriée. Lisp supprime essentiellement cette distinction syntaxique. (length thing)est à la fois la syntaxe d'appel de fonction et la syntaxe de méthode. Bien sûr, certaines personnes trouvent cela frustrant et veulent la différence syntaxique. Je préfère avoir la régularité.

edit2: J'ai converti la partie de ma thèse MS qui s'exécute sur le bureau en Common Lisp et ça a été un plaisir de travailler jusqu'à présent.

Paul Nathan
la source
2
D'après ce que j'entends, LISP est utilisé dans des systèmes de production à part entière, mais généralement uniquement pour certains traitements logiques plus faciles à coder dans LISP que dans d'autres langages. L'IA de jeux vidéo et le prétraitement des données statistiques ont été des exemples qui m'ont été cités. J'ai eu une fois un manager qui avait un dicton: "Tout système suffisamment complexe a une implémentation LISP semi-intégrée intégrée". Un dicton similaire était "Tout système suffisamment gonflé a un lecteur de courrier électronique intégré".
FrustratedWithFormsDesigner
4
@Frustré: Oui, ce sont la nième loi de Greenspun et la loi de jwz.
Paul Nathan
2
Beaucoup de ces problèmes sont résolus par Clojure, simplement parce qu'ils sont spécifiquement conçus pour être compatibles avec et remplacer Java. Mais bien sûr, il existe également des implémentations Scheme et CL pour la JVM (par exemple Kawa, ABCL).
Jörg W Mittag
4
Clojure m'agace vaguement parce que c'est encore une autre fragmentation.
Paul Nathan
la fragmentation n'est pas une mauvaise chose. Ce qui est vraiment ennuyeux à Clojure, c'est le manque de paires en pointillés. Peut-il être considéré comme un langage de type Lisp sans une chose aussi fondamentale?
SK-logic
11

Je connais personnellement des personnes utilisant Lisp sous la forme de Clojure dans quelques banques d'investissement et startups à Londres. J'ai également choisi Clojure comme langage de développement principal pour ma propre startup, donc je suis prêt à mettre mon argent là où ma bouche est :-)

J'ai trouvé que c'était une expérience très enrichissante d'apprendre Clojure au cours de la dernière année (après beaucoup d'expérience avec Java et C #). Les principales raisons en sont:

  • Il met un fort accent sur la programmation fonctionnelle (plus que la plupart des autres Lisps). L'auteur et BDFL Rich Hickey a fréquemment cité Haskell comme l'une de ses inspirations pour la conception du langage, ce qui signifie que vous obtenez des choses comme des structures de données entièrement immuables et des séquences infinies paresseuses, etc.
  • Métaprogrammation de macros - la philosophie Lisp "code is data" est difficile à comprendre à moins que vous ne l'ayez réellement expérimentée, mais c'est l'une des raisons pour lesquelles Lisps est si expressif et productif. Vous avez essentiellement le pouvoir d'étendre la langue pour qu'elle corresponde à votre domaine problématique.
  • Prise en charge fantastique de la concurrence multicœur - je pense que Clojure est le meilleur langage pour la programmation simultanée en ce moment. Voir http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey pour une présentation éclairante à ce sujet
  • Le développement interactif au REPL est un excellent moyen productif de créer des applications. Il vous donne un réel sentiment de puissance pour modifier dynamiquement votre code d'application en cours d'exécution et inspecter par programme les structures de données en direct .....

Il semble également être un choix pratique pour une utilisation en production réelle pour les raisons suivantes:

  • L'exécution sur la machine virtuelle Java avec une interopérabilité Java très simple vous donne accès à toutes les bibliothèques et outils de l' écosystème Java
  • Vous utilisez la JVM, une plate-forme éprouvée pour les applications d'entreprise. Clojure bénéficie gratuitement de toutes les fonctionnalités intéressantes de la JVM, comme l'excellente compilation GC et JIT.
  • C'est un langage dynamique par défaut, ce qui le rend très pratique pour le développement et le prototypage rapide avec pratiquement aucun passe-partout. Cependant, vous pouvez ajouter des indications de type statique pour obtenir de très bonnes performances là où vous en avez besoin.
  • C'est une communauté pragmatique et serviable - le genre de culture où les gens font avancer les choses et où l'accent est mis sur des solutions bien conçues qui résolvent de vrais problèmes
  • Il existe une prise en charge d'outils dans plusieurs IDE . Personnellement, j'utilise Eclipse avec le plugin Counterclockwise (car j'ai besoin de l'intégration Java) mais il y a beaucoup d'autres options.
Mikera
la source
8

J'utiliserais LISP si c'était le meilleur choix pour le travail. Juste quelques éléments qui influencent le "meilleur choix":

  • assistance aux fournisseurs. L'implémentation LISP que nous utilisons - si quelque chose ne va pas et interfère avec notre développement et donc nos délais, le vendeur travaillera-t-il vers une solution avec nous?
  • prise en charge de la bibliothèque. Quelles bibliothèques sont disponibles? Manipulation de chaînes, mathématiques, accès aux données, servlets Web (ou équivalents LISP), boîte à outils de fenêtrage, etc ... Je ne veux pas avoir à écrire ce truc à partir de zéro.
  • support d'outils - Quelle est la qualité de l'IDE? Solide / stable ou feuilleté? Bon support éditeur? Débogueur intégré? Si je dois faire du développement graphique dans LISP, y a-t-il un IDE visuel ou dois-je coder la disposition de l'interface graphique à la main (je déteste faire ça).
  • l'adhésion des développeurs (je ne veux vraiment pas avoir à passer trop de temps à enseigner à mes coéquipiers une toute nouvelle langue)

Tous ces facteurs doivent être pris en compte pour décider si le LISP est approprié pour un projet. Dans le monde de l'entreprise, je ne l'ai jamais vécu.

FrustratedWithFormsDesigner
la source
Je suis d'accord avec vous que la productivité est souvent plus influencée par les outils et bibliothèques disponibles que par le langage lui-même (à condition que le langage offre certaines fonctionnalités de base).
Giorgio
6

Absolument. Paul Graham l' explique bien .

... En 1995, nous savions quelque chose que je ne pense pas que nos concurrents aient compris, et peu de gens le comprennent encore: lorsque vous écrivez un logiciel qui ne doit s'exécuter que sur vos propres serveurs, vous pouvez utiliser la langue de votre choix. ..

Nous avons choisi Lisp. D'une part, il était évident qu'un développement rapide serait important sur ce marché. Nous partions tous de zéro, donc une entreprise qui pourrait obtenir de nouvelles fonctionnalités avant ses concurrents aurait un gros avantage. Nous savions que Lisp était un très bon langage pour écrire rapidement des logiciels, et les applications basées sur serveur amplifient l'effet d'un développement rapide, car vous pouvez publier des logiciels dès qu'ils sont terminés.

Si d'autres entreprises ne voulaient pas utiliser Lisp, tant mieux. Cela pourrait nous donner un avantage technologique, et nous avions besoin de toute l'aide que nous pouvions obtenir ...

On pourrait donc dire que l'utilisation de Lisp était une expérience. Notre hypothèse était que si nous écrivions notre logiciel en Lisp, nous pourrions obtenir des fonctionnalités plus rapidement que nos concurrents, et aussi faire des choses dans notre logiciel qu'ils ne pouvaient pas faire. Et parce que Lisp était si haut niveau, nous n'aurions pas besoin d'une grande équipe de développement, donc nos coûts seraient plus bas. Si tel était le cas, nous pourrions offrir un meilleur produit pour moins d'argent, tout en faisant des bénéfices. Nous finirions par obtenir tous les utilisateurs, et nos concurrents n'en obtiendraient aucun, et finiraient par faire faillite. C'est ce que nous espérions de toute façon.

Quels ont été les résultats de cette expérience? De façon assez surprenante, cela a fonctionné. Nous avons finalement eu de nombreux concurrents, de l'ordre de vingt à trente, mais aucun de leurs logiciels ne pouvait rivaliser avec le nôtre. Nous avions un constructeur de boutique en ligne wysiwyg qui fonctionnait sur le serveur et qui ressemblait pourtant à une application de bureau. Nos concurrents avaient des scripts cgi. Et nous étions toujours loin devant eux en termes de fonctionnalités. Parfois, en désespoir de cause, les concurrents tentaient d'introduire des fonctionnalités que nous n'avions pas. Mais avec Lisp, notre cycle de développement était si rapide que nous pouvions parfois dupliquer une nouvelle fonctionnalité en un jour ou deux d'un concurrent l'annonçant dans un communiqué de presse. Au moment où les journalistes couvrant le communiqué de presse se mettaient à nous appeler, nous aurions également la nouvelle fonctionnalité.

Il a dû sembler à nos concurrents que nous avions une sorte d'arme secrète - que nous décodions leur trafic Enigma ou quelque chose du genre. En fait, nous avions une arme secrète, mais c'était plus simple que ce qu'ils pensaient. Personne ne nous a fait part de leurs caractéristiques. Nous avons juste pu développer des logiciels plus rapidement que quiconque ne le pensait possible ...

Kevin Cline
la source
8
"... Paul Graham a écrit à l'origine reddit, en lisp, sur le dos d'une serviette pendant qu'il attendait un café. Il était si puissant qu'il devait être réécrit en python juste pour que les ordinateurs ordinaires puissent le comprendre. Parce qu'il a été écrit en lisp il n'y avait presque aucun effort pour réécrire le tout, et la réécriture s'est terminée entre deux cycles de processeur. Paul Graham lui-même a été complètement écrit en lisp, par une version antérieure de lui-même, également écrite en lisp, par un version antérieure de lisp. C'est lisp, paul graham, lisp, paul graham, tout en bas. "
John Cartwright
5

Où: Emacs est une application du monde réel qui utilise LISP.

Pourquoi: C'était un excellent moyen d'exprimer la correspondance entre la frappe et l'action. C'est interprété et c'est rapide et c'est bien défini et c'est simple.

S.Lott
la source
Je voudrais étendre cette réponse en disant pourquoi c'était bon pour exprimer la correspondance entre les frappes et les actions
Anto
@Anto: D'après mon expérience, Lisp facilite la création d'abstractions puissantes qui peuvent représenter de manière transparente toutes les actions que vous pouvez effectuer dans un éditeur de manière très cohérente - après avoir utilisé Emacs pendant un moment, vous pouvez deviner comment presque tout est fait . Cela permet de mapper tout ce que vous pouvez faire dans l'éditeur à un coup de clé, chaque liaison ressemblant vraiment à l'autre, ce qui la rend plus facile à écrire et à entretenir.
Tikhon Jelvis
4

Les deux Macsyma et Autocad sont basées sur un dialecte de Lisp. Je les classerais aussi bien dans le «monde réel» que dans Emacs.

Joris Geer
la source
Mathematica n'est pas basé sur Lisp.
Rainer Joswig
2
AutoCAD propose AutoLISP en tant qu'API mais il est écrit en code managé C ++ & .NET.
CAD bloke du
1
@RainerJoswig Macsyma était probablement destiné à la place de Mathematica.
user40989
2

Je le considérerais absolument. Surtout pour les nouveaux travaux de développement qui avaient un certain potentiel de calcul parallèle. Cela semble être un point idéal pour ces types de langages fonctionnels.

Dave Kincaid
la source
2

Lisp est l'un des meilleurs choix pour implémenter des compilateurs. Et, comme l'utilisation des DSL et des eDSL augmente maintenant, Lisp gagne en valeur. J'utilise un dialecte Lisp pour toutes mes tâches liées à DSL.

SK-logic
la source
0

En ce moment, j'essaie d'utiliser newLisp en remplacement de Php sur mon site Web personnel via le framework Dragonfly . Si je peux comprendre comment faire en sorte qu'Apache fonctionne correctement, je vais l'utiliser (le serveur Web intégré fonctionne très bien, mais je préfère de loin travailler avec Apache). Et une fois que cela se produira, j'utiliserai newLisp partout où j'utiliserais Php, car je n'aime pas Php et j'aime newLisp.

Pour le moment, Clojure n'est pas un bon choix pour les applications Android, mais je sais que les gens y travaillent. Donc, si cela est compris, ce serait un autre endroit où j'utiliserais un dialecte de Lisp pour des applications du monde réel ... mais encore une fois, c'est parce que je n'aime tout simplement pas Java.

Mais honnêtement, je préfère Ruby à Lisp ... mais c'est surtout une question de communauté et de documentation.

philosodad
la source
0

J'ai implémenté une application commerciale propriétaire en Common Lisp appelée Tankan qui s'exécute sur Microsoft Windows en tant qu'exécutable natif.

C'est un programme pour vous entraîner à mémoriser des caractères kanji japonais.

Le programme fonctionne comme un serveur HTTP en arrière-plan. L'exécution de ce serveur et la navigation vers ses pages sont coordonnées par une minuscule application d'icône de zone de notification système (aka "Tray") que j'ai développée en utilisant Visual C ++.

L'application d'icône de minuscule plateau démarre, surveille et arrête le serveur basé sur Lisp et communique avec lui à l'aide de canaux Win32 liés à ses entrées et sorties standard. Par le biais d'un canal, le serveur Lisp informe l'application d'icône de plateau de l'URL précise avec le bon numéro de port, et cette application d'icône de plateau peut lancer le navigateur via l'API Shell pour parcourir cette URL. L'utilisateur double-clique simplement sur l'icône pour afficher l'interface utilisateur.

Le programme Lisp conserve en mémoire un état de session assez complexe qui contient l'historique des entrées de l'utilisateur et diverses relations entre divers objets. La notation des objets circulaires de Lisp (activée par la *print-circle*variable) et son fonctionnement dans les print-objectméthodes CLOS personnalisées sont d'une aide précieuse dans la mise en œuvre de la persistance: les utilisateurs peuvent enregistrer l'état sur le disque et reprendre là où ils se sont arrêtés. Tout est enregistré, y compris l'état de l'interface utilisateur. Il y a beaucoup de sous-structure partagée dans le graphique d'objet, ainsi que des cycles. De plus, beaucoup de dépouille statique qui ne doit pas être persistée, comme le contenu des objets d'entrée de dictionnaire. Avec les méthodes d'objet d'impression personnalisées Common Lisp ANSI, vous pouvez créer des représentations imprimées condensées pour des objets qui sont néanmoins lisibles par machine,

Presque aucun JavaScript n'est utilisé dans l'interface utilisateur Web. Même les contrôles pour masquer et afficher des parties de l'interface utilisateur sont effectués par la soumission de formulaires et le rendu du HTML. Chaque détail de l'état de l'interface utilisateur se trouve donc dans le serveur et persiste lorsque l'utilisateur enregistre. La régénération du HTML est très rapide. Cela est fait par une expression de guillemet arrière Lisp géante qui alimente une macro générant du HTML. Le code compilé par Clozure Common Lisp (CCL) rend cela si rapide que vous n'êtes presque pas conscient que lorsque vous cliquez sur un bouton [+] sur l'interface utilisateur pour ouvrir quelque chose, vous soumettez une demande à un serveur qui régénère le toute la page sacrée, et pas simplement exécuter du JavaScript local pour changer la visibilité d'un élément de document local.

Le programme a été initialement développé avec CLISP. Merci à ANSI CL étant un langage standard, avec des implémentations qui se conforment bien et pas trop d'embûches sournoises dans le langage (comportement "non défini" ou "défini par l'implémentation"), il est assez facilement porté sur CCL.

CLISP n'a pas été abandonné; il est toujours utilisé pour alimenter le back-end de licence, en utilisant la même base de code commune.

J'ai développé un système de licence original pour le programme, en utilisant la cryptographie à courbe elliptique fournie par la bibliothèque IronClad, qui est utilisée par le serveur de licences pour signer les licences pour les certifier. (Il semble que je me souvienne que j'aurais pu utiliser le programme de ligne de commande d'OpenSSL pour générer les paramètres EC pour la clé de serveur.)

Les licences sont représentées comme des objets Lisp. C'est un hommage à la portabilité Lisp qu'un programme Windows compilé par Clozure Common Lisp peut générer une licence basée sur l'expression S, un programme CLISP exécuté sur un serveur Debian peut remplir le champ de signature numérique manquant dans cet objet et le renvoyer à le programme Windows qui peut valider la signature.

Sur le serveur, en plus du service de licence basé sur CGI, je API de ligne de commande simple pour gérer les licences. Vous pouvez répertorier les licences, en trouver des spécifiques et modifier leurs attributs: comme par exemple la modification de la date d'expiration d'une licence temporaire pour accorder une exception à un utilisateur. Le back-end de licence génère également des e-mails. Je n'ai pas utilisé de bibliothèque pour la gestion CGI côté serveur: juste du code Lisp roulé à la main pour gérer les variables d'environnement Apache et les arguments de ligne de commande. (Bien que le code de bibliothèque soit utilisé pour gérer l'encodage d'URL et la génération HTML.) Aucune base de données n'est utilisée pour le stockage; les licences sont cataloguées dans un fichier appelé licenses.lispet c'est tout.

Kaz
la source
-1

Si quelqu'un me payait, bien sûr.

Ils seraient probablement plus intéressés à payer quelqu'un qui connaît la langue. Je n'ai joué avec elisp et schema que quelques fois.

Edward Strange
la source