Apprendre un langage de programmation par an

Posté par  (site web personnel) . Modéré par baud123.
Étiquettes :
24
20
déc.
2010
Technologie
Un de mes livres d'informatique préférés est The Pragmatic Programmer, from journeyman to master. Dedans, on y trouve une foultitude de conseils, dont l'un m'a particulièrement marqué : il est souhaitable d'apprendre un nouveau langage de programmation tous les ans pour parfaire son portfolio de connaissances.

L'année 2011 va bientôt arriver et je souhaite partager avec vous quelques suggestions de langages pour ceux qui voudraient suivre ce conseil :
  • Ruby (disponible sous Licence Ruby et GPL) reste mon langage préféré et je ne saurais trop vous conseiller de le découvrir !
  • Reia (disponible sous licence MIT) est un langage avec une syntaxe inspirée de Ruby qui tourne au-dessus de la machine virtuelle d'Erlang, permettant ainsi de profiter du meilleur des deux mondes.
  • Go (disponible sous Licence BSD) est un langage assez jeune mais déjà très intéressant, avec notamment la programmation concurrente à base de Goroutines.
  • Io (disponible sous Licence BSD) est un langage de programmation qui s'appuie sur les prototypes, avec des inspirations venant de Smalltalk, Self, Lisp et Lua.
  • Scala (disponible sous Licence BSD) pourrait être le futur pour les développeurs Java et propose déjà des avancées très pertinentes comme son modèle d'Actors ou son travail sur le typage.
  • F# (disponible sous Licence Apache) est un langage de programmation fonctionnelle, fortement inspiré d'OCaml et issu des laboratoires de Microsoft.


Au fait, je n'ai pas encore choisi quel langage j'allais étudier en 2011, donc n'hésitez pas à défendre votre langage favori dans les commentaires ;-)

Aller plus loin

  • # Seven languages in Seven weeks

    Posté par  . Évalué à -3.

    Pas la peine d'attendre un an à chaque fois pour apprendre un nouveau langage :-)

    http://pragprog.com/titles/btlang/seven-languages-in-seven-w(...)

    (C'est édité par le gars qui a écrit The Pragmatic Programmer)
  • # Erlang

    Posté par  . Évalué à 4.

    Pourquoi ne pas utiliser erlang plutôt que d'essayer Reia ?

    Dans le monde des langages fonctionnel, erlang est très intéressant, et a l'immense avantage de fonctionner en production depuis des années.

    Je ne tenterai pas trop F#, peut être Scala avec le sympathique framework qu'est play: http://www.playframework.org/documentation/1.1/scala
    • [^] # Re: Erlang

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

      > Pourquoi ne pas utiliser erlang plutôt que d'essayer Reia ?

      Parce que la syntaxe d'Erlang est assez affreuse ;-)
      • [^] # Re: Erlang

        Posté par  . Évalué à 4.

        C'est pour ça qu'il existe Lisp Flavored Erlang. [http://metajack.im/2009/01/09/lisp-flavored-erlang/]
        • [^] # Re: Erlang

          Posté par  . Évalué à 10.

          Parce que le lisp a une syntaxe agréable ????

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Erlang

        Posté par  . Évalué à 7.

        Parce que la syntaxe d'Erlang est assez affreuse ;-)

        Je ne suis pas d'accord. La syntaxe d'Erlang est déroutante, déjà parce que c'est de la programmation fonctionnelle, mais surtout parce que Erlang est très fortement orienté communication. Mais la syntaxe Erlang est parfaitement limpide une fois qu'on a compris le truc.

        Ce qui manque VRAIMENT à Erlang ce sont des bibliothèques...
      • [^] # Re: Erlang

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

        C'est (presque) jamais un bon argument pour refuser d'essayer un langage. Si tu trouves une syntaxe affreuse, c'est généralement parce que tu n'es pas familier avec elle. C'est donc plutôt une bonne raison d'essayer le langage :)
        • [^] # Re: Erlang

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

          > Si tu trouves une syntaxe affreuse, c'est généralement parce que tu n'es pas familier avec elle.

          Et on devient familier au bout de combien de temps ? Nan, parce que ça fait quelques années que je fais du templeet et je trouve la syntaxe affreuse. Franchement, quelle idée d'utiliser un caractères à la con comme le tilde pour quelque chose d'aussi courant que appeler une fonction, mais peut-être qu'un jour je comprendrais :-)
          • [^] # Re: Erlang

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

            Parce que le tilde n'est un caractère a la con que sur un clavier azerty? Ou peut-être est-ce l'azerty qui est "a la con"...
            • [^] # Re: Erlang

              Posté par  . Évalué à 2.

              Sur un qwertz, c'est aussi un caractère à la con. Je ne suis pas sûr qu'il y a beaucoup de dispositions pour lesquels le ~ ne soit pas trop mal placé.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Erlang

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

                Chez moi, le ~ c'est MAJ-² (clavier Azerty, config standard Linux...)
                • [^] # Re: Erlang

                  Posté par  . Évalué à 2.

                  config standard Linux

                  C'est quoi une config standard Linux ?

                  Un kernel vanilla avec toutes les options ?

                  Vu que ça parle de clavier, je suppose que tu parles de distribution GNU/Linux. Dans ce cas, la « config standard », c'est la config par défaut ? Latin-0 ? Latin-9 ? Une autre ?

                  Et c'est la config standard d'Ubuntu (la plus répandue) ? Une autre distrib ?
                  • [^] # Re: Erlang

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

                    C'était la config standard en français sur toutes les distribs que j'ai utilisées, à savoir successivement:
                    - Slackware
                    - RedHat
                    - Mandrake/Mandriva
                    (Ubuntu n'existait pas encore à l'époque où j'ai commencé à utiliser ces distribs, il est apparu pendant que j'étais sous Mandrake)
                    - et maintenant ArchLinux.

                    On peut aussi noter que c'était vrai sous SunOS, HPUX, IRIX et Solaris (sauf que là ce n'est pas moi qui administrais les machines donc je ne peux pas dire si les admins avaient fait une configuration particulière).

                    PS: Latin-0 et Latin-1 concernent l'affichage mais n'ont rien à voir avec le clavier. Le clavier c'est XkbModel: pc105, XkbLayout: fr
                    • [^] # Re: Erlang

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

                      J'aurais du ajouter: même si les options que je cite dans mon PS sont pour X11, la touche marche aussi dans la console avec la config fr par défaut.
              • [^] # Re: Erlang

                Posté par  . Évalué à 3.

                Sur un clavier espagnol c'est en accès direct
        • [^] # Re: Erlang

          Posté par  . Évalué à 8.

          Je suis d'accord sur le principe mais dans le cas d'Erlang, c'est en fait justifié : la syntaxe d'Erlang est *vraiment* mauvaise.

          La syntaxe d'Erlang est, pour des raisons historiques, inspirée de la syntaxe de Prolog. Le problème c'est que la sémantique de l'Erlang moderne ne correspond pas du tout à celle de Prolog, et que des choses qui étaient donc très bien pour Prolog sont des problèmes pour Erlang.

          D'habitude les critiques qu'on peut faire sur une syntaxe sont... purement syntaxiques (il y a une ambiguïté à tel niveau, etc..), donc fondamentalement peu importantes. Mais dans le cas d'Erlang il y a de vrais problèmes sémantiques bêtement liés à la syntaxe, comme par exemple :
          - impossibilité de définir des fonctions locales récursives
          - impossibilité d'avoir des patterns linéaires. L'interprétation de la clause de filtrage "X => ..." dépend donc complètement de l'environnement : si X est défini, c'est un test d'égalité, sinon c'est un motif universel. Ça rend tout raisonnement équationnel (et donc la plupart des manipulations de code) difficile.

          Le deuxième point est par ailleurs corrigé par Reia, qui propose (ou proposait la dernière fois que j'ai regardé) deux syntaxes pour les patterns, une linéaire (une variable est toujours un motif universel) et une non-linéaire.
          • [^] # Re: Erlang

            Posté par  . Évalué à 2.

            Intéressant, je n'avais pas remarqué mais effectivement une fun ne peux pas s'appeler elle-même. Surprenant pour un langage dit fonctionnel. Quant à ce que tu appelles les patterns linéaires, peux-tu indiquer des langages qui les permettent et éventuellement à quoi cela ressemble ?

            À un niveau plus terre à terre, le trouve aussi qu'il n'est pas toujours évident de s'y retrouver entre la virgule, le point-virgule et le point, notamment lorsqu'on a des fun ou des case et qu'on souhaite modifier le code.
            • [^] # Re: Erlang

              Posté par  . Évalué à 4.

              je n'avais pas remarqué mais effectivement une fun ne peux pas s'appeler elle-même. Surprenant pour un langage dit fonctionnel.

              Attention ! En Erlang fun n'est pas une fonction mais un état fonctionnel. C'est à dire un objet avec du code, des valeurs et à peu prêt tout ce qu'on veut dedans (y compris si on le souhaite des fonctions récursives).

              Il est donc normal que ça ne puisse pas s'appeler soi-même. (récursion d'un état, ça ne veut pas dire grand chose).

              À un niveau plus terre à terre, le trouve aussi qu'il n'est pas toujours évident de s'y retrouver entre la virgule, le point-virgule et le point

              A part quand ça intervient comme séparateur dans un constructeur, c'est pas très compliqué généralement c'est

              Bloc
              cas 1 -> action 1, action 2, action 3;
              cas 2 -> action 4, action 5, action 6;
              cas 3 -> action 7, action 8.
              • [^] # Re: Erlang

                Posté par  . Évalué à 3.

                Attention ! En Erlang fun n'est pas une fonction mais un état fonctionnel. C'est à dire un objet avec du code, des valeurs et à peu prêt tout ce qu'on veut dedans (y compris si on le souhaite des fonctions récursives).

                Ton argumentation n'est pas bonne. Tu nous donnes des détails sur les choix de représentation par Erlang des fonctions locales (bien sûr, dans tous les langages les fonctions locales sont représentées par des fermetures, c'est à dire quelque chose avec du code, des valeurs issues de l'environnement, etc.).

                Mais ça m'est égal, moi, la façon dont Erlang représente ses fonctions locales. Je peux déclarer des fonctions locales (anonymes), et j'aimerais définir des fonctions locales récursives, sans utiliser un combinateur de point fixe codé à la main qui tue les performances et limite la lisibilité.

                Par ailleurs il est possible de définir la récursion sur certaines valeurs (par exemple en OCaml), et les "objets fonctionnels" semblent tout indiqués pour supporter cette fonctionnalité.
                • [^] # Re: Erlang

                  Posté par  . Évalué à 3.

                  Tu nous donnes des détails sur les choix de représentation par Erlang des fonctions locales

                  J'insiste vraiment sur le fait que ce n'est pas une fonction locale. C'est un état. Tu peux utiliser cet état ou tu veux dans ton code, le passer en paramètres d'une autre fonction d'un autre module etc. Au niveau de la représentation c'est très similaire, mais au niveau de la logique ça n'a rien à voir. Généralement ca n'est utilisé que lorsqu'on a besoin de gérer des pools ou de faire gaffe à des problèmes de concurrence. On a des fonctions qui pondent des fun et d'autres fonctions qui les exploitent à la chaîne.

                  et j'aimerais définir des fonctions locales récursives, sans utiliser un combinateur de point fixe codé à la main qui tue les performances et limite la lisibilité.

                  Je ne sais pas quel est le problème que tu cherches à résoudre, mais je pense que tu te trompes sur la solution a utiliser en Erlang. A mon avis tu cherches à dupliquer la logique d'un autre langage en Erlang. Même si les vrais programmeurs peuvent coder en fortran dans n'importe quel langage, c'est quand même généralement déconseillé.
                  • [^] # Re: Erlang

                    Posté par  . Évalué à 1.

                    Ton argumentation me rend perplexe. J'ai l'impression que tu dis qu'Erlang n'est pas un langage fonctionnel, puisqu'il ne permet pas de créer des fonctions locales, et que la syntaxe "fun" est juste du sucre syntaxique proche d'une fonction pour autre chose de moins expressif (moins expressif puisqu'on n'envisage pas d'y ajouter la récursion).
                    Dans ce cas, Erlang n'est pas satisfaisant du tout en tant que langage fonctionnel (un langage fonctionnel sans fonctions locales, c'est presque de la publicité mensongère).

                    En même temps, ton discours "tu peux l'utiliser où tu veux dans ton code, le passer en paramètre ..." est exactement celui que l'on utilise pour décrire des fonctions de première classe. Des fonctions quoi.

                    Ensuite tu dis que de toute façon, ces trucs là sont très peu utilisés en Erlang, ce n'est pas idiomatique de s'en servir. Très bien (tant mieux pour vous les programmeurs Erlang, qui n'êtes pas dérangé par cette limitation), mais peut-être que si la syntaxe était mieux pensée sur ce point, les gens pourraient s'en servir de temps en temps.

                    Je ne sais pas quel est le problème que tu cherches à résoudre.

                    Un exemple serait plus parlant. Imagine que j'ai une fonction Erlang un peu grosse, qui définit une fonction locale (parce que cette fonction utilise des variables définies plus haut dans le bloc, et qu'elle n'a de sens que dans ce contexte donc polluerait inutilement le niveau global).

                    (Désolé pour l'indentation, je ne sais pas comment faire simplement avec le markup LinuxFR)

                    truc(args) ->
                    ...
                    F = fun(N) ->
                    N * (N + 1) / 2
                    end,
                    ...


                    Maintenant il se trouve que ma spécification change un peu, et j'ai besoin d'utiliser non pas (1 + 2 + .. + n) mais (1 * 2 * .. * n). J'ai envie d'écrire :


                    truc(args) ->
                    ...
                    F = fun(N) ->
                    if
                    N > 1 -> N * F(N-1)
                    true -> 1
                    end
                    end,
                    ...


                    Mais je ne peux pas, car `F` n'est pas définie dans le corps de la fonction.

                    J'aimerais avoir une syntaxe pour faire ça, par exemple :

                    F = fix Fac(N) ->
                    if
                    N > 1 -> N * Fac(N-1)
                    true -> 1
                    end
                    end
                    • [^] # Re: Erlang

                      Posté par  . Évalué à 3.

                      Ton argumentation me rend perplexe. J'ai l'impression que tu dis qu'Erlang n'est pas un langage fonctionnel, puisqu'il ne permet pas de créer des fonctions locales, et que la syntaxe "fun" est juste du sucre syntaxique proche d'une fonction pour autre chose de moins expressif (moins expressif puisqu'on n'envisage pas d'y ajouter la récursion).

                      Non, je dis que fun est une sauvegarde d'état, qui ne doit en aucun cas être prise pour une fonction locale. Après comme on est dans un langage fonctionelle fort (i.e pas de porte de sortie pour faire un peu de procédural ici ou là) toutes les fonctions peuvent être considérée comme locale.

                      En même temps, ton discours "tu peux l'utiliser où tu veux dans ton code, le passer en paramètre ..." est exactement celui que l'on utilise pour décrire des fonctions de première classe. Des fonctions quoi.

                      Non un état ets en quelque sorte l'inverse d'une fonction

                      Si on a F : x-> pleins_de_trucs.
                      alors F est la fonction et x est l'état.
                      Sauf que contrairement à un matching standard ton etat peut posséder de la logique propre à lui (mais toujours totalement dissociée de la logique de F)

                      mais peut-être que si la syntaxe était mieux pensée sur ce point, les gens pourraient s'en servir de temps en temps.

                      La logique Erlang va vraiement à l'encontre de fonctions locales telles que tu les souhaites. Chaque morceau doit être patchable à chaud, distribuable etc. Dans cet optiques de nombreux choix ont été faits, un de ces choix est de dire que les variables ne sont pas modifiables et que les scopes sont tous locaux à la fonction qui s'execute. Vouloir faire de la récursion en local au sein d'une fonction n'est donc pas très utile...

                      Un exemple serait plus parlant. Imagine que j'ai une fonction Erlang un peu grosse, qui définit une fonction locale (parce que cette fonction utilise des variables définies plus haut dans le bloc, et qu'elle n'a de sens que dans ce contexte donc polluerait inutilement le niveau global).

                      Déjà je t'arrête, il n'y a pas de niveau global à polluer. Fais ta fonction/ton module tranquillement. Autre particularité d'Erlang, il y a 99 chances sur 100 qu'il gère mieux la concurence que toi. Il faut donc faire autant de fonctions que possible sans que ca gène trop la lisibilité.

                      Mais je ne peux pas, car `F` n'est pas définie dans le corps de la fonction.

                      Non, tu ne peux pas parceque F n'est pas une fonction locale au sens langage C du terme, mais un etat. F(N-1) ne veut rien dire, puisque F(N) a déjà été appelé et que l'état a déjà été assigné. C'est pour çà que le compilo te jette. De façon générale tu n'as aucun moyen de faire appel à la logique à l'intérieur de F, vu que cette logique n'a pas de nom par laquelle l'appeler (c'est le truc des fonctions locales d'ailleurs). Fondamentalement vu que tu ne peux pas l'appeler, tu vas avoir du mal à faire de la récursion dessus.

                      J'aimerais avoir une syntaxe pour faire ça, par exemple :
                      La méthode la plus simple est d'utiliser le keyword apply sur une fonction d'un module extérieur.

                      D'abord un module avec al fonction factorielle dedans :

                      -module(m).
                      -export([fact/1]).
                      fact(N) when N>0 ->
                      N * fact(N-1);
                      fact(0) ->
                      1.


                      Ensuite on applique gentillement dans la fonction

                      mafonction (X,Y,Z) ->
                      ...
                      Mafact = apply (m,fact,A)
                      ....


                      On a 0 passage d'arguments en dehors de la fonction.
                      A noter que c'est un très mauvais exemple, Dans le cas ou l'on connait à l'avance le nombre d'arguments (et pour la factorielle il y a pas photo), il est TOUJOURS préférable de faire appel à la fonction du module directement.

                      donc pour écrire le code :


                      mafonction (X,Y,Z) ->
                      ...
                      Mafact = m:fact(A)
                      ....


                      De façon générale fun et apply sont utilisés dans des cas très particuliers, à savoir quand on ne sait pas à l'étape de compilation ce qui va se passer ou quand on est obligé de bloquer une ressource, de faire un commit ou de chercher une cohérence par rapport à un élément extérieur au langage lui même.
                      • [^] # Re: Erlang

                        Posté par  . Évalué à 4.

                        Ce que tu dis est difficilement compréhensible.

                        « La logique Erlang va vraiement à l'encontre de fonctions locales telles que tu les souhaites. Chaque morceau doit être patchable à chaud, distribuable etc. »
                        J'ai l'impression qu'il n'y a aucun rapport. On peut définir localement des fonctions, je veux définir des fonctions locales récursives, c'est tout, c'est totalement indépendant de la question de la modification à chaud du code (qui se fait à un niveau plus grossier, comme la déclaration toplevel, le module, etc.).

                        « Non, tu ne peux pas parceque F n'est pas une fonction locale au sens langage C du terme, mais un etat. F(N-1) ne veut rien dire, puisque F(N) a déjà été appelé et que l'état a déjà été assigné. C'est pour çà que le compilo te jette. »
                        Qu'est-ce que c'est que cette histoire ? Une fonction locale définie avec "fun" peut bien-sûr être appelée plusieurs fois, par exemple quand on la passe à la fonction "map" qui l'applique à tous les éléments d'une liste. Je ne comprends pas ce que tu essaies de dire.

                        Pris d'un doute, je suis allé consulter la spécification Erlang de 1999 (qui est vieille, d'accord) et la sémantique de Core Erlang publiée en 2004, et les deux ne mentionnent aucune bizarrerie de ce genre : une fonction locale est décrite comme une fermeture classique, qui capture son environnement, et qu'on peut ensuite appliquer comme une fonction globale.
                        D'ailleurs Core Erlang contient une construction pour les déclarations récursives locales (letrec)... Ce qui tend à confirmer que c'est bien juste un problème de syntaxe, et que conceptuellement c'est tout à fait possible.

                        Enfin je suis tombé sur cette discussion de la mailing-list Erlang, datant de 2000 : Do we need a letrec construct ? : http://www.erlang.org/pipermail/erlang-questions/2000-Octobe(...)
                        I think a variant of letrec could be useful in many cases where one wants
                        local functions, not cluttering the module-level namespace, even if the
                        problem does not involve tricky recursion like in your example (and it is
                        not difficult to handle letrec in the compiler, as long as only function
                        definitions are allowed).


                        « La méthode la plus simple est d'utiliser le keyword apply sur une fonction d'un module extérieur. »
                        Oui... précisément il faut passer par une fonction non-locale définie au toplevel d'un module. Moi je voudrais faire ça en local (il n'y a pas de raison...).
                      • [^] # Re: Erlang

                        Posté par  . Évalué à 3.

                        Je me permets de te corriger pour ta fonction fact qui est "montée" à l'enver :)

                        On écrit plutot:


                        -module(m).
                        -export([fact/1]).

                        fact(0) -> 1.
                        fact(N) when N>0 -> N * fact(N-1);


                        et pour davantage de performances, on utilise une fonction tail recursive (avec un petit accumulateur):


                        -module(m).
                        -export([fact/1]).

                        fact(N) -> fact(N,1).
                        fact(0,Ac) -> Ac;
                        fact(N,Ac) when N > 0 -> fact(N-1,N*Ac).
            • [^] # Re: Erlang

              Posté par  . Évalué à 2.

              Dans de nombreux langages avec pattern matching, les patterns doivent respecter la restriction de linéarité, qui dit qu'une variable ne peut apparaître qu'une seule fois par pattern. En effet, la sémantique d'une variable dans un pattern est "accepte n'importe quelle entrée et, dans la clause de filtrage, je pourrai utiliser cette variable comme nom sur l'entrée filtrée". Par exemple en caml dans `fun (x, y) -> x + y`, `(x,y)` est un motif qui accepte un couple, et donne le nom "x" au premier composant du couple, et "y" au second. `fun (x,x) -> x` n'a pas de sens (puisqu'il faudrait donner le même nom à deux valeurs différentes) et est rejeté par le compilateur.

              Il y a des langages qui autorisent le filtrage non-linéaire, où une variable apparaît plusieurs fois, et dans ce cas la sémantique est "accepte cette clause de filtrage si les différentes valeurs liées par la variable sont égales". Par exemple le pattern `(x, x)` n'accepterait que les couples dont les deux composants sont égaux. Cette approche a en particulier été popularisée par Prolog qui l'utilise comme une des base de la programmation (parce qu'en prolog il n'y a pas vraiment de "motifs" et de "résultat", les variables sont au même niveau et unifiées entre elles). C'est assez naturel, le problème c'est que dans un langage fonctionnel il n'y a pas forcément de notion canonique d'égalité qu'on puisse utiliser (qu'est-ce que ça veut dire, que deux fonctions sont égales ?).

              Erlang, comme prolog, utilise une forme de filtrage encore plus étendue : le test d'égalité se fait quand la variable est déjà liée dans le motif courant, mais aussi quand elle est déjà liée dans l'environnement : si tu rencontres la variable X dans un motif, la signification du motif dépend de si la variable X n'existe pas déjà dans le programme (alors elle est fraîche et on la lie), ou de si la variable X est déclarée et que le motif est dans sa portée (alors c'est un test d'égalité).

              En pratique cela veut dire que quand tu vois un motif en Erlang, tu ne peux pas connaître sa signification sans lire tout le code "au dessus" pour repérer toutes les déclarations de variable, et savoir si les variables du motif sont déjà dans l'environnement ou non. En particulier, si tu coupes-colle du code d'une fonction à une autre, ton code a des risques de devenir complètement faux pour des raisons subtiles qui sont difficiles à repérer, et dont le compilateur ne pourra pas t'avertir.

              Ce comportement (que j'appelle non-linéaire) est utile et expressif. Mais parfois, ce n'est pas le comportement qu'on veut : on veut dire "je ne veux pas savoir si X existe déjà ou non, donne le nom X à cette nouvelle variable et oublie l'ancienne le cas échéant". C'est utile, ça aide le raisonnement local, bref on en a besoin. Et Erlang ne le propose pas (sauf dans le cas de la syntaxe "fun (motif) -> expression end"), ce qui est un défaut. Reia propose deux syntaxes, une pour les filtrages non-linéaires d'Erlang, et une pour les filtrages linéaires (il me semble que c'est "*X". À vérifier).
              • [^] # Re: Erlang

                Posté par  . Évalué à 1.

                Oups : ce long post est une réponse à la question suivante :

                Quant à ce que tu appelles les patterns linéaires, peux-tu indiquer des langages qui les permettent et éventuellement à quoi cela ressemble ?
              • [^] # Re: Erlang

                Posté par  . Évalué à 1.

                Je n'ai pas compris ton explication.


                Peux-tu montrer un exemple parce que j'ai du mal à comprendre pourquoi il te faudrait relire tout le code pour savoir si X est liée ou non.
                • [^] # Re: Erlang

                  Posté par  . Évalué à 4.

                  Plutôt que de produire un exemple artificiel, je suis allé chercher du code dans la documentation officielle : http://www.erlang.org/examples/examples-2.0.html

                      server_loop(Name, Data, Fun) ->
                          receive
                              {rpc, Pid, Q} ->
                                  case (catch Fun(Q, Data)) of
                                      {'EXIT', Why} ->
                                          Pid ! {Name, exit, Why},
                                          server_loop(Name, Data, Fun);
                                      {Reply, Data1} ->
                                          Pid ! {Name, Reply},
                                          server_loop(Name, Data1, Fun)
                                  end;
                              {cast, Pid, Q} ->
                                  case (catch Fun(Q, Data)) of
                                      {'EXIT', Why} ->
                                          exit(Pid, Why),
                                          server_loop(Name, Data, Fun);
                                      Data1 ->
                                          server_loop(Name, Data1, Fun)
                                  end;
                              {eval, Fun1} ->
                                  server_loop(Name, Data, Fun1)
                          end.


                  La partie intéressante est "{Reply, Data1}" : pourquoi appeler cette variable Data1 ? Parce que le nom Data est "déjà pris". Si on mettait Data ici, le code deviendrait complètement faux. Pour choisir le nom à mettre dans le motif, on a du faire une opération non-locale : regarder l'ensemble des noms existants dans l'environnement. Si on coupe-colle le "case (catch Fun(Q, Data) .. end) à un autre endroit il faut faire bien attention de vérifier que les variables Why, Reply et Data1 ne sont pas déjà dans la portée de l'endroit où on les ajoute.

                  Encore une fois, le comportement "variable existante = test d'égalité" de Erlang est parfois bien pratique (si on sait définir l'égalité). Le problème c'est qu'il soit imposé (pour de simples raisons syntaxiques), qu'on ne puisse pas choisir un comportement local plus prédictible quand c'est plus adapté.
                  • [^] # Re: Erlang

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

                    >> Encore une fois, le comportement "variable existante = test d'égalité" de Erlang est parfois bien pratique (si on sait définir l'égalité).

                    En fait, c'est du pattern matching plus qu'un test d'égalité.
                    Ça retourne l'objet matché, et fait potentiellement des déclarations si des noms de variables non associés sont utilisés.
                    [3=3,_=3,3==3,{Z,_}={42,3}].
                    ==> [3,3,true,{42,3}]
                    Z.
                    ==> 42

                    Si je fais
                    1=2 j'obtiens
                    ** exception error: no match of right hand side value 2
                    • [^] # u

                      Posté par  . Évalué à 3.

                      Je ne comprends pas ta remarque. Oui, les patterns Erlang font du pattern matching. Ce que je dis c'est que dans un patten, les *variables*, quand elles existent déjà dans l'environnement, matchent leur entrée si et seulement si l'entrée fournie est égale à leur variable dans l'environnement.

                      On peut ainsi définir l'égalité ainsi :
                      Eq = fun(X,Y) ->
                        case Y of
                          X -> true;
                          _ -> false
                        end
                      end.


                      Ça marche aussi quand les variables sont déjà définies par le pattern :
                      Eq2 = fun(X,Y) ->
                        case {X,Y} of
                          {Z,Z} -> true;
                          _ -> false
                        end
                      end.



                      (Je pense que tu le sais et que notre incompréhension est juste due à une question de formulation, mais histoire de mettre les choses à plat : )
                      Un motif fait à la fois un "filtrage" (j'accepte certaines entrées et j'en rejette d'autres), et a un effet sur l'environnement (si j'accepte, j'enrichis l'environnement avec de nouvelles variables liées). La sémantique du motif qui n'est qu'une variable (les motifs plus compliqués comme ceux sur les tuples étant défini par composition des sémantiques des sous-motifs qui les composent) est :
                      - si la variable n'existe pas dans l'environnement, accepter toujours et enrichir l'environnement avec un lien (variable -> entrée)
                      - si la variable existe déjà dans l'environnement, accepter seulement si l'entrée est égale à sa valeur dans l'environnement, et ne pas enrichir l'environnement
                      • [^] # V

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

                        Oui oui, on est d'accord :)
                        C'est juste que = n'est pas un opérateur d'égalité (ou d'assignation), mais de « matching » (ou d'assignation).
                        Pour moi, un opérateur d'égalité rend une valeur vraie en cas d'égalité, et une valeur fausse en cas de différence. Comme je le faisais remarquer,

                        X=3, % assigne
                        Y=4, % assigne
                        X=Y. % lance une exception

                        montre bien qu' = n'est pas un test d'égalité.

                        C'est un truc que je trouve laid, mais auquel on s'habitue vite, car ça a ses avantages pratiques quand on code.
                        • [^] # Re: V

                          Posté par  . Évalué à 3.

                          Désolé de m'insérer dans la discussion mais je ne vois pas le rapport entre ta réponse et la remarque de bluestorm.

                          Nul part dans ce que fait remarquer bluestorm il n'est question du fonctionnement de l'opérateur "=". La remarque de bluestorm concerne le fonctionnement du filtrage dans Erlang.

                          En Erlang, quand tu utilises dans une règle de filtrage une variable à portée, le compilateur considère que tu filtres sur sa "valeur" et utilise donc la relation d'égalité (pas l'opérateur =) sur le type que tu es entrain de matcher pour savoir si la règle est satisfaite.

                          Prenons l'exemple de la règle (x,x) dans le filtrage d'un couple quand la variable x n'est pas définie. Selon le langage, on va distinguer trois comportements.
                          Le premier est celui d'Ocaml. Le compilateur refusera cette règle arguant que tu affectes à la variables x deux valeurs potentiellement différentes.
                          Le second est celui d'Erlang. Il commencera par affecter le premier élément du couple à x. Ensuite, puisqu'il rencontre la variable x déjà définie dans l'espace de nom courant, il test l'égalité entre le deuxième élément et la valeur de x. Si il obtient vrai, il considère la règle satisfaite sinon il passe à la suivante.
                          Un troisième comportement consiste à affecter à x la première valeur. Puis, puisque on rencontre x à nouveau, lui réaffecter la seconde valeur en "oubliant" la première.

                          Bluestorm reproche à Erlang de ne pas permettre d'utiliser ce troisième comportement. Là, on pourrait rétorquer qu'après tout, c'est un choix d'implémentation du filtrage. Il n'y a qu'à s'y plier.

                          Dans un sens, c'est vrai. Néanmoins, ce comportement est parfois pénible pour le programmeur parce qu'il l'oblige à connaître parfaitement les variables à portée quand il écrit une règle de filtrage.

                          En effet, considérons un exemple moins "extrême" que la règle (x,x). Quand je filtre un couple, j'utilise souvent la règle (a,b).
                          En Ocaml, je n'ai jamais de problème. Si a et b sont déjà définis, le filtrage les réaffectent dans un nouvel espace de noms.
                          En Erlang, pour peu que je n'ai pas fait attention aux variables à portée, je n'ai pas le comportement attendu. Et là, c'est le drame.

                          Reia met tout le monde d'accord en introduisant deux syntaxes permettant d'utiliser l'un ou l'autre des comportements au choix.
                          • [^] # Re: V

                            Posté par  . Évalué à 3.

                            Ton post est tout à fait fidèle à l'idée de ma remarque sur le filtrage : c'est ce que je veux dire.

                            Dans les détails, moi je ne réclame pas ton "troisième comportement" (qui me semble moins bien que les deux premiers; il faudrait au moins afficher un warning) mais plutôt avoir le choix entre le premier et le second, comme fait Reia.

                            Par contre, il y a quelque chose d'important que j'ai aussi essayé de faire passer, c'est que les deux premiers comportements ne sont pas symétriques. C'est mieux d'avoir les deux mais, si on choisit l'un des deux, il vaut mieux choisir le premier. Choisir le second et l'imposer est un grave défaut, mais choisir le premier et ne pas permettre le second est une limitation relativement négligeable.

                            En effet, les deux langages considérés possèdent la possibilité d'ajouter une "garde" au filtrage. Le comportement du pattern `{X, X}` de Erlang peut facilement se réécrire en `{X, Y} ... when X == Y`. C'est moins joli, un peu plus pénible à lire et à écrire, mais c'est une modification locale : elle n'affecte que le motif, et pas le reste du code. Elle est par ailleurs plus fine puisqu'elle permet de spécifier l'égalité souhaitée (sachant qu'il n'existe en généralité pas d'égalité canonique qu'on puisse choisir naturellement et dont le comportement soit satisfaisant dans tous les cas).
                            Dans l'autre sens (si on ne propose que le deuxième comportement), la modification à faire pour obtenir le premier comportement est globale : il faut regarder l'ensemble de l'environnement de la fonction pour choisir des noms convenable. Une modification locale est plus coûteuse (en temps, en réflexion, en mémoire mobilisée chez le programmeur, en risque de bugs, en travail de maintenance...) donc avoir seulement ce comportement est un problème.

                            Heureusement, comme l'a souligné Jerome Herman, le style idiomatique Erlang encourage les fonctions plutôt courtes, qui contiennent peu de déclarations locales. La portée de l'environnement à considérer quand on analyse un motif reste donc raisonnable en pratique. Mais il n'empêche que ça reste un problème global (à l'ensemble d'une déclaration toplevel) et non local, et qu'on a donc un exemple concret où la syntaxe *gène* la sémantique.
                • [^] # Re: Erlang

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

                  Un truc de ce genre, ptet ?

                  -module(toto).
                  -export([main/0]).

                  %% Retourne {false,3}
                  foo() ->
                    X = 3, % Assigne
                    R = case {1,2} of
                      {X,_} -> true; % teste si la première projection vaut 3. Vrai si oui,
                      _ -> false % Faux si non.
                    end,
                    {R,X}.

                  %% Retourne {true,1}
                  bar() ->
                    case {1,2} of
                      {X,_} -> X = X; % teste si la valeur est une paire, si oui, lie X et 1, puis
                                      % vérifie via pattern match si X = X est vrai.
                      _ -> X = ohmygod % assigne ohmygod à X sinon
                    end, %% Maintenant, X vaut 1, alors qu'on est sorti de la portée du CASE
                    {true,X}.

                  % Que retourne cette fonction?
                  % quux() ->
                  % X = 41,
                  % X = 42.

                  main() ->
                    %io:format("~w, ~w, ~w~n",[foo(),bar(),quux()]).
                    io:format("~w, ~w~n",[foo(),bar()]).
        • [^] # Re: Erlang

          Posté par  . Évalué à 3.

          Ben voyons, et tu vas me dire donc que XSLT est une syntaxe agréable? Pareil pour APL?
  • # Apprendre un langage par an, et..?

    Posté par  . Évalué à 3.

    Sauf à vouloir satisfaire sa curiosité personnelle, apprendre un langage par an, sans avoir de projets concret de long terme ne me semble pas présenter pas d'intérêt particulier. Je parlerai plutôt d'étude, que d'apprentissage.

    Chaque langage présentant ses spécificités, le mélange des genre risque même d'être plus préjudiciable qu'autre chose, à mon sens.

    Autant, apprendre plusieurs langues peut permettre de s'en sortir avec des confusions, autant plusieurs langages risquent de donner lieu à quelques combats épuisants et perdus d'avances contre les compilateurs et autres interpréteurs.
    • [^] # Re: Apprendre un langage par an, et..?

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

      > Chaque langage présentant ses spécificités, le mélange des genre risque même d'être plus préjudiciable qu'autre chose, à mon sens.

      Au contraire, apprendre des langages différents permet d'apprendre de nouvelles façons de programmer, y compris pour les langages que l'on maitrisait déjà. Par exemple, je connaissais relativement bien Ruby, puis quand j'ai appris un langage de programmation fonctionnel, mon style en Ruby a changé : j'ai utilisé plus souvent des méthodes comme map et inject, et j'ai tendance à écrire des méthodes avec beaucoup moins d'effets de bord. Bref, je trouve mon style en Ruby bien meilleur et j'ai probablement plus progressé que si je n'avais fait que du Ruby sur cette même période.

      Par contre, je te rejoins sur un point, apprendre plusieurs langages peut présenter des risques de confusion. Il faut donc mieux éviter de vouloir se lancer dans plein de langages tant que l'on n'en maitrise pas correctement un, et il vaut mieux choisir des langages avec des paradigmes différents : programmation fonctionnelle contre orientée objets, typage statique vs typage dynamique, le choix est vaste ;-)
  • # Pharo

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

    parce que Smalltalk a été et est toujours une référence de simplicité, de dynamisme et que IDE veut dire quelque chose .... http://pharo-project.org

    Et si vous voulez quelque chose qui fasse "hype", il y a Newspeak http://newspeaklanguage.org/
  • # Goto++

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

    Il faut de tout pour faire un monde, il faut aussi des GOTO évolués : http://www.gotopp.org/presentation.html.fr

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Différents langages

    Posté par  . Évalué à 8.

    Prolog

    Oz, et l'excellent livre Concept, Techniques and Models of Computer Programming.

    OCaml ou SML (parce que .NET, on sait pas si c'est le mal, mais on se doute bien qu'un peu quand même)

    Haskell (mais après avoir appris OCaml ou SML) ou éventuellement Clean

    Coq ou Agda (ou Epigram) (mais après avoir appris un langage fonctionnel statiquement typé)

    Forth ou Factor

    un Lisp (Common Lisp ou Scheme, principalement) ou éventuellement Dylan

    C ou un assembleur

    Smalltalk, ou Ruby ou Python ou Javascript ou Io
    • [^] # Re: Différents langages

      Posté par  . Évalué à 4.

      Bonne sélection!

      Les langages comme Forth et Factor son très amusant à apprendre, parfaits pour les vacances, quand on veut se changer les idées, faire quelque chose de nouveau, différent, exotique ... tout en restant devant son écran.

      Mais dans cette famille de langages, je préfère PostScript.

      Ça permet de faire de joli dessin directement à partir de votre éditeur de texte favori.

      http://amath.colorado.edu/documentation/postscript/ThinkingI(...)
      http://www.cappella.demon.co.uk/psfiles/pracpost.html
    • [^] # Re: Différents langages

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

      En ce qui concerne Coq et Agda, et sans doute Epigram, mais je ne connais pas assez, ces langages ne sont pas Turing-complets, donc en parler comme « langages de programmation », c'est discutable.

      Par ailleurs, parce qu'il vaut toujours mieux préférer l'original à la copie, je pense que OCaml est supérieur à F#. (Et puis le tout objet, c'est hideux).

      Sinon, dans les langages rigolos, il y a ATS.

      Et dans les langages exotiques, il y a Unlambda, parce que call/cc, c'est bien.
      • [^] # Re: Différents langages

        Posté par  . Évalué à 1.

        Je ne vois pas en quoi un langage non Turing-complet ne serait pas un langage de programmation. Obtenir un langage utilisable¹ qui se trouve du bon côté de la frontière de Turing, derrière laquelle c'est le chaos (on ne sait presque plus rien dire du comportement des programmes), est justement une grande victoire des types dépendants.

        ¹: à discuter. Mais plus utilisables que tout ce qu'on faisait avant dans le genre

        Pour moi, la construction d'automates pour calculer des propriétés de mots (le modulo deux d'un nombre binaire par exemple) est aussi une forme de programmation, bien que ce ne soit pasnon plus Turing-complet.
      • [^] # Re: Différents langages

        Posté par  . Évalué à 2.

        Salut, ocaml est français, et j'ai trouvé des TP sur le web pour ma familiariser avec :

        http://www.lri.fr/~filliatr/tp_caml.fr.html
        http://fabien.viger.free.fr/liafa/caml/

        Et tout ça pour dire que ocaml fait vraiment très plaisir à utiliser, et les performances sont au rendez vous. Par contre, ça me fait presque peur.

        De telles performances, et une telle expressivité, quel est le revers de la médaille ?

        Ceci dit, les profs qui proposent des choses là dessus, ce sont surtout des algo d'AI, ou des problèmes de math/concepts informatique.

        Ce n'est pas pour rassurer les partisans des « vraies choses en informatique » :)

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Différents langages

          Posté par  . Évalué à 2.

          Bof, suffit de rappeler que mldonkey c'est fait en OCaml, ça fait pas trop recherche poussée en AI qui n'intéresse que les matheux.

          Le seul reproche qu'on peut faire à OCaml, c'est son manque de bibliothèques.
          Pour le reste, c'est le seul (et oui LE SEUL) langage que j'ai essayé d'apprendre et qui m'a donné envie de le pratiquer pour de vrai.
          (Bon, j'ai pas été exhaustif, mais j'ai regardé plus ou moins vite fait le C, le C++, le Python et le Ruby).
          • [^] # Re: Différents langages

            Posté par  . Évalué à 2.

            Ah non, le principal reproche que je fais à OCaml, c'est de ne pas supporter l'UTF8.
            Mais je fais ce reproche à plein plein de langage. C'est con, je fais du traitement du langage, il me faut un langage de programmation capable de gérer du chinois, du français et de l'hindi en même temps, il y en a assez peu qui font l'affaire finalement (même python me prend un peu la tête avec ça, mais pour le coup c'est sans doute un problème d'interface chaise-clavier).
            • [^] # Re: Différents langages

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

              C'est quoi les problèmes typiques ? Tu as essayer perl ou Go qui sont censé être pure UTF8.

              Lisaac ne l'utilise pas encore mais j'ai du mal à voir ce qui est plus complexe que changer la gestion interne des string.

              "La première sécurité est la liberté"

            • [^] # Re: Différents langages

              Posté par  . Évalué à 3.

              Je ne sais pas exactement ce que tu veux dire par "ne pas supporter l'UTF-8", mais on peut bien sûr manipuler des chaînes UTF-8 avec OCaml, il y a d'ailleurs une bibliothèque logicielle spécialisée pour cela, Camomile : http://camomile.sourceforge.net/

              Ce qui est vrai, c'est que le type "string" continue à considérer qu'il manipule des tableaux d'octets. Ça n'empêche pas de manipuler des chaînes UTF8 en utilisant le type string (plutôt que les types spécialisés de Camomile, repris par la bibliothèque Batteries), mais du coup certaines fonctions ne marchent pas tout à fait comme on veut, par exemple String.length renverra le nombre d'octets et non pas le nombre de caractères. On fait largement avec.

              Enfin, certaines bibliothèques ou outils n'ont pas pris en compte les questions liées à UTF8. Par exemple il me semble que le générateur de lexeurs standard, ocamllex, ne gère pas bien les entrée UTF-8. Mais il existe un lexeur pensé pour ça, ulex.

              Bref, le support d'UTF8 dans OCaml est satisfaisant, dans le sens où bien qu'UTF-8 ne fasse pas partie de la spécification du langage ou des types built-in, on peut tout à fait travailler sur de l'UTF-8 et ça marche très bien.
              Si tu veux faire du "bête traitement de texte" où la fatigue liée à l'utilisation d'une bibliothèque spécialisée surpasse la difficulté de la tâche à effectuer au départ, ce n'est pas une bonne idée. Mais si tu veux faire des opérations et manipulations un peu compliquées sur tes données, et que la question de l'encodage n'est au final qu'un détail, il n'y a pas de raison de se gêner.

              (D'ailleurs beaucoup d'outils de linguistique computationnelle sont développés en OCaml)
            • [^] # Re: Différents langages

              Posté par  . Évalué à 2.

              En même temps pour un langage très proche d'OCaml et qui supporte utf-8 une piste proposée l'est dans le post initial : F#.
              Je rappel aux divers trolls que le langage est sous licence libre, et que depuis les premières releases le projet est mono friendly.
              Libre à vous de ne pas l'utiliser ou le tester mais ne venez pas vous plaindre que ça n'existe pas.
        • [^] # Re: Différents langages

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

          >> De telles performances, et une telle expressivité, quel est le revers de la médaille ?

          Une syntaxe de merde, des erreurs cryptiques genre « machin has type int instead of type int » (Je sais plus comment, mais on pouvait créer des erreurs de même), l'absence de macros (j'ai pas touché à camlp4)…

          Cela dit, j'aime bien, hein. J'en ai fait pendant longtemps.
          Mais ces temps-ci, je trouve plus agréable de programmer en Haskell (pour son côté paresseux), Gambit-C Scheme ou Common Lisp (pour leur expressivité)…
          • [^] # Re: Différents langages

            Posté par  . Évalué à 2.

            je trouve plus agréable de programmer en Haskell (pour son côté paresseux)

            Ouai, en fait tu préfères Haskell parce que t'es une feignasse!!

            ----------------> [ ]
    • [^] # Re: Différents langages

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

      Et lisaac ?
      • [^] # Re: Différents langages

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

        Je crois que l'intéret principal dans lisaac est d'avoir à la fois un code de haut niveau et performant.

        Java et sa jvm n'inlinant pas les getter, c'est forcément une cata en terme de performance.

        "La première sécurité est la liberté"

        • [^] # Re: Différents langages

          Posté par  . Évalué à 2.

          Euuuuh, tu es sûr ? Avec le JIT je suis presque certain que les accesseurs sont inlinés.
          • [^] # Re: Différents langages

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

            Je croyais aussi. Je parle de la VM de sun de java sous linux ("$ javac" et "$ java") que j'ai dispo dans la mandrake 10.0.

            J'ai du optimiser du code java pour le concours ai-contest, cité plus haut, et j'ai compris que le jit ne fait que l'équivalent simple d'une compilation (genre gcc -1). Des optimisation assez stupide, comme inliner à la main, avait des effets important sur les performances. Supprimer les new et les remplacer par des reset avait aussi une grosse importance.

            "La première sécurité est la liberté"

            • [^] # Re: Différents langages

              Posté par  . Évalué à 2.

              C'est extrêmement surprenant. Il fut un temps où oui, il fallait par exemple déclarer tout un tas de champs et méthodes "final" pour être certain que le compilateur allait faire ce qu'il fallait, mais depuis la VM et les méthodes de JIT se sont beaucoup améliorés, du coup je ne comprends pas... Tu utilises quelle VM ? Celle d'Oracle ?
              • [^] # Re: Différents langages

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

                oui, "l'officiel".

                En même temps, il annonce 1.5 de compile jit sur mon programme, gcc prendrait bien plus de temps. Même si gcc est lent, il n'y a rien de magique.

                "La première sécurité est la liberté"

      • [^] # Re: Différents langages

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

        Le problème de Lisaac, c'est que c'est pas un langage encore fini. Ca a beaucoup progressé, mais il y a encore du boulot.
        J'espère être réaliste en disant que dans deux ans on aura une stable (une version est en train d'être réécrite là)..

        Mais pour le moment, comme le dit Nicolas, Lisaac c'est pour le type qui veut de la perf tout en utilisant des choses qu'il a l'habitude de faire en Ruby et sans être obligé de coder en C++.
        Le compilateur actuel suffit très bien pour faire ça.

        C'est mon cas en ce moment, parce que je code un jeu web et c'est vrai que c'est un langage dans lequel on est assez vite à l'aise en fait*, et dans lequel on peut inventer toutes sortes de choses assez couillues, surtout avec les blocks et l'héritage qui un monde énorme à défricher.

        M'enfin c'est une question de gout, les pointeurs et les références, ça me fait fuir, certains adorent. Donc pour la perf, beaucoup de gens utiliseront encore C++



        *Je dis ça parce que j'avais jamais vraiment codé beaucoup en Lisaac, et j'en fait à haute dose depuis quelques semaines, en debugant le compilateur en passant.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Différents langages

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

          >> Lisaac c'est pour le type qui veut de la perf tout en utilisant des choses qu'il a l'habitude de faire en Ruby

          Tu réécris DLFP en Lisaac ?
          • [^] # Re: Différents langages

            Posté par  . Évalué à 2.

            pas loin, il réécris un compilateur Lisaac en Templeet...
          • [^] # Re: Différents langages

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

            Je pars 2 jours en vacances en bretagne, en me disant "chouette, quand je vais revenir, j'aurais peut être un commentaire interessant ?"
            De toi, dont je lis toujours les commentaires avec grand intérêt, je m'attendais à mieux :-(

            Je voulais juste dire que on peut créer des structures de contrôles, créer des fonctions de fonctions (curryfication), jouer avec l'héritage, etc...
            Toute chose qu'on ne peut faire avec C++, sans perdre de perfs.

            En ce qui me concerne, mais c'est juste personnel, j'apprécie cela quand je code.

            Joyeux noël !

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Différents langages

      Posté par  . Évalué à 1.

      OMG.

      Il y a un tutorial d'enfer en ligne pour Haskell:

      http://tryhaskell.org/

      Jusque là ça ressemble beaucoup à OCaml (ce qui est vraiment un avantage).

      Yeah \o/
  • # LISP

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

    Vu la claque que plus de 4600 personnes ont pris cette année par ce monsieur : http://ai-contest.com/profile.php?user_id=8565 un bon paquet de gens vont s'amuser (ou retourner s'amuser) avec du Lisp.
    Au moins pour comprendre les algos qu'il a utilisé.
    • [^] # Re: LISP

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

      ((ou) pas) :)
    • [^] # Re: LISP

      Posté par  . Évalué à 3.

      Bof, j’ai pas spécialement besoin de connaître un langage pour décrypter un algo codé avec. Juste la syntaxe de base.

      Par contre c'est rudement malin d'avoir faire ça en Lisp. Toute personne n'ayant pas la compétence "Faire abstraction de parenthèse" au niveau maximum ne pourra pas le copier !

      Futé futé.
      • [^] # Re: LISP

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

        Est ce que ta deuxième phrase n'est pas en contradiction directe avec la première ?
        • [^] # Re: LISP

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

          Comprendre est une chose. Savoir modifier le code et garder le même nombre de parenthèses ouvrantes et fermantes (de préférence aux bons endroits) en est une autre :p
          • [^] # Re: LISP

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

            Ouais, enfin si tu programmes avec notepad, c'est *ta* faute.
            On code en Scheme/Lisp avec des éditeurs qui gardent/indiquent le balancement correct de parenthèses. Tu peux même avoir une coloration différente en fonction de la profondeur.

            Et d'ailleurs, les parenthèses font le même effet visuel que l'indentation, mais rendent impossible une erreur dans un programme à cause d'une indentation foireuse…
            • [^] # Re: LISP

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

              "les parenthèses font le même effet visuel que l'indentation,"

              Non, mets tout sur la même ligne et l'effet visuel n'a rien à voir.
              Ce qui fait le même effet que l'indentation... c'est l'indentation, qui permet de repérer plus facilement s'il manque une parenthèse (ou une accolade suivant le langage).

              Et pour le "rendent impossible une erreur dans un programme à cause d'une indentation foireuse… " si l'indentation est foireuse et que les parenthèses sont correctes, alors c'est que l'indentation ne reflète pas visuellement la façon dont tu penses que ton code est structuré. Peut-être que le code est correct, mais quelqu'un qui le relis risque de passer à coté de la structure de ton code, parce que l'indentation est plus visuelle que les parenthèses.

              Avantage aux parenthèses ou accolades: les outils automatiques peuvent remettre en ordre l'indentation du code pour qu'il soit lisible.

              Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

              • [^] # Re: LISP

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

                Techniquement, et avec un peu de pratique, même sur une seule ligne, tu t'en sors : les parenthèses retirent toute ambiguïté.
                Mais oui, je conçois que ma phrase était rentre-dedans.

                L'avantage, c'est que l'indentation qui découle du parenthésage et la structure du code sont interdépendants.
                Le coup classique du if test1 then if test2 then foo else bar relève alors plus de la faute grave que de la faute d'étourderie. Si ton langage est basé uniquement sur l'indentation, quelques espaces en plus ou en moins sur le else bar risquent d'avoir un effet pervers sur ton code… (nota : en CL ou Scheme, on utilisera (when test1 (if test2 foo bar)) ou (if test1 (when test2 foo) bar) pour rajouter une couche de clarté à ce que la commande d'indentation automatique de ton éditeur aura déjà exprimé pour toi.
                • [^] # Re: LISP

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

                  > les parenthèses retirent toute ambiguïté.
                  en fait ça retire tout ambiguïté au fait que c'est illisible, non ?
                • [^] # Re: LISP

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

                  Le problème, c'est que les parenthèses retirent l'ambiguïté au niveau du compilateur / interpréteur, mais qu'au niveau du programmeur humain la chose la plus visuelle est l'indentation.

                  Si les parenthèses/accolades ne reflètent pas l'indentation, alors il y aura un jour une divergence entre la compréhension du code par un lecteur humain et la compréhension du code par la machine. Peut-être pas par l'auteur, qui sait ce qu'il a écrit et pourquoi, mais par un autre, qui essaiera de comprendre ce que fait le code.

                  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                  • [^] # Re: LISP

                    Posté par  . Évalué à 2.

                    Les paranthèses font parties du langage, ce n'est pas un détail ou un truc rajouté pour faire joli (ou faire moche).

                    Je conseille cet article qui explique très bien le pourquoi de la chose:
                    [http://www.defmacro.org/ramblings/lisp.html]
                    • [^] # Re: LISP

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

                      Mon post n'est pas spécialement relatif à lisp et à son utilisation des parenthèses, mais à la lecture du code, à l'indentation et à la relation indentation / parenthèses ou accolades.

                      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                  • [^] # Re: LISP

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

                    >> Le problème, c'est que les parenthèses retirent l'ambiguïté au niveau du compilateur / interpréteur, mais qu'au niveau du programmeur humain la chose la plus visuelle est l'indentation.

                    C'est pas un problème !
                    C'est même un avantage certain !
                    Vu que les parenthèses reflètent la structure du code, tu peux, de manière automatique et sans ambiguïté, recréer l'indentation, la bonne seule et unique qui correspond à l'intention du programmeur (s'il a écrit ce qu'il voulait écrire), et à celle de toute personne qui sait lire un programme.

                    Donc, impossible de se tromper, vu que l'indentation *dépend* du parenthésage, et que le parenthésage est en bijection avec la structure intentionnelle du code.
    • [^] # Re: LISP

      Posté par  . Évalué à 2.

      Et pour ce faire, on pourrait lire le très chouette Land of Lisp ! http://landoflisp.com/

      Je le lis actuellement, et m'amuse bien. Que c'est rafraîchissant de programmer des petits jeux (mais pas que) pour découvrir le langage, le tout accompagné d'amusantes illustrations. Sans pour autant remettre en question la qualité technique de l'ouvrage !

      Common Lisp y est à l'honneur, mais ça donne les clefs au lecteur pour appréhender les autres dialectes populaires, tel Scheme et Clojure.

      Simple but refined, guaranteed to blow your mind.
    • [^] # Re: LISP

      Posté par  . Évalué à 1.

      Dans la famille des Lisp, il y Scheme qui est pas mal.
  • # Perl 6

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

    Évaluation paresseuse, superpositions quantiques, autothreading, inférence de type,... et un super logo convivial : http://perl6.org/

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Perl 6

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

      Oui, ainsi que la possibilité d'utiliser le typage statique, les minilangages, ou les jonctions.

      C'est vraiment un langage étonnant !

      Je suis en train de le découvrir avec le calendrier de l'Avent Perl6 : https://perl6advent.wordpress.com

      Il y a des choses bien pratiques comme ce système très simple de création d'arguments pour des programmes "en ligne de commande" (je reprends les exemples de perl6advent ) :


      $ cat add.pl
      sub MAIN($x, $y) {
      say $x + $y
      }
      $ perl6 add.pl 3 4
      7
      $ perl6 add.pl too many arguments
      Usage:
      add.pl x y


      Et des choses très amusantes comme l'opérateur de séquence :


      > my @Fibonacci := 0, 1, * + * ... *; 1;
      1
      > @Fibonacci ...^ * > 10000
      0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765
      > @Fibonacci[30]
      832040


      Et plein d'autres trucs bien évidemment.
      • [^] # Re: Perl 6

        Posté par  . Évalué à -2.

        C'est marrant, mais quand j'entends perl, j'ai envie de me cacher dans un trou... Ce langage ne me donne pas du tout, mais alors pas du tout envie... Quand je sais son évolution, je ne vois pas l'intérêt de l'utiliser...

        Peut être avec un nouveau nom ils seraient resté crédible, mais après toutes ces modifications, continuer à appeler ce langage perl, c'est un peu bizarre. À au fait j'ai entendu dire que
        P. E. R. L. = Pathetically Eclectic Rubbish Language

        Ça n'empêche rien au fait que je ne connais pas le langage, et gagnerai peut être à l'utiliser, mais je trouve sa syntaxe un peu trop à mi-chemin entre le pote de bistrot et l'ésotérisme..

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Perl 6

          Posté par  . Évalué à 4.

          "Ça n'empêche rien au fait que je ne connais pas le langage, et gagnerai peut être à l'utiliser, mais je trouve sa syntaxe un peu trop à mi-chemin entre le pote de bistrot et l'ésotérisme.."

          Je ne te connais pas, mais t'a l'aire d'un mec pas intéressant du tout. Peut être que si tu changeait de pseudo ça irais mieux mais là j'ai pas envie de te connaître.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Perl 6

          Posté par  . Évalué à 1.

          Je connais le langage (Perl5 pas Perl6 qui est un tout autre langage malgrès le nom) et plus je connais moins j'aime donc je suis d'accord que tu ne loupes rien.

          C'est un langage assez difficile a apprendre, les débutants font donc du code assez horrible, ça c'est assez normal, par contre là ou c'est plus génant c'est que les gens expérimenter en Perl ont développer chacun leur propre style et là niveau maintenance c'est pas terrible!

          • [^] # Re: Perl 6

            Posté par  . Évalué à 3.

            Les langages sont fondamentalement amoraux. La langue n'est pas le niveau auquel on devrait obliger à "penser bien", si l'on veut un langage utile. On ne peut garantir la moralité par la syntaxe.
            Larry Wall, créateur de Perl.

            Si on veut que les gens expérimentés programment tous de la même façon, alors il faut définir un "coding standard". Sinon, que ce soit Perl, Ruby, C ou PHP, chaque développeur fera sa propre cuisine. A une moindre échelle, même en Java ou C#, langages bien plus contraignants, si personne n'impose de conventions, c'est le bazar.

            A propos de l'acronyme "Pathologically Eclectic Rubbish Lister", il est de Larry Wall lui-même. C'est amusant de voir cette auto-dérision utilisée à charge.

            Si vous avez essayé Perl sans rien en ressortir de positif, c'est bien dommage. Je comprends qu'on n'apprécie pas sa syntaxe, mais il y a plein de principes intéressants qui ont très fortement influencé d'autres langages. Personnellement, je recommande souvent Perl et un langage Lisp ou Haskell pour encourager à voir la programmation autrement.

            Sinon, je suis étonné que l'importance de l'objectif n'aie pas encore été mentionnée. Pour de l'admin sys, je n'ai rien trouvé qui vaille Perl. Mais Ruby, Haskell, PHP ou C++/Qt ont leurs points forts dans d'autres domaines. Même Java, paraît-il ;-)
            • [^] # Re: Perl 6

              Posté par  . Évalué à 3.

              Mouai, bah il peut défendre son TMTOWTDI tant qu'il veux Larry Wall, moi je vois que quand je lis du code Perl, 9 fois sur 10, ça m'explose le cerveau ce qui est moins le cas pour du Python (et aussi Ruby): et pourtant j'ai eu une formation en Perl mais pas en Python!

              Donc si j'ai le choix entre faire du Perl ou du Ruby|Python, je ne choisirai pas Perl, malheureusement je n'ai pas le choix à cause de la base installée en Perl: de mon point de vue, Perl est le COBOL des langages de scripts.

              Pour ce qui est de voir le coté programmation par script, bof, a par le poids de l'existant, je ne vois pas trop ce que Perl apporte par rapport a Ruby ou Python.
              • [^] # Re: Perl 6

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

                Perl est le COBOL des langages de scripts

                Mouarf !

                Il faudrait déjà savoir ce qu'est un "langage de scripts" pour pouvoir dire ce genre de chose ;)

                Si par langage de scripts il faut entendre : "langage conçu pour réaliser de petits programmes servant de glu entre différents programmes".

                Alors soit Perl n'est pas un langage de scripts, car il sait faire bien plus que cela, soit il en est un mais alors TOUS les langages de programmation sont des langages de scripts.

                Il est vrai que Perl est un excellent langage de progra généraliste, mais est également une très bonne glu ;)
                • [^] # Re: Perl 6

                  Posté par  . Évalué à 5.

                  Pour s'embourber dedans.

                  (-->[])
              • [^] # Re: Perl 6

                Posté par  . Évalué à 1.

                Dans cette logique, je te conseille de jeter un oeil du côté des bibliothèques MOTIF/X11 pour ksh. Il y a quelques années, tous les outils d'admin' Solaris (et AIX peut-être) étaient fait ainsi.

                Un équivalent doit être possible en bash d'ailleurs...

                Le plus souvent cryptique, ça permet tout de même de faire des choses très intéressantes sans tout une chaine de compilation derrière

                Indépendamment, La syntaxe d'un langage est aussi affaire de goût.
                Pour ma part, j'ai toujours adoré Perl et ses expressions régulières.
                A contrario, j'ai horreur de Ruby.
                On ne doit pas être sur les mêmes "Rails" :)
              • [^] # Re: Perl 6

                Posté par  . Évalué à 2.

                L'excellent ouvrage "De l'art de programmer en Perl" [http://www.eyrolles.com/Informatique/Livre/de-l-art-de-progr(...)] - qui d'ailleurs s'applique à beaucoup d'autres langages - t'apprendra à faire du code propre, lisible et parfaitement maintenable en Perl.

                On peut écrire des choses illisibles dans bien des langages, mais ce n'est jamais obligatoire. Ce n'est pas un prérequis pour qu'un script Perl fonctionne, en tout cas.
        • [^] # Re: Perl 6

          Posté par  . Évalué à 1.

          Effectivement quand tu parcours du code en Perl, il arrive souvent qu'il faille plusieurs relectures pour comprendre ce qui a été codé.
          Mais ce langage est redoutable d'efficacité pour faire le lien entre des opérations d'administration sur un système (Linux, HP-UX, Solaris etc... et Windows). Bref pour remplacer bash + awk .... (pas taper! (troll détecté)).
          Cette facilité à faire du lien, c'est aussi une facilité à faire du vite et "crade", bien connu de nombreux admins sous pressions (pas taper! ...).
          Il est alors assez inquiétant de s'apercevoir, en relisant son propre code, datant de seulement quelques mois (et rédigé un jour de grande forme ;) ) que l'implémentation semble très obscure (ceci sans avoir abusé de substances illicites).
          Et, je ne parle pas d'un code pondu il y a des années, par un débutant (ou pire un super "bon"), pressé de passer à autre chose.....

          Je préfère des langages où il n'y a pas 36000 façons de faire une chose.
          • [^] # Re: Perl 6

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

            Ce qu'il y a d'extraordinaire avec Perl ce sont les clichés qu'il trimballe.

            Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit)

            Tout le monde dit que Perl c'est un truc fait pour faire des petits scripts auxquels qu'on ne retouche jamais, donc on le répète.

            Bien souvent, ceux qui répètent ces âneries n'ont jamais touchés sérieusement à Perl.

            La vérité c'est que la communauté Perl a mis en place des "bonnes pratiques" depuis longtemps. Les idiomes sont connus. Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE.

            Dernièrement est sorti un français un petit ouvrage qui s'intitule Perl Moderne, ça devrait dépoussiérer le cerveau de nombre de lecteurs de nombreux clichés.

            Je préfère des langages où il n'y a pas 36000 façons de faire une chose.

            Là oui, c'est un vrai argument.

            On compare dans ce domaine deux langages : Python et Perl. On a bien raison, ils sont sur ce point réellement antagonistes.

            Perl est un langage conçu pour pouvoir être parlé de diverses manières, un peu comme une langue vivante. Il y a le langage familier, grossier, ordurier, noble, technique etc.

            Python est langage conçu pour n'être parlé que d'une manière. Un peu comme les langues mortes encore utilisée dans des cadres très spécifiques.

            Ainsi en Perl quasiment TOUT est réellement possible : programmation objet (divers modèles de OO), programmation fonctionnelle, orientée aspect programmation en latin ;) etc. Tout de diverses manières.

            En Python, il faut se limiter aux choix de GvR :

            GvR n'aime pas la progra concurrente ? Hop un GIL !

            GvR n'aime pas les récursions terminales ? Zou, à la trappe :)

            GvR ne croit pas en la progra fonctionnelle ?

            Etc. etc,

            Perl et Python sont vraiment des langages de caractère, c'est certains ;)

            Entre un langage qui offre les moyens de faire ce que l'on veut de diverses manières et un autre qui vous impose les convictions de son concepteur, il y a sans doute de nombreux intermédiaires.

            Mais une chose est certaine, ces deux langages là ont leur caractère ;)

            P.S. : j'ai coutume de dire que Python pourrait très bien être un sous-ensemble de Perl...
            • [^] # Re: Perl 6

              Posté par  . Évalué à 2.

              >>Ce qu'il y a d'extraordinaire avec Perl ce sont les clichés qu'il trimballe.<<

              Bof, certains des clichès invalides, tu les as ressorti toi même (je ne me souviens pas avoir lu dans ce sujet que Perl n'était utilisé que pour de petit programmes et c'est faux hélas).

              >> Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit) <<

              Si tu manges sans sel ce n'est pas très bon, si tu manges trop salé, ce n'est pas bon non plus.
              Créer un langage qui soit utiliser pour faire des programmes lisibles 'par défaut', c'est comme faire la cuisine c'est un équilibre délicat: il ne faut pas être trop artificiel comme Lisp ou trop 'baroque' comme le Perl, ceci dit il y a encore pire que le Perl: APL!


              >> Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE <<

              Je ne dirais pas facile, mais juste "pas difficile".
              Le problème c'est que:
              1) ce n'est pas le comportement par défaut donc les débutant ne le font pas
              2) ce n'est pas vraiment encouragé car beaucoup d'exemples que tu trouves sur le web n'utilisent même pas les bases comme 'use strict' et autre.
              3) très peu de programmeurs expérimenté le font, car ils préfèrent utiliser leur idiome..
              Donc ce qui est facile en théorie, est rarement appliqué en pratique..


              • [^] # Re: Perl 6

                Posté par  . Évalué à 3.

                Mmmh, nous n'avons pas eu les mêmes expériences de programmation Perl en entreprise alors. Il y a huit ans, lorsque je faisais du Perl pour la première fois « sérieusement », use strict et use warnings étaient obligatoires. Il n'y avait pas de « style » à suivre à proprement parler, si ce n'est de mettre des parenthèses aux appels de fonctions, et ne pas utiliser les variables implicites -- ou alors bien expliquer ce que faisait le code en commentaire et pourquoi faire ainsi, lorsque ça se justifiait, du genre :


                use strict;
                use warnings;
                # code avant ...
                my $content;
                # $! n'est pas expliqué dans le code car on apprend très vite qu'il est équivalent à
                # ce que renvoie perror() ...
                open (my $fh, '<', $file) || die "Could not open $file: $!";
                # "Slurps" the file into $content. Making $/ local undefines it for the local scope
                # and stops it from separating the file into "lines" with the '\n' character.
                {
                    local $/;
                    $content = <$fh>;
                }
                # code après ...


                Ce code est idiomatique (on le trouve un peu partout dans pas mal de tutoriels/bouquins), et nécessaire (le fichier à lire était un fichier binaire -- une image). Évidemment, ce code a vite été mis dans une fonction slurp ... :)

                Le code était maintenable, car il était de toute manière lu et partagé par d'autres qui pouvaient avoir besoin de jeter un œil. Et contrairement à ce que tu sembles dire, un débutant peut parfaitement avoir de bonnes bases : il suffit qu'il ait été bien formé -- en l'occurrence je sortais plus ou moins d'IUT, où l'on m'avait appris à correctement nommer mes variables, indenter mon code et le modulariser ... Bref, ce qu'il faut savoir faire en C, Java, ou autres langages.
      • [^] # Re: Perl 6

        Posté par  . Évalué à 3.

        J'ai écrit récemment une dépêche relativement complète sur Perl 6, et moi aussi j'avais des étoiles dans les yeux en découvrant le langage (dans lequel j'ai du m'immerger un peu de force pour essayer d'être pertinent). Au final, j'étais content parce que Perl 6 empruntait des choses à des langages que j'aimais bien, notamment Haskell.

        Ça fait quelques mois maintenant que je n'ai pas lu de Perl 6, et si je me souviens bien de l'opérateur * servant à plein de choses différentes, j'ai un peu perdu les réflexes que j'avais acquis. Notamment, comprendre la définition de la liste Fibonacci ne me semble pas évident (je veux dire, comprendre pourquoi ça marche). En Haskell, en revanche, avec plus de mots et moins de symboles, ça donne

        > let fibo = 0 : 1 : zipWith (+) fibo (tail fibo)
        > takeWhile (< 10000) fibo
        [0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765]
        > fibo !! 30
        832040


        Et si j'ai des doutes sur le comportement d'une fonction (par exemple que je ne connais pas zipWith), son type m'aide bien souvent à deviner ce qu'elle fait :

        > :t takeWhile
        takeWhile :: (a -> Bool) -> [a] -> [a]
        > :t zipWith
        zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
  • # F# et Linux

    Posté par  . Évalué à 4.

    Est-ce que F# fonctionne vraiment sous Linux avec Mono ?

    J'ai toujours un peu l'impression que c'est juste histoire de dire que cela peux fonctionner sous Linux ...

    De plus quand je vois monodroid ou monotouch, j'ai comme l'impression que je suis pas un fan de Novel !
  • # Code Complete

    Posté par  . Évalué à 2.

    Sur les bonnes pratiques de programmation j'ai acheté le bouquin Code Complete [1], j'ai pas encore tout lu mais je peux dire que c'est un bon bouquin, le seul défaut c'est que c'est édité par Microsoft Press (mais il n'y a pas grand chose à voir avec crosoft dedans).

    Bon maintenant il est un peu plus gros que The Pragmatic Programmer (900 pages contre 350).

    Les libristes ils lisent quoi d'habitude dans ce sujet ? (bon OK vous allez me répondre : le code d'autres programmes ;)

    [1] http://www.amazon.fr/Code-Complete-Steven-C-McConnell/dp/073(...)
    • [^] # Re: Code Complete

      Posté par  . Évalué à 4.

      Les libristes ils lisent quoi d'habitude dans ce sujet ?

      Au moins The C Programming Language et The Art of Computer Programming

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Code Complete

        Posté par  . Évalué à 2.

        Bien entendu en faisant tous les exercices de The Art of Computer Programming
        • [^] # Re: Code Complete

          Posté par  . Évalué à 3.

          A ce propos Knuth demande de l'aide sur les exercices du tome 4 (volume 4a). Ça se passe là:
          http://www-cs-faculty.stanford.edu/~knuth/news.html

          Pour ma part je viens de lui envoyer une correction - ça y'est c'est la gloire, j'ai trouvé une faute chez Knuth! bon c'est juste une correction sur son site web, ça ne vaut pas un 0x$1.00, mais il y a un début à tout. ;-)

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Code Complete

        Posté par  . Évalué à 1.

        C'est pas vraiment le même sujet. Les deux (ou plutôt les 4) bouquins que tu cites n'expliquent pas je pense les techniques pour être le plus efficace en programmant et produire du code de meilleure qualité.
        • [^] # Re: Code Complete

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

          produire du code de meilleure qualité.

          C'est bien le thème de "the art of computer programming", non ?
    • [^] # Re: Code Complete

      Posté par  . Évalué à 2.

      Art of programming, probablement

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Aux conquérants de l’inutile!

    Posté par  . Évalué à 0.

    Si certains nouveaux langages de programmation sont d’un point de vue académique à priori intéressant, dans l’industrie par contre le choix des langages de programmation reste restreint voire très conventionnel.

    Je trouve d’autre part que cette tendance lourde chez les étudiants informaticiens de se passionner pour tel ou tel nouveau langage d’ailleurs plutôt infantile et pas forcément utile pour leur avenir professionnel.

    La plupart des informaticiens semblent d’ailleurs ignorer que la plupart des programmes demandés dans l’industrie automatisent en fait une technique et un savoir faire particulier. Le programme n’est qu’un outil qui facilite le travail et non une fin en soi.

    Dans la société où je travailles, nous avons souvent de sérieux problèmes à faire comprendre aux informaticiens que nos spécifications doivent être respectées de façon impérative car dictée par des critères technologiques et ergonomiques. Il est tout à fait possible que notre point de vue ne leur simplifie pas la tâche mais après tout c’est la vie et on ne leur demande pas d’être des spécialistes en ce qui nous concerne en électrotechnique.

    D’autre part j’ai souvent remarqué que l’intérêt pour tel ou tel langages est souvent lié à la liberté (certains diront créativité !) laissée aux programmeurs pour rendre leur « œuvre » accessible qu’à eux-mêmes.
    • [^] # Re: Aux conquérants de l’inutile!

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

      Tu viens de décrire l'un des trucs les plus repoussant du monde "professionnel". Dans beaucoup d'entreprises, le développeur n'a aucune liberté et ne fait qu'appliquer un cahier des charges stricte en utilisant des technologies parfois inadaptés mais imposées car la main d'œuvre y est moins chère.
      Le programmeur passionné a envie de choisir le langage adapté en fonction du projet. Mais je comprend que le laisser coder dans un super langage que lui seul connait risque d'être un problème.

      Je me suis intéressé à un certain nombre de langages différents et c'est grâce à cela que je suis aujourd'hui capable de comprendre plus rapidement de nouveaux langages. L'informatique est ma passion et si je trouve ça passionnant d'apprendre un nouveau langage, grand bien m'en fasse. Je ne vois pas pourquoi tout ce que j'apprends devrait être forcément utile professionnellement si je le fais sur mon temps libre. On me fait manger déjà assez de Java/EJB/WS/WSDL/CORBA/JSP/... en cours.
      • [^] # Re: Aux conquérants de l’inutile!

        Posté par  . Évalué à 4.

        IJe ne pense pas que l’ouvrage cité au début de l’article traite du temps libre des informaticiens mais plutôt de moyens d’augmenter sa « valeur marchande » en tant que programmeur. Les termes employés « Pragmatic » ou « Portfolio » sont d’ailleurs je crois assez clair !
        En ce sens d’ailleurs je ne suis pas d’accord avec ce point de vue et comme je l’ai titré plus haut est une approche de conquérants de l’inutile.

        Etant un informaticien devenu ingénieur en productique je vois les choses autrement et personnellement j’ai un autre avis sur la question : Comment en pratique un programmeur devrait augmenter son portfolio de connaissance.

        Au lieu d’apprendre un nouveau langage de programmation, la plupart des informaticiens devraient plutôt parfaire leur connaissance du langage …humain que ce soit sous forme écrite ou verbale.

        Une spécification mal comprise, interprétée de travers voire pire « améliorée » donnera quelque soit le langage de programmation utilisé un résultat non conforme. Le fait d’apprendre x langages de programmation n’apportera pas vraiment de valeur ajoutée aux connaissances.

        En pratique d’ailleurs je conseillerai plutôt aux programmeurs d’approfondir plutôt leur connaissance dans le domaine où leur application sera utilisée, car cela permet d’éviter les erreurs les plus grossières et aussi de poser les bonnes questions quand une spécification est incomplète voire imprécise.
        • [^] # Re: Aux conquérants de l’inutile!

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

          > Je ne pense pas que l’ouvrage cité au début de l’article traite du temps libre des informaticiens mais plutôt de moyens d’augmenter sa « valeur marchande » en tant que programmeur.

          Le livre traite de comment devenir un meilleur programmeur. Après, on peut l'appliquer dans un contexte professionnel ou sur son temps libre, libre à chacun de choisir.

          > Au lieu d’apprendre un nouveau langage de programmation, la plupart des informaticiens devraient plutôt parfaire leur connaissance du langage …humain que ce soit sous forme écrite ou verbale.

          Il y a aussi quelques conseils à ce sujet dans le livre The Pragmatic Programmer ;-)

          > En pratique d’ailleurs je conseillerai plutôt aux programmeurs d’approfondir plutôt leur connaissance dans le domaine où leur application sera utilisée.

          Tiens, encore un conseil présent dans The Pragmatic Programmer.

          > Une spécification mal comprise, interprétée de travers voire pire « améliorée » donnera quelque soit le langage de programmation utilisé un résultat non conforme.

          Oui, mais bon, j'ai vu tellement de spécifications mal écrites, incomplètes, inconsistentes ou qui changent à de multiples reprises que j'ai du mal à croire que s'en tenir stricto sensu à des spécifications est le chemin de la réussite. Après, cela doit sûrement dépendre du domaine.
          • [^] # Re: Aux conquérants de l’inutile!

            Posté par  . Évalué à -2.

            Ayant survolé la description du livre, je me doutais un peu que ce pavé contenait bien plus que le conseil d'apprendre un nouveau langage de programmation par an.
            En cela ta dépêche est très réductrice car l'aspect que tu mets en exergue semble n’être qu’une petite partie de l’ouvrage en question.

            J’ai surtout l’impression que tu te sers du bouquin comme « alibi » pour énumérer les langages de programmation que tu aimerais apprendre et attendait des commentaires des avis sur ceux-ci.
            • [^] # Re: Aux conquérants de l’inutile!

              Posté par  . Évalué à 2.

              Les auteurs mettent à disposition sur leur site les conseils (slogans) principaux de leur livre :
              http://pragprog.com/the-pragmatic-programmer/extracts/tips
            • [^] # Re: Aux conquérants de l’inutile!

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

              > En cela ta dépêche est très réductrice car l'aspect que tu mets en exergue semble n’être qu’une petite partie de l’ouvrage en question.

              peut-être parce que la dépêche traite du choix d'un langage à apprendre pour 2011 et non du bouquin...

              > J’ai surtout l’impression que tu te sers du bouquin comme « alibi » pour énumérer les langages de programmation que tu aimerais apprendre et attendait des commentaires des avis sur ceux-ci.

              Attends, je reprend le contenu de la dépêche :
              > l'un m'a particulièrement marqué : il est souhaitable d'apprendre un nouveau langage de programmation tous les ans
              > je souhaite partager avec vous quelques suggestions de langages
              > je n'ai pas encore choisi quel langage j'allais étudier en 2011
              > je n'ai pas encore choisi quel langage j'allais étudier en 2011

              Ha ok, en fait c'est bien ça, tu viens juste de comprendre la dépêche.
              Si on met ça en relation avec un autre post disant que souvent on trouve la solution sois même sauf qu'il faut tout lire ... ça fait sourire ;-)
        • [^] # Re: Aux conquérants de l’inutile!

          Posté par  . Évalué à 2.

          Tu en dis trop ou pas assez, tu penses à des exemples précis ?

          L'électrotechnique ça a l'air d'un truc très bas niveau pour un informaticien. Les spécifications en question ressemblent à quoi ? Qu'est ce qui est le plus susceptible de foirer dans la communication informaticien / électrotechnicien de ton point de vue ?
        • [^] # Re: Aux conquérants de l’inutile!

          Posté par  . Évalué à 1.

          Pour ma part, ce que je conseillerai aux développeurs, sans partir dans des considérations de niveau Ingénierie Système (besoin, concepts, exigences, spécifications...), serait de s'intéresser aussi aux problématiques IVQ (Intégration, Validation & Qualification).
          Ca permettrait déjà de se comprendre au niveau de l'équipe de réalisation et d'anticiper ("Risques & Opportunités", le truc qui passe à 10000 au-dessus des têtes en général hormis le PM)...

          Produire des spécifications intelligibles serait aussi un sujet à débattre (avec celui de savoir les lire) :)

          Bref, le développeur (terme bien vague) devrait être le trait d'union entre architecture et intégration à minima... pas seulement un technicien (avec moult langages) hors pair.
          • [^] # Re: Aux conquérants de l’inutile!

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

            Des spécifications ? Pourquoi faire ? :D
            • [^] # Re: Aux conquérants de l’inutile!

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

              Je dirais pour savoir ce que tu es en train de faire.

              Cela me rappelle le format PAR de découpage de fichier qui a été proposé en certification : cela a permit de trouver un bug dans la façon de calculer un hash (de mémoire).

              Dans la vrai vie, on a un prototype qui sert à écrire une spécification. Celle-ci est elle-même prototypé, pour la valididé, la compléter. Ensuite, peut commencer le vrai développement (avec des bouts des étapes d'avant).

              "La première sécurité est la liberté"

    • [^] # Re: Aux conquérants de l’inutile!

      Posté par  . Évalué à 5.

      Dans la société où je travailles, nous avons souvent de sérieux problèmes à faire comprendre aux informaticiens que nos spécifications doivent être respectées de façon impérative car dictée par des critères technologiques et ergonomiques.

      Ça doit venir du fait que la plupart du temps les spécifications sont données sans vraiment réfléchir et parfois même contradictoire, il est donc normal de les adaptés dans ce cas.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Aux conquérants de l’inutile!

        Posté par  . Évalué à 3.

        Ça doit venir du fait que la plupart du temps les spécifications sont données sans vraiment réfléchir et parfois même contradictoire, il est donc normal de les adapter dans ce cas
        Ce cas arrive certes mais dans ce cas les adapter de son propre chef est en fait la plus mauvaises des solutions !
        La seule et bonne réaction est de la signaler et de demander des précisions. Même si parfois le simple bon sens permet de trouver « tout seul » la solution, celle-ci se trouve à un autre endroit du cahier des charges que par manque de temps ne fut que survoler.
        • [^] # Re: Aux conquérants de l’inutile!

          Posté par  . Évalué à 6.

          Tout le monde n'a pas un contact facile avec client et des deadlines souples. J'ai l'impression de lire un cours d'analyse. La différence avec la réalité est parfois énorme.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Aux conquérants de l’inutile!

      Posté par  . Évalué à 6.

      … tendance lourde chez les étudiants informaticiens de se passionner pour tel ou tel nouveau langage d’ailleurs plutôt infantile et pas forcément utile pour leur avenir professionnel.
      Leur avenir professionnel, ce n’est pas ton problème.

      Dans la société où je travailles, nous avons souvent de sérieux problèmes à faire comprendre aux informaticiens que…
      Mon dieu, que de soucis…!
      Vivement que les étudiants comprennent que leur destin est de faire la pute…
      • [^] # Re: Aux conquérants de l’inutile!

        Posté par  . Évalué à 1.

        >>>Vivement que les étudiants comprennent que leur destin est de faire la pute…

        Description un peu crue mais tellement réaliste, informaticien c'est accepter de travailler beaucoup, d'être mal payé, d'être stressé en permanence et de bosser pour des gros cons qui ne comprennent rien ;)
    • [^] # Re: Aux conquérants de l’inutile!

      Posté par  . Évalué à 4.

      je plains les informaticiens qui n'exercent leur art que professionnellement et sur des spécifications prémachées


      oui, entre la maison les loisirs et d'autres types de postes (R&D, etc) il y a de quoi faire
    • [^] # Re: Aux conquérants de l’inutile!

      Posté par  . Évalué à 4.

      Je trouve d’autre part que cette tendance lourde chez les étudiants informaticiens de se passionner pour tel ou tel nouveau langage d’ailleurs plutôt infantile et pas forcément utile pour leur avenir professionnel.

      Fort heureusement tout le monde ne se destine pas à l'industrie. D'autres embrassent pleinement cette citation du SICP, "It's extraordinarily important that we in computer science keep fun in computing."
  • # Langage

    Posté par  . Évalué à -10.

    Quelques langages suffisent.

    Avec le C++ ou java, on peut déjà tout faire on peut meme faire une intelligence artificielle :)

    Si ca ce n'est pas le but de l'informatique, l'informatique qui est le dernier métier, métier qui va aussi disparaitre

    Et si vous faisiez plutot de l'intelligence artificielle ? Pour créer vos programmes tout seul, avec une interface "humanoide" ou virtuel pour le client : et une grosse temporisation car "il faut pas aller trop vite avec le client" sinon il croirait qu'il a payé pour rien.

    NON , ca ne vous dis pas ?

    Non ?

    Bon alors je vous conseille de vous mettre à réfléchir a propos de l'économie, et aussi du rapport capital / travail : le salaire quand il n'y a pas besoin d'émployé : et qu'il n'y a pas de revenu, ou d'allocation universelle.

    Bonne réflexion :)
    • [^] # Re: Langage

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

      42
    • [^] # Re: Langage

      Posté par  . Évalué à -9.

      Joyeux noël, et bonne année a tout ceux qui refusent de regarder la réalité en face

      La réalité ne tardera pas à vous toucher
  • # Je rêve d'un langage de script

    Posté par  . Évalué à 1.

    Qui respecte les contraintes suivante:
    - Langage objet
    - Typage fort (dans le sens, toutes les variables doivent être déclaré et être au moins du type Objet universel tel que l'Object de Java).
    - Jamais de déclaration implicite genre:
    bidule = 10;
    - Supporte l'introspection d'objet.
    - Gestion de package géré au niveau de la vm avec contrôle au chargement de la signature: un truc du genre:
    import log.jar, 1.2 , http://log.jar/download, {Signature SHA256}
    - Garbage collector
    - Machine virtuel avec contrôle d'accès aux ressources systèmes qui permet un contrôle via bac à sable.
    - Syntaxe type C++ ou Java

    Bref , Java sans Oracle ou Microsoft :)
  • # Approfondir aussi

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

    C'est indéniablement enrichissant d'étudier différents langages de programmation et de s'interroger sur la raison des choix de conception faits par les créateurs de ces langages.

    Mais ce qui peut tout aussi être enrichissant c'est d'approfondir un vieux langage que l'on croit connaître.

    Par exemple prenez un vieux langage comme Python, vous savez qu'il est le fruit d'un travail de recherche. Et, à priori, ses concepteurs sont des personnes respectables.

    Dès lors il est intéressant de s'interroger sur les choix qu'ont faits ces personnes.

    Exemple : pourquoi imposer l'indentation du code dans la syntaxe du langage ? Vous savez que de toutes façons dans un cadre professionnel on vous demandera d'appliquer des règles de codage, parmis lesquelles il y en aura forcément une qui traitera d'indentation.

    Alors pourquoi ce choix d'indentation ? N'est-ce pas pour faire en sorte que votre code soit le plus lisible par le plus grand nombre ?

    Ce que vous voyez comme une contrainte à votre encontre s'avère être en sorte une aide pour que d'autres puissent facilement relire votre travail et apprendre en s'affranchissant des questions de tabulations, d'éditeur...

    De même, le C, les pointeurs de fonctions, sizeof truc, etc.

    Bonnes fêtes de fins d'année !
    Fred
    • [^] # Re: Approfondir aussi

      Posté par  . Évalué à 3.

      > pourquoi imposer l'indentation du code dans la syntaxe du langage ?

      Un lien sur ce sujet: un enseignant a experimenté avec le même langage avec ou sans indentation significative et il a trouvé que ses étudiants apprenaient mieux avec l'indentation significative.
      Interessant je trouve: pour une fois que quelqu'un a une approche 'scientifique' des langages:
      http://lambda-the-ultimate.org/node/2695


      Une remarque cependant: >> à priori, ses concepteurs sont des personnes respectables <<
      La respectabilité des concepteurs n'implique pas malheureusement qu'il ne sont pas capables de faires des *grosses* erreurs dans leurs langages..
      J'ai énormément de respect pour Dennis Ritchie, il n'empèche que je considère qu'il a fait (au moins) deux grosses erreurs sur le C:
      - variables non initialisée par défaut plutôt qu'en option: où comment créer une source majeur de bug et de problème de sécurité pour un faux gain de performance (*)
      - syntaxe différente entre la déclaration de variable et l'utilisation,
      comment compliquer la lecture de programme sans gain particulier.

      *: puisque si les tests montrent que l'initialisation des variables prend trop de temps, alors on pourrait les annoter pour les déclarer non-initialisée.
  • # D a la place de Go

    Posté par  . Évalué à 3.

    Personnellement j'aurais mis D comme 'langage systeme' a la place de Go: il est développé depuis plus longtemps et me parait mieux armé comme alternative au C++.
    • [^] # Re: D a la place de Go

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

      D est un très bon langage, mais ça fait 10 ans qu'il existe et on a toujours l'impression qu'il est en version beta...

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Mainstream || hype || marginal

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

    Je crois que c'est la principal question à se poser : pour quel usage le langage d'apprentissage doit-il être choisi ?

    À mon avis, je pense qu'il faut d'abord faire le point sur soit-même. Savoir où on en est dans les langages qu'on connais, quels sont les paradigmes qu'on y applique et lesquels on ignore totalement.
    Par exemple, le C++ a de nombreux paradigmes, et de nombreuses techniques sont liées à ces approches. Elles permettent d'emprunter plusieurs voies pour appréhender et résoudre un même problème. Mais telle ou telle approche sera plus apparente dans un autre langage. Par exemple, la programmation fonctionnelle en Javascript m'a permis de comprendre et de maîtriser le contenu des en-têtes algorithm et functional. Python me permet d'avoir une approche plus directe et d'explorer la programmation orientée objet sans devoir souffrir du typage statique. Même si en Python, l'absence d'encapsulation (ce qui me pousse à considérer Python comme un langage absolument pas orienté objet) et le passage par référence par défaut (sauf exception) est parfois surprenant.

    PHP m'a permis de manger quelques temps. C'est le premier langage dans une optique professionnelle que j'ai assimilé. C'est là encore un autre but dans l'apprentissage du langage : quel est la technologie qui me permettra de bien manger (parce que bon, du boulot pour les développeurs, il y en a beaucoup).

    Un troisième objectif peut être la découverte absolue. Apprendre un nouveau langage dont on sait déjà ce qu'on va y trouver n'est pas forcément très intéressant. Le conseil du livre cité est agrémenté d'arguments et de raisons pour lesquelles il faut apprendre de nouveaux langages, mais pas seulement. L'auteur conseil aussi de s'intéresser à d'autres champs de connaissances. C'est ainsi qu'on produit des réponses originales, inédites, à des problèmes qui n'ont reçu que des réponses insatisfaisante.

    Pour l'année à venir, je pense continuer à apprendre C++0x et Python 3. Mais aussi solidifier mon expérience en Javascript. Car comme c'est parti, 2011 sera l'année du Javascript (HTML5, Node.JS, MongoDB, CouchDB, etc).

    On en a pas parlé, mais les langages de traitement de flux texte (awk, XSL) et de grammaire (bison, EBNF) sont autant de langages délaissés parce qu'on en voit pas l'utilité intrinsèque. Jusqu'à ce qu'on en ai besoin.

    Et pourquoi pas un peu d'assembleur ? :D
    • [^] # Re: Mainstream || hype || marginal

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

      >> Je crois que c'est la principal question à se poser : pour quel usage le langage d'apprentissage doit-il être choisi ?

      Question inutile.
      Tu prends Scheme/Common Lisp, c'est fait pour tous les usages :)
      T'as du fonctionnel, de l'impératif, de l'objet, du concurrent (à la Erlang, avec Termite/Gambit-C), etc.
      Ça marche pour les calculs matheux (maxima), pour le jeu vidéo (abuse, farmageddon (sur iphone !)), pour comparer les prix les moins chers de vols en avion (itasoftware), pour animer la tête de Gollum dans Le seigneur des anneaux (Mirai), pour faire des serveurs webs ultra rapides (teeteepeedee), des WM (stump), etc.
  • # Lilypond

    Posté par  . Évalué à 2.

    Moi, j'ai choisi.
    Mon langage de programmation est musicale : lilypond.
    Guillaume
  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: 3 type de langage a connaitre:

      Posté par  . Évalué à 3.


      En fait il te manque un langage fonctionnel (Haskell, OCaml) et un Lisp (que je ne sais pas trop comment définir méta-
      • [^] # Re: 3 type de langage a connaitre:

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

        Il en manque bien plus !
        Ne serait-ce que prolog (puis langage synchrone, comme dit dans mon message plus bas).

        Lisp, c'est pas tant la peine si c'est juste pour apprendre les concepts et qu'il a déjà l'objet, l'impératif et le fonctionnel en poche.
    • [^] # Re: 3 type de langage a connaitre:

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

      Il te manque un langage fonctionnel dans ta liste.

      Le jour ou tu découvre comment fonctionne un map ou un grep (en perl); tu découvres un moyen de résoudre des problèmes de façon utlra concise. Passer des fonctions en paramètres changent beaucoup de choses.

      Tu as aussi les contrats (assert() en C et Java, les bloc [] en smarteffel ou en lisaac, qui s'hérite). Ils te permettent de poser tes conditions sur les entrées/sortie de ton code, cela évite de faire trop de programmation défensive, qui finit par couter et facilite de beaucoup les tests en proposant une série "d'Oracle" qui te donne un vrai ou faux dans un test.

      Lisaac apporte un plus par rapport à Java c'est de pouvoir faire plein de petit objet, plein de niveau d'héritage, sans perte de performance.

      "La première sécurité est la liberté"

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: 3 type de langage a connaitre:

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

          Et ben en C tu passes un pointeur de fonction. Dans les vrais langages de programmation tu passes une fonction.

          (define (compose f g) (lambda (x) (f (g x))))

          La construction Scheme ci-dessus retourne une fonction appelée "compose". Cette fonction prend deux arguments f et g qui sont eux même des fonctions et retourne une fonction qui est la composée (composition ?) f(g()).

          Pour faire ce genre de chose en C, tu vas t'amuser.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: 3 type de langage a connaitre:

            Posté par  . Évalué à 3.

            Tu déclare une fonction g, puis une fonction f et enfin t'a fonction compose qui appelle f en donnant en parametre g. Oui la syntaxe est plus lourde mais c'est pas non plus du complexe.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: 3 type de langage a connaitre:

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

              Dans ce cas, ta fonction compose() est la composée de f(g()) et elle retourne le résultat, pas une nouvelle fonction.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: 3 type de langage a connaitre:

              Posté par  . Évalué à 2.

              Non, tu n'as pas compris. Dans un langage fonctionnel, je peux générer autant de composées que je veux (par exemple), de façon arbitraire et dynamique. Ça ne me semble pas possible en C (en tout cas ça fait deux fois que je dis que j'aimerais bien qu'on me prouve le contraire).

              Pense à l'itérée d'une fonction par exemple.
              • [^] # Re: 3 type de langage a connaitre:

                Posté par  . Évalué à 2.

                Je vois (même si je ne vois pas les cas d'usage). Je ne sais pas ce qu'est l'« itérée d'une fonction ».

                Le problème au C pour faire ça en plus du fait qu'il n'est pas fonctionel c'est son typage static et pas de réflexivité, sinon dans l'absolue tout est possible avec le fameux void *.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: 3 type de langage a connaitre:

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

                  En Haskell, tu as du typage statique et tu peux faire ça. Pour l'usage, les gens qui ne connaissent pas les pointeurs comprennent pas l'intérêt non plus au début :)

                  J'ai pas dit que c'était pas possible en C. Mais c'est bien plus compliqué et donc en pratiquer tu vas programmer autrement.

                  Je ne suis pas sûr de voir ce qu'est que « l'itérée d'une fonction » non plus.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: 3 type de langage a connaitre:

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

                Je me demande si les fonctions trampolines ne permettent pas de faire ça : http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
                • [^] # Re: 3 type de langage a connaitre:

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

                  Oui mais c'est plus du C standard alors. C'est une extension GNU. De plus, tu dois toujours connaître le type de tes fonctions à l'avance tandis qu'en Scheme/Lisp/Haskell/OCaml tu dois juste connaître leur arité (combien d'arguments elles prennent ; et encore, il y a peut-être moyen de contourner à coup de currying ou autre subtilité) :
                  int (*compose(int (*f)(int), int (*g)(int)))(int)
                  {
                          int composed(int x)
                          {
                                  return f(g(x));
                          }
                          return &composed;
                  }
                  Si tu connais des gens qui écrivent du C comme ça, je demande à voir quand même.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: 3 type de langage a connaitre:

                    Posté par  . Évalué à 2.

                    Avec un compilateur Objective-C 2.0 (pas encore dans GCC il me semble, mais ça devrait marcher avec clang)


                    (int(^)(int)) compose((int(^)(int)) f, (int(^)(int)) g) {
                    return ^(int x){ return f(g(x)); }
                    }


                    Et oui, c’est utilisé en pratique, notamment chez Apple (forcément) dans libdispatch par exemple.
                    • [^] # Re: 3 type de langage a connaitre:

                      Posté par  . Évalué à 2.

                      Tu dois connaître les arguments, sauf à utiliser un void ** avec comme dernier élément NULL. Mais je ne sais même pas si c'est valide en Objective-C.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: 3 type de langage a connaitre:

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

          C'est tellement chiant que tu ne le fais pas.

          @selection = map {$_ if ($_> 10)} @array;

          "La première sécurité est la liberté"

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: 3 type de langage a connaitre:

      Posté par  . Évalué à 6.

      En fait tu devrais plutôt t'intéresser à la physique quantique. Après tout, un atome est un atome, un électron est un électron, un trou est un trou. De l'électronique (au sens composants, ...), ce n'est jamais qu'une abstraction de plus ou moins haut niveau. Mais une fois que l'on a compris comment la physique quantique marche, le reste n'est que de l'application sans intérêt particulier.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: 3 type de langage a connaitre:

      Posté par  . Évalué à 1.

      Aucun langage ne fait plus que ce que fait électronique, ils font de l'abstraction plus ou moins de haut niveau.

      Il est certes très utile de comprendre comment fonctionnent les entrailles de la machine, mais l'abstraction a pour but précisément de se détacher du fonctionnement concret de l'ordinateur, et d'offrir un moyen plus élaboré d'aborder les problèmes et d'exprimer plus élégamment leur solution.

      L'ordinateur étant une machine à automatiser, autant automatisé ce qui peut l'être également en programmation.

      Un nouveau langage pourquoi faire ? Une boucle est une boucle, un test un test etc.

      Il y a des langages sans boucle! Alors évidement, il sera toujours exécuté par les mêmes instructions fondamentales du processeur. Mais l'expressivité n'est vraiment pas à négliger.

      Ça m'a fait directement penser à l'expérience d'Ontologia: https://linuxfr.org/comments/1138809.html#1138809

      Pour ma part, l'apprentissage de différents langages de programmation m'a énormément ouvert d'horizons quant à la manière d'affronter un problème.
      Le langage qui a le plus marqué mon esprit est Haskell, et les concepts de programmation fonctionnel en général. Et quand j'utilise un langage de haut-niveau qui n'offre pas cette expressivité, je me sens très frustré. Et Java est probablement un des langages qui m'est le plus pénible tellement il est inexpressif et rigide, sans offrir de réelle contre-partie qualitative.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: 3 type de langage a connaitre:

          Posté par  . Évalué à 2.

          La raison pour laquelle il est important d'avoir des langages avec des paradigmes différent, c'est qu'avec les paradigmes impératifs, on est tout sauf sûrs d'arriver à continuer à profiter de la loi de Moore. En effet, la fréquence des processeurs n'augmente plus, seul le nombre de coeurs augmente désormais. D'où la nécessité décrire des programmes concurrents ou distribués. Sauf que les langages tels que Java ne proposent que les verrous comme seuls moyens de faire de la programmation concurrente, et ceux-ci ne passent pas vraiment à l'échelle.

          À l'opposé, des langages aux paradigmes différents proposent des modèles de parallélisme bien plus évolués : Scala et ses agents, Haskell a une STM, Erlang est conçu pour le message passing, etc.

          Avec une différence fondamentale entre la programmation "classique" et la programmation parallèle : si avant on bénéficiait du modèle de Turing pour nous dire que de toute façon, on savait que tout était faisable, là c'est tout sauf le cas, on ne sait toujours pas (à ma connaissance) s'il est possible d'avoir la même classe de calculabilité en distribué qu'avec un seul process. D'où le fait qu'aller chercher des paradigmes différent pourrait aider à mieux appréhender ce problème.

          Pour résumer mon post long et plutôt mal structuré en une phrase : on peut continuer à coder en impératif, mais alors il faudra peut-être dire adieu au doublement de la puissance de calcul tous les 18 mois.
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

  • # Synchrones

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

    Je vois que personne n'a cité de langages synchrones comme Lustre ou Esterel.
    Ça aussi, c'est fun !

    (Ni intercal ou unlambda, mais c'est une autre histoire…)
  • # C'est dans les vieux pots qu'on fait les meilleurs bugs

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

    Pourquoi ne pas explorer de vieux langages qui ont potentiellement évolués?

    Object Pascal, Ada et Eiffel, par exemple, méritent certainement un peu d'attention.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.