Je vous propose de redécouvrir ce langage et d'oublier *tous* vos a priori. Common LISP est un langage énorme certes, mais qui vous permet de penser en vos termes, non par ceux dictés par votre langage.
Il existe plusieurs implémentations libres de Common Lisp: clisp, cmucl, sbcl. Essayez les!
Aller plus loin
- Guide to Lisp (167 clics)
- Beating the averages (33 clics)
- Lisp as an alternative to Java (59 clics)
- Myths and Legend (27 clics)
- Implémentations libres (73 clics)
# vive Lelisp ;)
Posté par dinomasque . Évalué à -1.
Evidemment, ce LISP foireux était un programme ... DOS ! qui ne fonctionnait que sous DOS (peut être un peu Win9X), pas Linux ou les windows récents.
Donc la standardisation du LISP, c'est bien sur le papier, mais dans les faits c'est du grand n'importequoi.
Sinon, j'encourrage tout le monde à faire du LISP ou du PROLOG au moins une fois dans sa vie : ca change complètement des langages "traditionnels", et ca force à adopter une logique de programmation complètement différente.
BeOS le faisait il y a 20 ans !
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à 10.
Ce n'est pas elisp qui est standardise mais "Common Lisp". Essayes de parler en connaissance de cause. Common Lisp est le dialecte LISP le + repandu.
[^] # Re: vive Lelisp ;)
Posté par Blackknight (site web personnel, Mastodon) . Évalué à -6.
De toutes façons, pour moi, ce ne sont que de mauvais souvenirs d'étudiants.
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à 2.
[^] # Re: vive Lelisp ;)
Posté par Guy Chovet . Évalué à 10.
Sinon je garde un souvenir ému de ce langage que je n'ai plus pratiqué depuis.
Savez vous ce que veut dire l'acronyme LISP ? Lot of Insipid and Stupid Parenthesis... ;-)))
[^] # Re: vive Lelisp ;)
Posté par Guillaume Rousse (site web personnel) . Évalué à 10.
Ou Lots of Irritating and Superfluous Parenthesis...
Bref il doit y en avoir presque autant que pour Emacs.
[^] # Re: vive Lelisp ;)
Posté par BoB . Évalué à -3.
[^] # Re: vive Lelisp ;)
Posté par Benjamin Michotte . Évalué à -2.
c'est normal, ils suxent tous les deux tout autant...
(chérie, ca va chier)
[^] # Re: vive Lelisp ;)
Posté par Moby-Dik . Évalué à -3.
Sans blague, les fichiers config d'Emacs c'est du Lisp, pas étonnant hein.
[^] # Re: vive Lelisp ;)
Posté par sToR_K . Évalué à -1.
Tu peux le faire tourner parfaitement sous GNU/Linux grace à dosemu.(apt-get install dosemu).
Effectivement, LeLisp appartient à l'INRIA, mais aucune trace du soft sur le site officiel, ni sources, ni binaire, et très peu de réponses sur google.
A priori, il n'existe pas de portage GNU/Linux de LeLisp :-(
Mais tu peux le faire tourner parfaitement grace à dosemu.(apt-get install dosemu).
[^] # Re: vive Lelisp ;)
Posté par Le_Maudit Aime . Évalué à 2.
Il faut de toutes façon une licence pour faire tourner lelisp.
[^] # Re: vive Lelisp ;)
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: vive Lelisp ;)
Posté par Denis Rampnoux . Évalué à 1.
Il y a environ 600 personnes chez Ilog dans le monde, et c'est le numéro un mondial du composant logiciel pour la visualisation et l'optimisation (cf www.ilog.fr)
[^] # Re: vive Lelisp ;)
Posté par Guillaume Laurent (site web personnel) . Évalué à -2.
[^] # Re: vive Lelisp ;)
Posté par Olivier M. . Évalué à 10.
Je suis tout à fait pour les langages "différents", mais à mon avis, le LISP est pas idéal. Surtout que tant qu'à aller chercher les langages maisons de l'INRIA, le CAML est bien plus moderne et adapté aux besoin de la programmation de tous les jours. :)
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à -3.
Qu'appelles tu les besoins de programmation de tous les jours? Donne une ou +sieurs bonne raison pour laquelle CL n'est pas adapte? En quoi perl, Java, CAML est plus adapte? En quoi CAML est plus moderne?
Affirmation gratuite. Toujours et encore.
[^] # Re: vive Lelisp ;)
Posté par Dugland Bob . Évalué à 10.
Lisp (et scheme et smalltalk) pêche par le typage dynamique : pour être sûr du typage il faut tester. Et les tests c'est exponentiel avec la croissance de l'application.
Maintenant, avoir un système self-réflexif statiquement typé ? j'ai entendu parler d'expériences smalltalk mais c'est tout. Peut-être caml s'en approche par camlp4 et le chargement dynamique de libs mais on est loin du compte. P4 offre un vrai système de macros sympa (je connais pas celui de lisp).
Il me semble difficile d'assurer la qualité sans typage fort statique (+contrats). Il me semble difficile d'avoir de l'expressivité et de la concision sans (au minimum) des closures correctes (squeak rentre chez toi) et des exceptions. Pour les closures : essayez de dégager la structure d'algèbre dans un langage sans closures pour factoriser avec le même code l'addition (en multiplication) et la multiplication (en puissance entière). Pour les exceptions : mattez comment on fait en C pour fermer un fichier quand on vient de découvir une erreur dans le traitement qu'on faisait dessus, c'est rarement top factorisé.
Certains pensent que les continuations sont importantes aussi mais je n'ai jamais utilisé.
Ca va c'est construit ?
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à -6.
Je n'ai pas parle de la famille LISP. Je parle de Common LISP. Common LISP est plus recent.
Effectivement, en 58 LISP n'avait que les symboles (quelqu'un peut peut-etre confirmer?) comme type de donnee. Le LISP d'antan a beaucoup change. le LISP d'aujourd'hui s'appelle Common LISP.
>pour être sûr du typage il faut tester. Et les tests c'est exponentiel avec la croissance de l'application.
Crois moi ou pas, je n'ai jamais eu besoin de tester le typage...Ce ne sont pas les objets qui sont types en CL, ce sont les valeurs.
De plus, tu as l'air d'impliquer que les developpements sont long quand tu n'as pas a specifier les types. Ton experience de la programmation m'epoustouffle.
[^] # Re: vive Lelisp ;)
Posté par Dugland Bob . Évalué à -6.
Il a été statiquement typé depuis 1958 (puisque c'est de ça dont je parlais) ? J'ai la flemme de vérifier mais même si c'est le cas, c'est pas compatible avec :
je n'ai jamais eu besoin de tester le typage
Mais aux dernières nouvelles, Lisp est toujours dynamiquent typé. Donc c'est bien une connerie que tu dis. Il n'a sûrement pas bénéficié de ce type d'amélioration. Et je ne crois pas que les amélioration de VM aient quelquechose à foutre dans une spec (puisque tu tien tant à parler de spec)
De plus, tu as l'air d'impliquer que les developpements sont long quand tu n'as pas a specifier les types.
quote un peu plus quand tu affirme quelquechose, j'ai beau me relire, je trouve pas de référence. Je développe en smalltalk et je suis un des premiers défenseurs de son efficacité en vitesse de développement. Mais comme tu t'es renseigné sur moi avant d'envoyer une attaque personnelle, tu le sais déjà.
Ton experience de la programmation m'epoustouffle.
Je suis fan des attaques personnelles, ta mère suce des ours ? Où c'était des caribous ? on distingue mal sur la vidéo. C'est le problème en Europe de l'Est, ils font du hard très gore mais top au niveau technique.
Bon, je t'offre une vrai réponse :
Une partie de ce que tu teste en Lisp serait validé par du typage mais le lien n'est pas toujours immédiat.
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à -1.
Dans le pire des cas, Common LISP peut verifier le type de donnee en runtime. Il est aussi possible d'effectuer des controles plus fin genre ce nombre doit etre pair ou impair, ce character doit etre ASCII etc...
CL permet aussi de specifier le type de donnee. Cette pratique arrive souvent en fin de developpement, quand le programme est pret. Si la vitesse d'execution de tout ou partie du code est critique, une programmeur peut specifier le type pour augmenter la vitesse d'execution. (il peut aussi declarer des optimizations pour le compileur).
Je passe tes commentaires vulgaires...
[^] # Re: vive Lelisp ;)
Posté par AnneDeMontMorency . Évalué à 1.
MetaOCaml (et son cousin MetaML) comme leur nom l'indique s'efforcent de permettre la métaprogrammation tout en conservant les qualités bien connues des langages de la famille ML
http://cs-www.cs.yale.edu/homes/taha/MetaOCaml/(...)
http://www.cse.ogi.edu/PacSoft/projects/metaml/(...)
http://www.cse.ogi.edu/PacSoft/projects/Mustang/Overview.html(...)
[^] # Re: vive Lelisp ;)
Posté par TazForEver . Évalué à 0.
J'etais tres rétissant au début (c'est le premier langage que j'ai appris) mais maintenant je suis ravi d'en connaitre les bases.
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à -1.
[^] # Re: vive Lelisp ;)
Posté par Moby-Dik . Évalué à -4.
Qu'est-ce qu'il faut pas entendre ;)
[^] # Re: vive Lelisp ;)
Posté par Delaregue . Évalué à -1.
Je paries que ton editeur fait la meme chose. Tu comptes tes '{' ou tu concentres sur le code?
[^] # Re: vive Lelisp ;)
Posté par Aza . Évalué à 1.
J'ai vite fait switché sur emacs, malgré les gueulantes de la prof : je trouve le lisp utilisé dans emacs bien plus logique (pour les quelques différences qu'il y'a ) et emacs est tellement plus pratique a utiliser qu'un machin dos infame.
N'empeche j'aime bien le lisp, c'est dommage que ce ne soit pas plus utilisé.
# Scheme in one Day/Defun
Posté par jm . Évalué à 4.
http://people.delphiforums.com/gjc/siod.html(...)
[^] # Re: Scheme in one Day/Defun
Posté par Delaregue . Évalué à 1.
http://www.lispme.de/lispme/(...)
# Combat d'arrière garde tout ca...
Posté par Le_Maudit Aime . Évalué à 10.
Oui lisp c'est beau, oui lisp c'est bien.,
oui c'est dommage on l'utilise pas/plus.
On va pas revenir dessus 107 ans, les anciens de l'I.A des années 80 qui comprennent toujours pas que le monde a changé, cela commence à bien faire.
1) il y a plein d'autres langages dans le monde qui sont intéressants ET minimaux.
2) CL est vraiment une usine à gaz, mieux vaut parler de scheme si on veut quelque chose d'élégant.
3) si vous voulez un langage fonctionnel+efficace(très)+fortement typé => langages à la ML type SML/Caml/etc. (eh oui le lambda calcul existe aussi en version -bien- typée)
</CAUTION:Explicit Offensive Troll>
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à 9.
Oui le monde a change. Il ne cesse de reinventer la roue. Celui que veut imiter Common Lisp est comdamne a le reinventer pauvrement.
(ps: j'avais 5 ans en 80 ;-)
>CL est vraiment une usine à gaz, mieux vaut parler de scheme si on veut quelque chose d'élégant
CL a tout le necessaire pour delivrer une application de haute qualite. Je n'appelle pas ca une usine a gaz.
Il faudrait m'indiquer ce que scheme a de plus elegant. De plus, bien que je neglige pas que l'elegance soit importante, je prefere un langage adapte au monde reel (aka faire de l'argent).
>langages à la ML type SML/Caml/etc
Ces langages sont effectivement puissants.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Le_Maudit Aime . Évalué à 1.
Je n'appelle pas ca une usine a gaz.
ca commence tout de suite par un gros pipo : http://www.lisp.org/table/Lisp-History.html(...)
Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp research and use.
http://www.lispworks.com/reference/HyperSpec/(...)
et ca se termine par un gros tas
In hardcopy, the ANSI Common Lisp standard is nearly 1100 printed pages describing nearly a thousand functions and variables in sufficient detail to accommodate hosting of the language on a wide variety of hardware and operating system platforms.
(Pour une histoire de Lisp :
http://www.dreamsongs.com/NewFiles/Hopl2.pdf(...))
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à -4.
On ne parle pas du Common Lisp qui a ete standardise ici. On parle du Common Lisp pre-standard. Cette citation est donc invalide pour appuyer ton point. C'est confirme dans le paragraphe suivant:
" Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification was developed"
>et ca se termine par un gros tas
In hardcopy, the ANSI Common Lisp standard is nearly 1100 printed pages describing nearly a thousand functions and variables in sufficient detail to accommodate hosting of the language on a wide variety of hardware and operating system platforms.
C'est tres facile de se former une opinion avec la description que tu viens de donner. Mais la encore cette opinion n'est pas valable.
En effet si tu consideres que Common LISP n'a qu'une bonne douzaine de primitives et que la syntaxe est quasi-inexistante (cad simple), cela reduit beaucoup le langage.
Le standard que tu cites considere ce que les autres langages appelle librairies, et dans une moindre mesure utilitaires tels que les debuggers, inspecteurs etc...
Pour paraphraser PSG:
Choisis ton langage favori. Rajoutes 3 ou 4 librairies, utilitaires de developpment, une liste de type de donnees ou objets exhaustives, des utilitaires de development, IO generalise etc... Prends le manuel de ton langage et toutes les docs de tes utilitaires et compte les pages. 1000 et quelques pages te semblent beaucoup maintenant?
Il est tres facile de prendre des commentaires au hazard et d'avancer une opinion. Developper une opinion eclairee est un art plus difficile.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Le_Maudit Aime . Évalué à 7.
Pourquoi était-ce/est-ce génant ? :
- c'était génant parce que les éxécutables CL étaient énormes par rapport à la puissance des machines (chuis un dino moi),
- c'est génant maintenant (à mon avis) parce que si c'est pour développer en fonctionnel, il y a mieux (caml,haskell etc.) et si, on utilise du lisp de nos jours c'est pour de l'embarqué (petit code/reconfiguration à la volée/etc.) et la cela redevient gros du fait des contraintes de l'embarqué.
si tu consideres que Common LISP n'a qu'une bonne douzaine de primitives
Tous les LISP sont contruits avec un nombre de primitives réduits. On trouve plus petit, mais ce genre de comparaison, bof
Haskell dont on parle + bas : c'est 250 pages (2 manuels dont 1 pour la librairie) et avec des vrais morceaux de typeurs à l'intérieur. R4RS c'est 50 pages.
Regardons Caml par rapport à SML, on a l'impression que c'est le retour de la gueguerre Lelisp (dont on parle au dessus) contre CL. Mais Caml il fout la patée aux autres langages. Oui on peut pinailler que ce n'est pas tout à fait compatible avec SML (Standard ML = la norme d'après les américains) etc mais toujours est-il que c'est élégant ET efficace.
http://www.bagley.org/~doug/shootout/(...)
(je sais on peut tout faire dire aux benchmarks etc. mais bon in-fine il faut un point de comparaison)
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à -1.
Ou as tu lu ca?
CL as repris les meilleurs traits de la famille LISP entre autre et s'est pose en unificateur. Il a reussi car il n'y a pas un seul LISP qui peut se poser en conccurent (a ce jour). Si tu programmes en entreprise aujourd'hui, c'est en CL.
>Scheme + élégant, il n'y a pas eu de compromis
Il y a eu un compromis sur la capacite a resoudre de vrais problemes. C'est comme les robes de haute couture. Tu ne les porte pas au travail.
>on utilise du lisp de nos jours c'est pour de l'embarqué
http://www.lisp.org/table/commercial-use.htm(...) annulera ta dernier remarque.
>Tous les LISP sont contruits avec un nombre de primitives réduits. On trouve plus petit, mais ce genre de comparaison, bof
Le point etait de prouver que ta tirade sur la taille du standard etait infondee. Tu t'ecartes du probleme.
>Haskell dont on parle + bas : c'est 250 pages
Haskell est purement fonctionnel. CL propose tous les idiomes de programmation. CL a un compilateur disponible en runtime. Je repete: CL a un compilateur dispo en runtime. CL debugger, plus de librairies etc... Cesse de parler de nombre de pages quand tu compares un langage qui ne propose pas un dixieme des fonctionalites de CL.
>Mais Caml il fout la patée aux autres langages
Quels sont tes criteres? Affirmation gratuite?
Tu n'as decidement rien a apporte au debat. Quand j'argumente un point, tu t'eloignes systematiquement du vrai probleme en cherchant la petite bete ailleurs. Malheureusement tu ne peux pas la trouver.
Quand tu argumentes, tu parles de taille de livres...
A la prochaine.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Le_Maudit Aime . Évalué à 3.
-> puéril
<i>L a un compilateur dispo en runtime. CL debugger, plus de librairies etc... <i>
et tu crois que caml et haskell sont venus tout nu ?
>Mais Caml il fout la patée aux autres langages
Quels sont tes criteres? Affirmation gratuite?
tu te fous de la gueule du monde, je fournis un lien juste en dessous.
De la même façon tout en haut, quand je fournis un lien sur l'histoire de Lisp, c'est pour appuyer mes propos. Tu aurais pu faire l'effort de le lire. Alors un conseil, lis le maintenant et tu diras moins de conneries.
Tu n'as decidement rien a apporte au debat.
tout est dit, je m'abaisse devant le grand maître que tu es.
[^] # Un peu lassant
Posté par Moby-Dik . Évalué à 10.
Ah, pardon, dans les entreprises j'ai vu passer du Java, du C++, de l'assembleur, du XML, du Perl, du shell, des tas d'autres trucs, mais alors jamais oh grand jamais une seule ligne de Lisp (sauf pour configurer emacs pour les amateurs d'icelui).
Tu n'as decidement rien a apporte au debat. Quand j'argumente un point, (blabla)
Pardon encore, mais ces propos seraient plus recevables si tes propres affirmations étaient argumentées. Or là, entre "Lisp est fait pour résoudre de vrais problèmes", "Lisp vous permet de penser avec votre cerveau à vous" (et la marmotte... m'enfin) et "Lisp est le langage utilisé en entreprise", on nage dans la purée de pois. T'as pas des arguments (ou au moins des exemples) concrets et pertinents ? Tu as semble-t-il répondu à la moitié des messages de ce forum, et à chaque fois c'est du genre : je m'empresse de défendre mon langage fétiche sans prendre le temps de construire un argumentaire intéressant. Un discours de midinette, quoi.
[^] # Re: Un peu lassant
Posté par Delaregue . Évalué à -4.
Je voulais dire que si tu programmais LISP en entreprise, c'etait CL. Je peux te garantir que LISP est plus present que tu ne le pense. J'ai moi meme concu des programmes en CL pour les besoins d'une compagnie de telecom. J'ai effectivement aussi programmer de maniere plus frequente dans les programmes cites au-dessus. Je n'en tire pas malheureusement pas une grande satisfaction.
>Pardon encore, mais ces propos seraient plus recevables si tes propres affirmations étaient argumentées
L'auteur se faisait un plaisir de chercher la petite bete la ou il y en avait pas. Contredire pour contredire. J'ai coupe court a ce thread de maniere abrupte car il n'y avait plus lieu de discuter.
[^] # Re: Un peu lassant
Posté par Le_Maudit Aime . Évalué à -4.
je tiens à vous féliciter, en quelques interventions bien ciblées, vous avez réussi à donner de l'espoir à de nombreuses personnes qui ont parcouru ce fil de discussion. Nombreux sont ceux qui, dans notre monde si cruel, se posent des questions existentielles.
Par exemple: est-ce qu'être con, ignorant et prétentieux a des effets néfastes sur la santé, voire même peut nuire à ma carrière ?
Grâce à votre enfilade de perles, le monde entier sait désormais que non.
un seul mot : Bravo et merci pour cette expérience in-vivo.
[^] # Re: Un peu lassant
Posté par Delaregue . Évalué à -3.
[^] # Re: Un peu lassant
Posté par Le_Maudit Aime . Évalué à 1.
Mourant presque de faim, vit au haut d'une treille
Des Raisins mûrs apparemment,
Et couverts d'une peau vermeille.
Le galand en eût fait volontiers un repas ;
Mais comme il n'y pouvait atteindre :
"Ils sont trop verts, dit-il, et bons pour des goujats. "
Fit-il pas mieux que de se plaindre ?
Jean de LA FONTAINE (1621-1695)
[^] # Re: Combat d'arrière garde tout ca...
Posté par Ken Le Survivant . Évalué à 6.
Personnellement, ce qui m'a toujours emmerdé avec Lisp, c'est pas les parenthèses mais le double espace de nom (le #' pour les fonctions...).
Ben voilà, dans scheme c'est plus là.
Et il y a d'autres améliorations : "The major contributions of Scheme were lexical scoping, lexical closures, first-class continuations, and simplified syntax (no separation of value cells and function cells)" (http://www.elwoodcorp.com/alu/table/Lisp-History.html(...)). En fait scheme était plus ou moins censé remplacer lisp, et en corriger les défauts, mais il ne s'est jamais imposé (à cause de l'existant, y'a qu'à voir la taille de la bibliothèque standard de Lisp pour comprendre).
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à -6.
L'un a ete creer pour etre le lit d'experimentations des theories informatiques dont certaines ne sont pas forcement utiles (continuation) et l'autre a ete cree comme un un outil de travail( eprouve en entreprise depuis des annees). Toutes les contributions citees font partie de CL excepte les continuations qui ne font pas parties du standard (certains vendeurs ont tout de meme decide d'implementer les continuations).
Scheme ne s'est jamais impose car les concepteurs preferaient developper un jouet a un utilitaire.
Il lui manque beaucoup de choses elementaires. Les hash ont font partie.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Dams Nadé (site web personnel) . Évalué à 9.
http://www-sop.inria.fr/mimosa/fp/Bigloo/(...)
Et en plus bigloo compile le scheme. Interfacable avec C, y'a tableau, hash, socket, parser, lexer.. tout y est. Bigloo peut meme generer du bytecode java si ca te branche..
Et pour ceux qui veulent faire des interfaces graphiques : http://www-sop.inria.fr/mimosa/Manuel.Serrano/biglook/(...)
Voila, bonne nuit...
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à -4.
Bonne nuit effectivement.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Dams Nadé (site web personnel) . Évalué à 2.
Bigloo est une implementation de scheme... :)P
tcho
[^] # Re: Combat d'arrière garde tout ca...
Posté par Delaregue . Évalué à 0.
==> Bigloo != scheme.
Donc je reitere: Je parlais de scheme pas de bigloo.
[^] # Re: Combat d'arrière garde tout ca...
Posté par Le_Maudit Aime . Évalué à 4.
En fait, ils ont participé à CL puis après ils se sont aperçu qu'en fait ils avait fabriqué le Frankenstein Lisp. (c:
(Lisez un peu le lien sur l'histoire de Lisp)
[^] # Re: Combat d'arrière garde tout ca...
Posté par reno . Évalué à 1.
C'est pour ça que le TurboPascal a eu autant de succès: il apportait plein de truc tres utile..
# Le plus lisible
Posté par Dugland Bob . Évalué à 6.
mes 2 préférés :
-la version encodage par listes (bijection entre la longueur d'une liste de unit et les entiers naturels)
-la version "statique" qui se la joue prolog (ceux qui ont fait de la compil par tables SLR peuvent aussi comprendre).
[^] # Re: Le plus lisible
Posté par Le_Maudit Aime . Évalué à -1.
allez -1
[^] # Re: Le plus lisible
Posté par Moby-Dik . Évalué à -3.
A part ça, beau temps non ? Dommage qu'ils y aient tous ces trolls qui se promènent dans les cieux :-)
[^] # Re: Le plus lisible
Posté par Dugland Bob . Évalué à 1.
Ceci est de l'humour. D'autre part, si tu a réellement lu ce qui était marqué (mais j'en doute) le mec dit qu'il a utilisé cet exemple car c'est l'équivalent fondtionnel du "hello world" des langages impératifs.
[^] # Re: Le plus lisible
Posté par Fabimaru (site web personnel) . Évalué à 2.
-1, car je porte encore les sequelles de mes cours de scheme
[^] # Re: Le plus lisible
Posté par Moby-Dik . Évalué à 2.
# D'abord fonctionnel
Posté par duaneg . Évalué à 9.
C'est le fait que ce soit un langage fonctionnel
qui fait que l'on doit penser différemment (par rapport à la majorité des langages impératifs) lorqu'on programme. Qu'on ajoute ensuite des constructions au langage permettant de faire de l'objet est secondaire.
[^] # Re: D'abord fonctionnel
Posté par Delaregue . Évalué à -3.
CL ne te force pas dans le fonctionnel, l'imperatif ou l'objet. Tu choisis. De plus, CL propose un nombre impressionnant de type d'objet.
Tu testes ton code a la seconde ou tu ecris etc...
Toutes ces raisons font que tu raisonnes dans les termes de ton probleme, pas ceux du langage. Tu en deviens plus productif.
Peux tu dire qu'une voiture en 1920 est comparable a une voiture de 2002 en terme de fonctionalites car il c'est son ancetre?
[^] # L'effet longue durée de Lisp Common réhydrate mon cerveau en profondeur
Posté par Moby-Dik . Évalué à 5.
[^] # Re: L'effet longue durée de Lisp Common réhydrate mon cerveau en profondeur
Posté par Delaregue . Évalué à -3.
# Un autre truc aussi vieux que le lisp à redecouvrir
Posté par Troy McClure (site web personnel) . Évalué à 10.
# Quelques questions
Posté par Philippe F (site web personnel) . Évalué à 6.
- vous recommanderiez quoi comme bouquin pour mieux saisir les joies de la programmation foncionnelle ? Je pense a un bouquin qui ne serait pas "comment programmer en OCaml", mais plutot "comment programmer en fonctionnel" et voila des exemples en OCaml ou autre chose.
- plus ca va, plus python a l'air d'integrer des fonctionnalites de programmation foncionnelle. Il y avait un article sur ibm-developers un jour a ce sujet. Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ? D'apres ce que je vois, les langages fonctionnels supportent aujourd'hui le double paradigme fonctionnel et imperatif. Donc eux aussi se rapprochent ?
- y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels ?
- j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante [comment on traduit 'lazy' ?] et ses capacites de mise a jour dynamique. Il semble que ce genre de fonctionnalite ne fasse pas partie de OCaml mais que ca soit bien quand meme. Vous pouvez m'expliquer ?
- je crois que je devrai faire un tour sur un newsgroup de programmation fonctionelle.
- ca a l'air cool l'inria, vous etes tous payes pour vous eclatez sur des trucs qui vous plaisent ? Comment qu'on rentre ?
[^] # Réponse d'un gourou imaginaire
Posté par Moby-Dik . Évalué à 10.
Je ne connais pas grand chose aux langages fonctionnels mais ca a l'air grave interessant.
Plus exactement, c'est amusant et ça peut donner de bonnes idées pour tes expériences futures. Maintenant, en-dehors de cas académiques (la factorielle (tm), etc), c'est relativement inutile de vouloir s'accrocher à ce genre de langages. Les problèmes du monde réel, qui sont complexes, multivalents et nécessitent des solutions soigneusement affutées, s'accomodent mal de la "pureté", ou plus exactement de l'austérité sémantique, des langages fonctionnels.
Quand je vois que KDE avec du C++ arrive tout juste au niveau des fonctionnalites d'emacs avec son lisp
Non non petit scarabée, quand tu t'adresses à un gourou, abstiens-toi de troller comme tu le fais dans la cour avec les autres scarabées... Enfin, je te pardonne, ça m'est arrivé aussi dans ma jeunesse de faire preuve d'impolitesse avec les gourous dont je quémandais les lumières :)
Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ?
Ah cher newbie, tu poses la mauvaise question (rassure-toi, c'est un trait commun à beaucoup de newbies, et tu arriveras à t'en défaire grâce à la sagesse que tu accumuleras). La bonne question est : quels sont donc les mythiques avantages des langages fonctionnels ? Tu verras que la réponse se réduit à l'ensemble vide.
y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels
J'ai déjà vu une interface graphique réalisée en Lisp. Mais je te rassure, c'était laid, lent et buggé.
j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante
C'est une "force" commune à la plupart des langages interprétés (ou pseudo-compilés). Si c'est ce que tu cherches, Perl par exemple fera très bien l'affaire. Pas besoin donc de se perdre dans une marée d'inutiles parenthèses...
et ses capacites de mise a jour dynamique
Là encore, c'est une caractéristique de Lisp qui le rend assez beau d'un point de vue théorique (académique) ; un peu comme le fait que la sémantique du langage se satisfasse de très peu de constructions "natives" (on peut descendre à moins d'une dizaine), ou que tout soit listes qui sont elles-mêmes paires pointées (d'ailleurs, indice, c'est intéressant pour les templates C++). Mais en pratique, c'est beaucoup trop lourd à exploiter. Tu imagines un vrai programme (un pas trivial, plusieurs milliers de lignes au minimum) qui changerait à la volée la définition de ses propres fonctions et structures ? Ce serait rudement amusant à débugger, un programme pareil, tu penses ;) Certes la nomenclature deviendrait un effort inutile et donc évitable (ce qui n'est pas, j'en suis sûr, sans éveiller ton tempérament paresseux comme celui de tout programmeur de génie, même en herbe et en culottes courtes), puisqu'avec des structures qui changent de sémantique au gré de l'exécution du programme, pourquoi s'acharner à vouloir donner des noms pertinents ?
je crois que je devrai faire un tour sur un newsgroup de programmation fonctionelle.
Crois-moi, la vie est belle et vaut la peine d'être vécue. C'est bien dommage de s'abandonner à de telles pensées noires et peu adaptées à la fraîcheur de ta sève, petit scarabée.
Comment qu'on rentre ?
L'INRIA c'est chiant et rempli de gens qui pensent travailler sur des sujets très utiles qui en fait n'aboutissent jamais à rien de concret (ou alors un pauvre partenariat concernant mille lignes de code après dix ans de "recherches" poussives). On n'y est de plus pas bien payé (normal, puisqu'on est inutile). Par contre, si tu choisis bien le lieu et la période, tu pourras passer d'agréables vacances sur la côte d'Azur : un stage est tout indiqué ; tâche de dégoter un sujet bien fumeux à Sophia-Antipolis et fais-toi des copains parmi les autres stagiaires du coin (que tu pourras rencontrer dans la résidence à laquelle t'enverra l'INRIA), tu ne le regretteras pas.
Voilà, petit scarabée, j'espère que mes réponses t'agréeront. Il est toujours agréable de pouvoir être utile à d'innocents et jeunes newbies quand ils butent contre les mêmes interrogations que celles que l'on eut, soi-même jeune et innocent, avant de devenir gourou....
Bien à toi.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Anonyme . Évalué à 4.
J'ai déjà vu un jeu réalisé en Lisp. Je te rassure, c'était beau, rapide (ça tournait très bien sur mon 486) et ça roxorisait. Même que ça roxor toujours, puisqu'il tourne toujours. Ce jeu, c'est Abuse http://abuse2.com/sshots.php3(...)
[^] # Re: Réponse d'un gourou imaginaire
Posté par Moby-Dik . Évalué à 7.
Bon, pour le Lisp, une entrée de la Faq :
[^] # Re: Réponse d'un gourou imaginaire
Posté par Fabimaru (site web personnel) . Évalué à 4.
A faire: arreter la drogue
[^] # Re: Réponse d'un gourou imaginaire
Posté par Anonyme . Évalué à -1.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Fabimaru (site web personnel) . Évalué à 3.
C'est la fete aux -1 en ce moment !
-1
[^] # Re: Réponse d'un gourou imaginaire
Posté par Dugland Bob . Évalué à 1.
Avec un langage nettement plus expressif, tu écris moins de lignes de code pour une partie qui va rester exécutée plus longtemps.
J'ai du mal à le définir mieux mais disons que l'équivalent en C++ de ce qui a été écrit en Lisp à de grandes chances d'être énorme en nombre de lignes.
En gros, ce critère n'est pas suffisant.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Anonyme . Évalué à 2.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Dugland Bob . Évalué à -6.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Moby-Dik . Évalué à 3.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Dugland Bob . Évalué à -10.
c'est marrant car un certains nombre des conneries que tu débites sont marquées dans la Faq. La plus précise c'est le coup des listes.
J'aime bien aussi ton discours sur l'inria, tu sais même pas lire ! génial ! je t'aime !
Le gueule du gourou, balaise !
[^] # Re: Réponse d'un gourou imaginaire
Posté par Moby-Dik . Évalué à 1.
Hmmmm ?
:-))
[^] # Re: Réponse d'un gourou imaginaire
Posté par Dugland Bob . Évalué à -8.
Comme tu as déjà dit un certain nombre de conneries, je pensais que ceci n'en était qu'une de plus.
[^] # Re: Réponse d'un gourou imaginaire
Posté par Kriek . Évalué à 1.
Dirais tu aussi que le MIT est inutile ? Les gens de l'INRIA font aussi des softs "utiles" par ailleurs comme mldonkey :) (belle utilisation de CAML avec interface graphique GTK pour la question précédente )
Pour être aussi aigri tu as du être refoulé à l'entrée ;)
[^] # Re: Quelques questions
Posté par Vivi (site web personnel) . Évalué à 5.
- vous recommanderiez quoi comme bouquin
il y a "Developpement d'applications en Objective Caml" http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/(...) qui est trés trés bien. Il y a des chapitres qui ont une portée plus large, genre "Styles fonctionnel et impératif" ou "Programmation modulaire/programmation objet".
- y a-t-il des boite a outils graphique
il y a LablGTK (interface GTK) et des interfaces pour glade. (bon le tout est moins abouti que les versions originales, il faut bien le dire ...)
sinon à propos des types, caml est trés différent du lisp sur ce point car le typage de caml est statique et non dynamique, c'est-à-dire que la plupart des vérifications de type se font lors de la compilation et non pas à l'éxécution. De plus caml fait de l'inférence de type, c'est à dire que le compilateur détermine tout seul le type des valeurs : il n'y a plus d'annotations de type dans le code.
(bon j'ai pas dit grand-chose en somme mais il se fait tard)
[^] # Re: Quelques questions
Posté par Dugland Bob . Évalué à 3.
En fait la classification des langages est en général assez "molle", c'est plutôt une calssification par traits de caractère qui serait plus rigoureuse.
Quand à un rapprochement fonctionnel/impératif, tout le monde pique des trucs chez tout le monde.
Je maîtrise pas le Lisp donc je répondrait pas avec certitude sur la notion de typage fainéant (qui est une excellente traduction de lazy). Je pense qu'il s'agit du fait que les types ne sont vérifiés que si c'est nécessaire (donc à l'exécution). En lien avec le typage dynamique (c'est la même chose ?)
Lisp effectivement a la capacité de modifier lui-même son code source, ça veut dire que le compilateur est embarqué (donc c'est mieux d'avoir une grammaire simple) et que la machine virtuelle est capable d'intégrer du code nouveau (ou de modifier l'existant) en cours de route. Ceci permet de modifier le compilateur afin de lui faire comprendre des nouvelle choses, on peut le faire n'importe comment mais il existe un système qui permet de juste lui faire comprendre de nouveaux mots et de les traduire en Lisp (comme une macro en C mais version propre). C'est (il parraît) très puissant. Ceci influe aussi beaucoup (positivement) sur la correction des bugs, l'analyse du programme, et le cycle de développement en général.
Objective Caml n'embarque pas le compilateur mais l'extention de la syntaxe se fait par l'extérieur (camlP4). Hormis un truc douteux (dont je n'ai jamais entenu parler : recharger une bibliothèque partagée après l'avoir recompliée) on ne peut pas modifier du code compilé à la volée. Donc tout le débogage se fait depuis l'extérieur.
Ceci n'enlève rien à l'expressivité du langage, toute la puissance est là.
D'autre part, le typage fort statique permet d'améliorer la qualité du logiciel (il diminue les erreur connes), d'améliorer la vitesse (beaucoup plus de contexte est connu à l'avance) et aussi d'améliorer la lisibilité (par l'aspect annotation de la chose). Le compilateur sait lui-même (en général, sinon y'a un '_a qui va se trimbaler) reconnaitre les types des objets.
Caml parraît aussi moins repoussant par l'abscence d'arrêtes de poisson et une syntaxe plus conventionelle (il a pas à se trimballer le compilo en mémoire, donc on hésite pas sur les fioritures et le maquillage (list, array, lazy, etc.) :-).
Un aspect passionel est sous-jacent aussi.
Pour les outils graphiques, y'a mlglade et un truc en TK aussi mais c'est pas le point fort de ces langages. Peut-être un manque de recherche ? Quelqu'un connais des patterns fonctionnels pour les UI ?
Concernant l'INRIA, c'est le CNRS donc concours du CNRS.
[^] # Re: Quelques questions
Posté par Ronan BARZIC . Évalué à 6.
A bon ?, je n'etais pas au courant (J'ai passe trois ans a L'Irisa de Rennes il y a longtemps et ce n'etait pas le CNRS)
Pris par le doute, j'ai regarde sur le site de l'INRIA et le CNRS n'est cite que comme partenaire.
Je m'etonne (et m'enerve !) de voir que quelqu'un comme toi qui a l'air si erudit pour nous puisse se permettre de telles inexactitudes.
Il suffisait de regarder sur www.inria.fr et www.cnrs.fr pour voir la difference et que l'on peut bosser
a l'Inria sans forcemment faire un concour, tout depend du profil...
Si tu ne sais pas, ne reponds pas plutot que de vouloir avoir reponse a tout
> informatique : science de l'érection du crétinisme en idéal.
Ouf, je suis electronicien...
[^] # Re: Quelques questions
Posté par Dugland Bob . Évalué à -1.
C'est pas la dernière fois, donc prépare les pilules pour ton coeur.
C'est très con d'avoir le centre de recherche en informatique détaché du centre de recherche français.
[^] # Re: Quelques questions
Posté par boubou (site web personnel) . Évalué à 4.
Absolument pas, c'est un concours spécifique. Le lien avec le CNRS est simplement terminologique, tu es Chargé de recherches (CR) puis Directeur de recherches (DR), à l'INRIA comme au CNRS. Par contre, les critères sont les "mêmes" : il faut une thèse et des publications internationnales et surtout connaître des gens...
[^] # Re: Quelques questions
Posté par Alberto . Évalué à 3.
A priori aussi l'inria est moins "cote" que le cnrs.
[^] # Re: Quelques questions
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Quelques questions
Posté par Dugland Bob . Évalué à 5.
http://mitpress.mit.edu/sicp/full-text/book/book.html(...)
(c'est le texte complet)
[^] # Re: Quelques questions
Posté par AnneDeMontMorency . Évalué à 7.
- vous recommanderiez quoi comme bouquin pour mieux saisir les joies de la programmation fonctionnelle ?
La question est difficile... Mon livre préféré est celui de X. Leroy et P. Weis que je recommande vivement, mais il s'agit de Caml même s'il s'efforce de donner un aperçu syntétique de la question.
Je vous conseille d'aller faire un tour dans la section livres de plusieurs langages fonctionnels (Haskell, Caml, ML), d'éventuellement télécharger des tutoriels pour vous en faire une idée :
http://www.haskell.org(...) (livres en anglais exclusivement)
http://www.ocaml.org(...)
- plus ca va, plus python a l'air d'integrer des fonctionnalites de programmation fonctionnelle. Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ? D'apres ce que je vois, les langages fonctionnels supportent aujourd'hui le double paradigme fonctionnel et imperatif. Donc eux aussi se rapprochent ?
Tous les langages fonctionnels ne supportent pas le double paradigme fonctionnel/impératif : contre-exemple Haskell.
Lisp est aussi vieux que Fortran et antérieur à C, Ada, etc. Autrement dit les langages fonctionnels ne se rapprochent pas, ils ont toujours été là.
Quant à savoir si les langages purement impératifs vont un jour adopter les paradigmes venus du monde fonctionnel, jusqu'à présent toutes les initiatives en ce sens ont échoué, que ce soit Pizza (au dessus de Java) ou autres. C'est fondamentalement un problème de conception, à l'image des machines virtuelles de Java et de Python sont irrécupérables (et resteront à jamais des tortues devant celle de Caml)
- y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels ?
Caml et Haskell ont des wrappers pour toutes les librairies graphiques nécessaires (ils ont d'ailleurs des interfaces C, COM, etc?). Vous trouverez nombre d'applications Caml qui utilisent une interface Tk ou GTk, j'ai même vu un jeu en openGL
(voir les entrées correspondante dans la bosse -the hump- sur le site caml précédemment cité)
- j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante [comment on traduit 'lazy' ?] et ses capacites de mise a jour dynamique. Il semble que ce genre de fonctionnalite ne fasse pas partie de OCaml mais que ca soit bien quand meme. Vous pouvez m'expliquer ?
Il ne faut faire la part entre les différents concepts :
- typage dynamique / typage statique
Le typage dynamique se fait à l'exécution (Lisp), le typage statique à la compilation (Caml), certains langages ont une part des deux (Java)
Le principe du typage statique est "si le programme compile correctement, il n'explosera pas à l'exécution" autrement dit pas de segfaults, pas de message d'erreur "method not found", etc.
- évaluation stricte / évaluation paresseuse (lazy)
Cela désigne le fait que lors de l'appel à une fonction, tous les arguments sont évalués même s'ils sont inutiles (strict) ou seulement les arguments nécessaires sont évalues (paresseur). Exemples caractéristiques Caml / Haskell.
Cependant, les langages paresseux comportent toujours des mécanismes pour forcer une évaluation stricte (! en Haskell) et inversement les langages stricts ont des calculs déférés (type lazy en Caml)
- réflexivité
C'est un concept plus difficile, il s'agit de pouvoir se manipuler soi-même en tant que langage. Par exemple en Lisp les fonctions sont des listes, donc on peut les manipuler comme des listes (prendre la tête, coller avec une autre queue, etc.)
- mise à jour dynamique
Je ne vois pas très bien ce que vous voulez dire par là, sans doute faites vous référence à la particularité de pouvoir changer les éléments en cours d'éxécution (un peu à la SmallTalk).
Il faut savoir que cela est caractéristique des langages interprétés (typiquement SmallTalk), seulement tant Lisp que Caml ou Haskell viennent en version interprétée ou compilée.
Lisp (même compilé) permet certaines manipulations du genre (Java aussi par exemple), mais il s'agit là plutôt de réflexivité
Lisp
forces :
- réflexivité
faiblesses :
- typage dynamique
Caml
forces :
- typage statique
- vitesse
faiblesse :
- absence de réflexivité (cependant MetaOCaml)
- je crois que je devrai faire un tour sur un newsgroup de programmation fonctionelle.
Il y a une FAQ qui peut vous être utile
- ca a l'air cool l'inria, vous etes tous payes pour vous eclatez sur des trucs qui vous plaisent ? Comment qu'on rentre ?
On rentre par concours. Voir http://inria.fr(...) pour les postes disponibles (tout niveaux : chercheurs, ingénieurs confirmés ou débutants...)
[^] # Re: Quelques questions
Posté par Gniarf . Évalué à 2.
"C++ is not a better Smalltalk, Smalltalk is the best Smalltalk" - Scott Meyers
[^] # Re: Quelques questions
Posté par HappyCrow . Évalué à 1.
J'ai lu "Developpement d'applications en objective CAML", "Structure and interpretation of computer programs" et le bouquin de CAML des gars de l'INRIA.
Tu y apprends respectivement a programmer en OCaml, Scheme, CAML.
Mais tu y apprends aussi plein d'autres choses...(threads, programmation repartie,
fonctionnement d'un interpreteur, compilation de languages).
Je les conseille tous, meme si on doit passer a Ocaml (CAML n'est plus maintenu)
et a Scheme ("nouveau LISP").
- plus ca va, plus python a l'air d'integrer des fonctionnalites de programmation foncionnelle. Il y avait un article sur ibm-developers un jour a ce sujet. Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ? D'apres ce que je vois, les langages fonctionnels supportent aujourd'hui le double paradigme fonctionnel et imperatif. Donc eux aussi se rapprochent ?
Je pense qu'on peut programmer en purement fonctionnel avec un language imperatif,
simplement le compilo ne derecursivera surement pas et donc ca ne tracera pas des masses.
- y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels ?
Je crois que quelqu'un a poste un lien dans les reponses au dessus, sinon CAML
s'interface avec gtk si je me souviens bien.
- j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante [comment on traduit 'lazy' ?] et ses capacites de mise a jour dynamique. Il semble que ce genre de fonctionnalite ne fasse pas partie de OCaml mais que ca soit bien quand meme. Vous pouvez m'expliquer ?
Je sais pas trop ca, a mon avis la force de OCaml est le typage fort:
le compilateur te gueule dessus tant que tous tes types ne sont pas corrects,
c'est chiant au debut mais apres tu comprends la force du truc.
- ca a l'air cool l'inria, vous etes tous payes pour vous eclatez sur des trucs qui vous plaisent ? Comment qu'on rentre ?
Je pense que certains des meilleurs informaticiens francais travaillent la bas (Xavier LEROY)... certains des meilleurs des USA travaillent au MIT (et ils font Scheme...).
Perso, je pense que la force du fonctionnel est de programmer tres rapidement
(t'as l'algo. dans la tete et boum il est implemente) car ce sont des languages de tres haut niveau.
Un gars parle de Prolog plus haut, je pense que ca a le merite de te remettre en question, tu doutes de savoir programmer. Mais c'est de la prog. logique, pas fonctionnelle.
Bonne "caramelisation" (programmer en OCaml)! :O)
# Mouai
Posté par Herrera Carlos . Évalué à 6.
[^] # Re: Mouai
Posté par Moby-Dik . Évalué à 2.
[^] # Re: Mouai
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Mouai
Posté par Dugland Bob . Évalué à -7.
C'est plus par paresse intellectuelle que pour une autre raison qu'il n'y a que peu de langages utilisés (de plus ils se ressemblent fortement).
Mais peut-être qu'une aggravation du nombre de morts directement imputables à de mauvaise pratiques informatiques va déclencher une prise de consience. Ce n'est pas gagné vu ce que tu écrit (ça a toujours marché comme ça et il n'y a pas de raison que ça change)
[^] # Re: Mouai
Posté par Ramón Perez (site web personnel) . Évalué à 5.
Non, le Lisp date de 1958 et le C de 1971.
[^] # Re: Mouai
Posté par Benoît Bailleux (Mastodon) . Évalué à 0.
[^] # arf
Posté par Vivi (site web personnel) . Évalué à 8.
Si le lisp était vraiment un bon langage, depuis le temps qu'il existe il aurait été utilisé.
des milliards de mouches ... tout ça ...
[^] # Re: Mouai
Posté par ufoot (site web personnel) . Évalué à 3.
Pour info mon principal outil de travail - celui sur lequel je passe plus des 3/4 quarts du temps et qui bouffe une part non negligeable de mes resources systeme - est une machine Lisp. Et je suis tres loin d'etre le seul dans ce cas...
Pour argumenter mon propos, je te propose de regarder le sondage LinuxFR http://www.linuxfr.org/poll/index.php3(...) et tu constateras que 360 utilisateurs (soit 10%), lancent Emacs apres s'etre logges. Ils utilisent donc un programme Lisp. Evidemment ca n'est pas la majorite. Mais ce n'est pas negligeable.
Avec ton type d'argumentation on pourrait aussi considerer que Linux c'est vraiment de la merde car depuis le temps que ca existe (1991), si c'etait vraiment bien, la majorite des gens s'y serait mis... La preuve par la majorite n'en est pas une.
[^] # Re: Mouai
Posté par Herrera Carlos . Évalué à 2.
[^] # L'arbre qui cache la forêt
Posté par Moby-Dik . Évalué à 1.
C'est énorme. En plus d'utiliser un programme Lisp, ils utilisent :
- un interpréteur Lisp (quel langage ?)
- une bibliothèque de fonctions de base utilisées par l'interpréteur Lisp et le code Lisp (quel langage ?)
- peut-être une interface graphique (quel langage ?)
- un noyau de système d'exploitation pour faire tourner le tout (quel langage ?)
En gros, 99% des gens utilisent un système majoritairement à base de C/C++. De plus, à part emacs, je ne pense qu'il y ait beaucoup de trucs en lisp dans les suites d'outils couramment utilisées. Enfin bref, ton argument est complètement à côté de la plaque (je ne dis pas ça pour te vexer ;-)).
[^] # Re: Mouai
Posté par AnneDeMontMorency . Évalué à 4.
Le lisp est plus vieux que le C
Une rapide comparaison de ce qui a été réalisé en C et de ce qui a été réalisé en lisp que je vous invite à faire nous conduit à une conclusion inévitable et sans appel
Vous n'avez de toute évidence pas la moindre idée de ce qui a été fait en Lisp, en C ou en n'importe quel autre langage ; un petit aperçu s'impose
Les langages dans lesquels ont été écrits le plus grand nombre de lignes de code sont
- Cobol (entreprises, gestion, comptabilité)
- Ada (systèmes embarqués, domaine militaire)
- Lisp (toute l'informatique jusqu'au début des années 80 - avant l'apparition du C)
- Fortran (tout le calcul scientifique jusqu'à très récemment)
arrivent seulement ensuite C, C++ et Java
Y-a-t-il des systèmes d'exploitations écrits en Lisp ? oui... des tas. Il y avait même des machines spécialement construites autour d'un interprète Lisp (tout comme il y a des machines qui executent directement du byte code Java)
[^] # Re: Mouai
Posté par patate . Évalué à 2.
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/s(...)
C'est etrange d'ailleurs, sur une copie d'ecran sur cette page, on voit un menu "pomme" dans le coin en haut a gauche, comme sur les vieux macs.
[^] # Re: Mouai
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Mouai
Posté par Herrera Carlos . Évalué à 2.
[^] # Re: Mouai
Posté par HappyCrow . Évalué à 1.
Tu aimes C, probablement parce que tu ne connais que ca,
tout comme certains programmeurs Java qui ne jurent que par Java.
Si tu essayes un peu Ocaml ou scheme, tu vas comprendre
un peu que tu peux etre beaucoup plus productif.
Ces languages sont de beaucoup plus haut niveau,
tu t'abstrais de plein de choses: la machine (car il y a une machine virtuelle),
l'OS si tu ne fais pas d'appels systemes, les pointeurs...
Avec asm, C, C++ tu es au niveau des paqueretes.
Avec Ocaml / scheme tu es au niveau de dieu.
[^] # Oh, j'oubliais
Posté par Moby-Dik . Évalué à 0.
Ahhh :-))
Si c'est le cas, le fait que C ait supplanté Lisp montre bien que :
[^] # Re: Oh, j'oubliais
Posté par Dugland Bob . Évalué à 0.
Aujourd'hui c'est complètement différent tu te retrouve avec des programmes à peine 2 fois plus lent, pour plus de fiabilité, du développement plus court et une maintenance plus facile.
Ceci dit, je suis convaincu que les langages plus récents (caml, haskell) on globalement plus d'atouts (mais ils n'ont pas tout de lisp).
[^] # Re: Mouai
Posté par HappyCrow . Évalué à 1.
quand tu auras fini, je serai a la retraite depuis longtemps.
Le C est plus rapide, c'est sur. Mais le lisp est plus rapide a ecrire
(moi je prefere scheme ou ocaml mais bon).
Si tu veux gagner du temps machine, fais du C ou de l'asm
et casse toi bien la tete.
Si tu veux aller vite, fait du scheme/ocaml.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.