Common LISP, un langage à (re)découvrir

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
29
août
2002
Technologie
Pascal Costanza, développeur Java, nous propose son point de vue subjectif ainsi qu'un guide sur le langage Common LISP. Common LISP a été le premier langage orienté objet standardisé par l'ANSI et si je ne m'abuse, le seul langage objet certifié par l'OMG. Bien sur, CL permet aussi de développer avec la plupart des idiomes supportés par d'autres langages: Vous n'êtes pas restreint à l'objet.

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

  • # vive Lelisp ;)

    Posté par  . Évalué à -1.

    Cette année à la fac, on a du faire un projet LISP avec un LISP tout bizzare que seul LELISP, un environnement LISP maison de l'INRIA pouvait faire tourner.

    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  . Évalué à 10.

      >Donc la standardisation du LISP, c'est bien sur le papier, mais dans les faits c'est du grand n'importequoi.

      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  (site web personnel, Mastodon) . Évalué à -6.

        Il me semble que LeLisp est une implémentation du Common LISP.
        De toutes façons, pour moi, ce ne sont que de mauvais souvenirs d'étudiants.
        • [^] # Re: vive Lelisp ;)

          Posté par  . Évalué à 2.

          lelisp n'est pas une implementation de Common Lisp. Il se veut proche de "Common Lisp". Ce n'est donc pas un standard.
    • [^] # Re: vive Lelisp ;)

      Posté par  . Évalué à 10.

      Personnellement j'ai dans ma jeunesse (85-88) utilisé LeLisp sur SM90, machine Bull à base de 68000, sans aucun problèmes. Ce n'est pas parce que l'interpréteur que vous avez à votre Fac est sur une machine DOS que le langage est ...
      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  (site web personnel) . Évalué à 10.

        >Savez vous ce que veut dire l'acronyme LISP ? Lot of Insipid and Stupid Parenthesis... ;-)))
        Ou Lots of Irritating and Superfluous Parenthesis...
        Bref il doit y en avoir presque autant que pour Emacs.
        • [^] # Re: vive Lelisp ;)

          Posté par  . Évalué à -3.

          Je connais pas emacs, mais le langage de script n'est pas (ou du moins dérivé) du lisp? Pareil d'ailleur pour sawmill
        • [^] # Re: vive Lelisp ;)

          Posté par  . Évalué à -2.

          Bref il doit y en avoir presque autant que pour Emacs.

          c'est normal, ils suxent tous les deux tout autant...

          (chérie, ca va chier)
        • [^] # Re: vive Lelisp ;)

          Posté par  . Évalué à -3.

          Bref il doit y en avoir presque autant que pour Emacs.

          Sans blague, les fichiers config d'Emacs c'est du Lisp, pas étonnant hein.
    • [^] # Re: vive Lelisp ;)

      Posté par  . Évalué à -1.

      LeLisp ca ro><!

      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  . Évalué à 2.

        si je me souviens bien l'INRIA a refilée lelisp a une boite et depuis c'est devenu commercial. Je me rappelle pas si la boite a fait faillite ou si elle a en juste arrêté la commercialisation.

        Il faut de toutes façon une licence pour faire tourner lelisp.
        • [^] # Re: vive Lelisp ;)

          Posté par  (site web personnel) . Évalué à 1.

          Ouaip. La boite en question, c'est Ilog, mais bon ça m'etonnerais vraiment que ça soit encore maintenu...
          • [^] # Re: vive Lelisp ;)

            Posté par  . Évalué à 1.

            ... et la boite n'a pas du tout fait faillite, au contraire !
            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  . Évalué à 10.

      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.

      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  . Évalué à -3.

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

        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  . Évalué à 10.

          Caml est plus moderne (disons plus récent) car la théorie des types qu'il utilise date des années 80 (pour les trucs les plus pointus). Donc Lisp risquait pas de les avoir en 58.

          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  . Évalué à -6.

            >Donc Lisp risquait pas de les avoir en 58
            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  . Évalué à -6.

              Common LISP est plus recent.
              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  . Évalué à -1.

                CL permet le typage dynamique et statique. Les variables elles-meme ne sont pas typees et peuvent comporter n'importe quel type de donnees. Les donnees seulement sont taggees avec un type.

                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  . Évalué à 1.

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

            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  . Évalué à 0.

        J'étudie à la fac le Scheme (et le prolog) et bien que ce soit un paradigme de programmation peu utilisé et encore moins enseigné, c'est un langage tres puissant des qu'on a réussi a compter ses parentheses.

        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  . Évalué à -1.

          Tous les bons editeurs te permettent de te concentrer sur le code, pas les parentheses.
          • [^] # Re: vive Lelisp ;)

            Posté par  . Évalué à -4.

            Excellent argument. Je propose qu'on traduise les mots-clés du C en Chinois, de toute façon les bons éditeurs permettent de se concentrer sur le code :))

            Qu'est-ce qu'il faut pas entendre ;)
            • [^] # Re: vive Lelisp ;)

              Posté par  . Évalué à -1.

              L'editeur que j'utilise m'indique quel elements sont ouverts tels que '(' '{' '['.
              Je paries que ton editeur fait la meme chose. Tu comptes tes '{' ou tu concentres sur le code?
    • [^] # Re: vive Lelisp ;)

      Posté par  . Évalué à 1.

      Ah, on a peut être utilisé le même alors. Je me souviens aussi qu'on nous avait donné un programme dos pour faire du lisp, mais je crois que ca sortait de jussieu et non de l'inria (peut être que c'est passé par les deux remarques).

      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  . Évalué à 4.

    un ptit interpreteur scheme en quelques lignes de C
    http://people.delphiforums.com/gjc/siod.html(...)
  • # Combat d'arrière garde tout ca...

    Posté par  . Évalué à 10.

    <CAUTION:Explicit Offensive Troll>

    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  . Évalué à 9.

      >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
      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  . Évalué à 1.

        Celui que veut imiter Common Lisp est comdamne a le reinventer pauvrement. On va pas très loin avec ce genre de phrases d'une part ce sont des généralités sans fond et d'autre part la question est qui veut utiliser, pas qui veut imiter/copier/etc...

        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  . Évalué à -4.

          >Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp research and use.
          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  . Évalué à 7.

            On parle du Common Lisp pre-standard. Cette citation est donc invalide pour appuyer ton point. Oui d'ailleurs j'ai pensé à laisser le mot Research dans ma citation. Le problème que je voulais exposer c'est qu'en partant de là ils auraient eu du mal à aboutir a quelque chose de concis. CL a voulu reprendre les traits de tous les LISP qui le précédaient et c'est pour cela que c'est une usine à gaz. Les origines de CL, c'est grosso modo le DARPA qui dit mettez-vous d'accord sinon + de contrats LISP. Alors les industriels se sont mis d'accord mais au dépend de l'élégance du langage. C'est pour cela que je trouve Scheme + élégant, il n'y a pas eu de compromis. La sémantique d'un langage, c'est parfois TRES compliqué mais rarement TRES long.

            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  . Évalué à -1.

              >CL a voulu reprendre les traits de tous les LISP
              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  . Évalué à 3.

                Il y a eu un compromis sur la capacite a resoudre de vrais problemes.
                -> 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  . Évalué à 10.

                Si tu programmes en entreprise aujourd'hui, c'est en CL.

                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  . Évalué à -4.

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

                  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  . Évalué à -4.

                    Mon cher ami,

                    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  . Évalué à -3.

                      Il y a seulement 2 types de personnes dans la vie: Les ignares et les ignorants. Les ignorants sont ceux qui ne disposent que de peu de savoir et le reconnaissent. Ils cherchent continuellement a faire table rase avec ce qu'ils croient savoir. Ils se posent des questions et cherche a apprendre. Ils apprennent... Les ignares, dont tu fais partie n'ont aussi qu'un savoir limite sur les choses de ce monde. La difference avec les ignorants est qu'ils croient tout savoir et restent sur leur position toute leur vie. Ils ne cherchent pas a apprendre ni comprendre. Ce sont ceux qui sont devastes par les prejuges et autres idees-preconcues. Ils marchent a contre-courant du progres. Tu sers ce mouvement. Toute ta vie on t'a appris qu'il fallait penser d'une certaine facon. "On m'a dit ca depuis des annees, cela doit etre vrai" C'est un choc cognitif d'apprendre quelque chose de nouveau et ta pauvre cervelle ne peut pas supporter ce desequilibre. En effet non seulement tu es stupide, mais tu es vulgaire et irrespectueux! J'espere que nous croiserons plus jamais nos plumes. Cela n'a rien d'instructif.
                      • [^] # Re: Un peu lassant

                        Posté par  . Évalué à 1.

                        Certain Renard Gascon, d'autres disent Normand,
                        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  . Évalué à 6.

        Il faudrait m'indiquer ce que scheme a de plus elegant.

        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  . Évalué à -6.

          Scheme et Common Lisp ont eu 2 buts differents:

          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.
  • # Le plus lisible

    Posté par  . Évalué à 6.

    C'est haskell, regardez comme toutes ces versions de la factorielle sont toutes plus lisibles les unes que les autres : http://www.willamette.edu/~fruehr/haskell/evolution.html(...)

    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  . Évalué à -1.

      rien que la factorielle à la prolog un vrai bonheur.

      allez -1
    • [^] # Re: Le plus lisible

      Posté par  . Évalué à -3.

      C'est sûr, la factorielle est un exemple hautement pertinent (et tellement "real-world") pour juger de la lisibilité d'un langage. Enfin bref, tout est dit.

      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  . Évalué à 1.

        Pourquoi un mec aussi terre-à-terre poste sur une news parlant de fonctionnel ?

        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  (site web personnel) . Évalué à 2.

        Mauvaise langue ! Avec les langages fonctionnels on peut resoudre le probleme des huits reines

        -1, car je porte encore les sequelles de mes cours de scheme
  • # D'abord fonctionnel

    Posté par  . Évalué à 9.

    Avant d'être orienté objet, Lisp est d'abord l'ancêtre des langages fonctionnels.
    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  . Évalué à -3.

      Attention encore: Je parle de Common Lisp.
      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?
  • # Un autre truc aussi vieux que le lisp à redecouvrir

    Posté par  (site web personnel) . Évalué à 10.

    How to shoot yourself in the foot:

    • C: You shoot yourself in the foot.

    • FORTH: Foot in yourself shoot.

    • FORTRAN: You shoot yourself in each toe, iteratively, until you run out of toes; then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception-handling routine.

    • LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...

  • # Quelques questions

    Posté par  (site web personnel) . Évalué à 6.

    Puisqu'il y a des gourous dans la salle, je vous pose quelques questions. Je ne connais pas grand chose aux langages fonctionnels mais ca a l'air grave interessant. Quand je vois que KDE avec du C++ arrive tout juste au niveau des fonctionnalites d'emacs avec son lisp, je me dis qu'il y a une lecon a en tirer.

    - 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  . Évalué à 10.

      Cher néophyte,

      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  . Évalué à 4.

        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 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  . Évalué à 7.

          Joli en effet :))
          Bon, pour le Lisp, une entrée de la Faq :

          E. Was Abuse Written Entirely in Lisp?

          This has the unfortunate possibilty of becoming a well spread misconception.
          While the external entity code that you will write for modifications and
          additions (or total reconstruction) of the game will be in Lisp, the game
          engine was written in C++. There is also a small amount of 80x86 assembly
          in the DOS version.

          Here is the wc (word count) output on the source code.

          Lisp code: 5374 16377 142220 total
          C++ code: 67904 185889 1717174 total
          Asm code: (negligible)

          Approximately seven percent of the game engine and Abuse combined is
          Lisp code. The rest is C++. There 5044 lines of Lisp code distributed in
          the 0.3.2 version of the Linux version, so you are seeing _all_ of the Lisp
          code (the difference is likely due to some lisp net Abuse code that hasn't
          been finished yet).
          • [^] # Re: Réponse d'un gourou imaginaire

            Posté par  (site web personnel) . Évalué à 4.

            C'est bien la preuve de la formidable puissante expressive du LISP. D'enormes fonctionnalites regroupees dans si peu de code LISP. Superbe face au C++ bien verbeux.

            A faire: arreter la drogue
          • [^] # Re: Réponse d'un gourou imaginaire

            Posté par  . Évalué à -1.

            Oui, bon, dire que le jeu est en lisp est un peu abusé (huhu) mais quand même, doit pas y en avoir beaucoup d'autres avec des bouts de lisp dedans (sachant que dans le tas en c++, y a un interpreteur lisp...)
          • [^] # Re: Réponse d'un gourou imaginaire

            Posté par  . Évalué à 1.

            Je peux mettre de la mauvais foi ?

            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  . Évalué à 2.

              cela dit, il me semble que c'est "l'intelligence" du jeu qui réside dans ce code lisp... c'est bien entendu à vérifier...
              • [^] # Re: Réponse d'un gourou imaginaire

                Posté par  . Évalué à -6.

                J'ai la flemme de vérifier, mais ça correspondrait bien aux clichés sur le Lisp ("c'est fait pour l'intelligence artificielle"). Donc ça ne m'étonnerait pas.
                • [^] # Re: Réponse d'un gourou imaginaire

                  Posté par  . Évalué à 3.

                  Ouaip. Comme c'est un jeu de plateformes, ils auraient dû faire les routines de sprites en Lisp. Mais bon, ils sont victimes de leurs préjugés, les pauvres :-))
      • [^] # Re: Réponse d'un gourou imaginaire

        Posté par  . Évalué à -10.

        T'es un fake ?
        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  . Évalué à 1.

          Hum, n'est-ce pas toi qui te gaussais des pisse-froid qui manquent d'humour, quelques messages plus haut ?
          Hmmmm ?

          :-))
          • [^] # Re: Réponse d'un gourou imaginaire

            Posté par  . Évalué à -8.

            J'hésitais mais je viens de capter le critère : le titre !

            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  . Évalué à 1.

        Conernant l'INRIA, ce n'est ni plus ni moins "utile" que toiut autre centre de recherche scientifique. On ne peut pas prévoir à quoi aboutit la recherche, surtout quand elle est fondamentale, donc c'est très facile de dire "ça ne sert à rien" mais le LASER ne servait à rien non plus lors de sa découverte ...
        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  (site web personnel) . Évalué à 5.

      bon, je vais parler de ce que je connais bien, le caml ...

      - 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  . Évalué à 3.

      Un langage impératif peut prendre des trucs dans le fonctionnel (comme les [ ] de smalltalk) et l'inverse (les do machin des langages fonctionnels stricts).
      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  . Évalué à 6.

        > Concernant l'INRIA, c'est le CNRS donc concours du CNRS.

        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  . Évalué à -1.

          Ben je me suis planté.
          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  (site web personnel) . Évalué à 4.

        >>Concernant l'INRIA, c'est le CNRS donc concours du CNRS.

        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  . Évalué à 3.

          Il n'y pas necessairement besoin de these pour le cnrs mais c'est recommande ; de toute facon il faut des publis dans des confs/revues internationales et surtout connaitre des gens dans les CN.

          A priori aussi l'inria est moins "cote" que le cnrs.
          • [^] # Re: Quelques questions

            Posté par  (site web personnel) . Évalué à 3.

            Effectivement, en théorie on doit présenter des "travaux équivalents à une thèse". Mais enfin bon, sauf pour les vrais génies, je pense que la thèse est assez indispensable.
    • [^] # Re: Quelques questions

      Posté par  . Évalué à 5.

      pour le bouquin :
      http://mitpress.mit.edu/sicp/full-text/book/book.html(...)

      (c'est le texte complet)
    • [^] # Re: Quelques questions

      Posté par  . Évalué à 7.

      Je vais tenter de donner des éléments de réponse à vos questions :

      - 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  . Évalué à 2.

        le typage dynamique n'est pas une faiblesse en soi : Smalltalk vit très bien avec ça, par exemple.

        "C++ is not a better Smalltalk, Smalltalk is the best Smalltalk" - Scott Meyers
    • [^] # Re: Quelques questions

      Posté par  . Évalué à 1.

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

      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  . Évalué à 6.

    Donc le lisp est un langage aussi 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: le lisp est un langage inintéressant. Après il y a toujours des gens qui viendront nous parler de paradigme, d'idiome, de "puissance", de typage fort, de typage faible, d'une manière simple de résoudre tous les problèmes compliqués, etc etc ... Mais cela ne nous inspire qu'un sourire amusé car nous avons notre petit test en tête. Si le lisp était vraiment un bon langage, depuis le temps qu'il existe il aurait été utilisé.
    • [^] # Re: Mouai

      Posté par  . Évalué à 2.

      Voyons, tu oublies le complot mondial des barbus rétrogrades (les mêmes à coup sûr qui veulent faire croire qu'un avion s'est écrasé sur le Pentagone !).
    • [^] # Re: Mouai

      Posté par  (site web personnel) . Évalué à 2.

      Tu as oublie la puissance expressive, comme disait jadis mon prof de scheme.
    • [^] # Re: Mouai

      Posté par  . Évalué à -7.

      D'ailleur c'est vrai que aucun des concepts lancés par lisp n'a jamais été réutilisé.
      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  (site web personnel) . Évalué à 5.

      > le lisp est un langage aussi vieux que le C.
      Non, le Lisp date de 1958 et le C de 1971.
      • [^] # Re: Mouai

        Posté par  (Mastodon) . Évalué à 0.

        Faut être réaliste : pour des types (forts ?) nés en même temps ou après le C, cela ne change pas grand chose : les deux existaient avant qu'ils aient conscience de l'existence de l'informatique !
    • [^] # arf

      Posté par  (site web personnel) . Évalué à 8.

      c'est marrant, y'a un poste la mailing-liste caml qui me fait penser à ton (pitoyable) troll :
      Objective Caml's popularity in academia is a curse as
      well as a blessing. For every coder like me who wonders if he should
      rather have gone into academia, industry has a hundred coders who think
      career academics are a fat lot of pencil-necked geeks who can't get
      "real" programming jobs. This is why industry continues to be
      populated with idiots who think the reason Java programs so often
      perform badly is the garbage collector. These are also the same people
      who will tell you that the syntax of Objective Caml is intolerably
      bizarre, while simultaneously raving about the elegance of C#. (I'm
      not bitter. I'm not bitter.)

      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  (site web personnel) . Évalué à 3.

      > Une rapide comparaison de ce qui a été réalisé en C
      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  . Évalué à 2.

        "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" Pour info mon principal outil de travail est un PC sous NT et une station Sun sous Solaris et je pense qu'on est beaucoup plus dans mon cas que dans le tien (et je dis "je pense" pour ne pas dire "je sais"). "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" Linux existe depuis 1991, je ne pense pas que ce soit super vieux pour un os. Et si linux se faisait rapidement supplanter par un os plus jeune encore, alors vive ce dernier. Lisp existe depuis 1960, je pense que c'est suffisemment vieux pour qu'il ait dû faire ses preuves car des langages plus jeunes que lui les ont faites.
      • [^] # L'arbre qui cache la forêt

        Posté par  . Évalué à 1.

        je te propose de regarder le sondage LinuxFR 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.

        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  . Évalué à 4.

      Donc le lisp est un langage aussi vieux que le C

      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  . Évalué à 2.

        Il y avait même des machines spécialement construites autour d'un interprète Lisp

        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  . Évalué à 1.

        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 Des chiffres avec une description de la méthode de recensement utilisée, ce serait intéressant. Là c'est du vague emballé dans du flou. Y-a-t-il des systèmes d'exploitations écrits en Lisp ? oui... des tas Ah lesquels ? Et à quelle échelle sont-ils utilisés ? :-))
      • [^] # Re: Mouai

        Posté par  . Évalué à 2.

        "Y-a-t-il des systèmes d'exploitations écrits en Lisp ? oui... des tas" Si Quake tourne sur un de ces os, promis, je l'essaye. "tout comme il y a des machines qui executent directement du byte code Java" Idem
        • [^] # Re: Mouai

          Posté par  . Évalué à 1.

          Mais oui, on mesure la qualite d'un language par un Quake Benchmark...!!!

          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  . Évalué à 0.

        - Lisp (toute l'informatique jusqu'au début des années 80 - avant l'apparition du C)

        Ahhh :-))
        Si c'est le cas, le fait que C ait supplanté Lisp montre bien que :

        • la non-adoption de Lisp n'est pas une affaire de "préjugés" et de "paresse" (puisqu'on l'utilisait avant)

        • les programmeurs qui ont fait l'effort de passer à C ont probablement un certain nombre de raisons de l'avoir fait (sachant que le bon programmeur est par nature paresseux)
        • [^] # Re: Oh, j'oubliais

          Posté par  . Évalué à 0.

          ça m'étonnerais que beaucoup aient fait le passage lisp-C c'est plutôt fortran-C ou directment C comme premier langage. Pour les autres, le C offrait des perfs vraiment meilleures à l'exécution.

          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  . Évalué à 1.

      Va programmer du calcul symbolique avec du C,
      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.