Journal Go : Un nouveau langage chez Google

Posté par (page perso) .
Tags :
24
11
nov.
2009
Le langage Go (sous licence BSD) est issu d'une discussion entre Ken Thompson (un des auteurs d'Unix et d'UTF8) et Rob Pike (un des auteurs de Plan9 et d'UTF8). Nous avons donc affaire a de vrais barbus, des légendes de la communauté des codeurs ce qui explique la curiosité qui entoure ce projet de nouveau langage.
Comme Rob Pike travaille chez Google c'est donc avec le puissant soutien de son employeur que le langage Go a été développé avec les contraintes suivantes :

- Go doit pouvoir être utilisé pour de la programmation système donc c'est un langage compilé et pas interprété.
- La compilation doit être très rapide pour faciliter le développement des projets (l'analyse des dépendances permet une compilation en quelques secondes).
- La syntaxe doit être assez proche du C tout en corrigeant ses défauts les plus criants.
- La gestion de la mémoire doit être automatique (garbage collector)
- Le typage doit être statique mais il n'y a pas de hiérarchie des types pour simplifier le langage.
- La programmation concurrente (pour exploiter les multicores) doit être intégrée au coeur du langage. Cela se fait par l'intermédiaire des "goroutines" qui sont plus légères que les threads.

Go est le résultat de la très longue expérience de Thompson et Pike et la auteurs semblent assez fiers de leur rejeton :

"Go has fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection. It feels like a dynamic language but has the speed and safety of a static language. It's a joy to use. "

La FAQ du projet évoque les questions générales et une FAQ spécifique est dédiée au langage lui-même. Un tutorial est aussi disponible avec, pour mettre en évidence le support d'UTF8, un assez inhabituel "Hello, world; or Καλημέρα κόσμε; or こんにちは 世界".

Pour l'instant les remarques sur le web se concentrent sur des points de détail: la syntaxe qui ne plaît pas à tous le monde, l'absence de telle ou telle fonction (comme les exceptions), etc.
Il faut attendre un peu pour que la poussière retombe et pour avoir des analyses qui se concentrent sur les apports spécifiques du langage: les goroutines, la segmentation de la pile d'exécution, la compilation rapide, etc.
Il sera également intéressant de lire des comparaisons détaillées avec les autres langages qui veulent s'attaquer au C en apportant des innovations techniques (comme par exemple le langage D).

L'annonce de Go sur LWN avec pas mal de commentaires intéressants.
Un article consacré à Go sur Astechnica.
Heise Online parle aussi de Go.
Enfin Wikipedia version anglaise et version française ont déjà des pages sur Go.
  • # Ah! C'est la saison de la galinette cendrée!

    Posté par . Évalué à 1.

    Toujours à l'affût, notre Patrick_g!

    Merci pour ce journal intéressant. Je ne suis pas dev, mais ça fait plaisir de voir que ça bouge toujours de ce côté. Et ce d'autant plus si ce sont de bon vieux barbus qui se remettent au taf.
    Il ne manquerait plus qu'un ado suédois nous ponde un Hurd OS avec ce nouveau langage.
    • [^] # Re: Ah! C'est la saison de la galinette cendrée!

      Posté par . Évalué à 1.

      Pourquoi suédois ?!
      • [^] # Re: Ah! C'est la saison de la galinette cendrée!

        Posté par . Évalué à 2.

        Linus Torvalds est Finlandais, mais suédophone (sa langue maternelle est le suédois), d'où la petite blague...

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Ah! C'est la saison de la galinette cendrée!

      Posté par . Évalué à 1.

      Ça risque d'être controversé, vu qu'en général on essaie d'éviter les garbage collector dans les kernels.

      Go est un langage système, pas un langage pour kernel.

      Sinon j'aime bien les 4 premiers commits du repo hg:
      http://code.google.com/p/go/source/list?r=1bc84c9f0f221196b4(...)

      Finalement je ne sais pas si Go est un "vrai" projet Google, ou bien un projet sur les 20% de temps libre (ça permet de mesurer le soit-disant soutien de Google au projet).
      • [^] # Re: Ah! C'est la saison de la galinette cendrée!

        Posté par . Évalué à 5.

        Pour le gc, je n'en sais rien, mais les temps changent, dans la FAQ ils disent que les gc ont fait d'énormes progrès ces derniers temps par exemple. Et que pour la concurence, c'est un gros plus que ce soit le gestionnaire de mémoire qui se charge de tout ça une fois pour toute plutôt que chaque programmeur en permanence. Donc un gc dans un noyau, pourquoi pas, à terme ... (pour l'instant ils disent que leur implémentation gc est classique et pas du tout état de l'art)


        Sinon apparemment Go c'est un langage généraliste, qui se débarasse de ce que j'ai vu de toutes les vieilleries bas niveau obsolètes du C qui servent plus à rien du genre l'arithmétique des pointeurs.

        C'est un vrai projet 100 % qui a démarré comme un projet de temps libre. Ça te rend un peu médisant sur le "soit disant" soutient, rien que le fait de financer des gens pour qu'ils fassent ce qu'ils veulent 20% du temps c'est un soutiens de google en soi ...
        • [^] # Re: Ah! C'est la saison de la galinette cendrée!

          Posté par . Évalué à 4.

          Soi-disant c'était pas négatif (je me demande comment on dit du coup, "so called" ou "sogenannte" c'est pas négatif, y a t'il un équivalent en français ?)... Il faut aussi dire que l'absence de tout logo ou texte Google sur http://golang.org/ est troublante.

          Pour le gc c'est surtout que les kerneleux n'aiment pas faire tourner un runtime du langage dans le kernel (surtout que un général il faut le réimplementer vu que le runtime d'espace utilisateur n'est pas utilisable directement).

          Pour les vieilleries, il faudrait implementer une stack TCP/IP avec pour vraiment savoir si on en a toujours besoin ou pas :)

          Finalement ils ont un compilo super rapide, mais qui n'implémente pas beaucoup d'optimisations. Quand ils disent 20% plus lent que du C, c'est a priori avec gccgo qui doit être beaucoup plus lent... du coup c'est un peu dommage d'avoir fait Yet Another Compiler plutôt que de targeter llvm (surtout que les blocs type Grand Central Dispatch doivent être un peu proche des goroutines).
          • [^] # Re: Ah! C'est la saison de la galinette cendrée!

            Posté par . Évalué à 2.

            Juste pour le soi-disant. Dans le contexte, je dirais sus-nommé ou sus-mentionné. car effectivement, sois disant sonne connoté.

            Pour le reste, je n'ai pas les compétences...
            • [^] # Re: Ah! C'est la saison de la galinette cendrée!

              Posté par . Évalué à 3.

              D’abord, « soi-disant » ne devrait pouvoir être utilisé que pour les personnes (celles qui ont un « soi » qui puisse « dire »). « Prétendu » serait l’adjectif à utiliser dans la plupart des cas.

              Ici, le soutien n’a pas été mentionné avant, donc « sus- » n’est pas le bon choix.
              De plus, il s’agit bien de porter un doute, une réserve, sur le soutien effectif ou officiel de Google (savoir si c’est du 20% ou un projet officiel).
              Enfin, « so-called » (littéralement : ainsi-nommé) est tout aussi péjoratif que « prétendu » (ou « soi-disant »).
          • [^] # Re: Ah! C'est la saison de la galinette cendrée!

            Posté par (page perso) . Évalué à 2.

            >> Pour les vieilleries, il faudrait implementer une stack TCP/IP avec pour vraiment savoir si on en a toujours besoin ou pas :)

            La pile TCP/IP, faut s'en séparer…
            Elle a fait son temps et n'est plus adaptée (API de merde, limitée aux connexions fixes… La recherche a continué depuis la préhistoire !)
            • [^] # Re: Ah! C'est la saison de la galinette cendrée!

              Posté par . Évalué à 6.

              tu parle de l'api ou de TCP/IP ?

              Comment veux-tu passer à autre chose que IP sachant que IP V6 n'arrive même pas à s'imposer ?

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

              • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                Posté par (page perso) . Évalué à 3.

                >> Comment veux-tu passer à autre chose que IP sachant que IP V6 n'arrive même pas à s'imposer ?

                Et aussi "Pourquoi voulait-on des DVD alors que le LaserDisc n'arrivait même pas à s'imposer". IPV6 est une solution au NAT, mais pas la solution à tous les problèmes…

                Ensuite, je parle de l'API et de TCP/IP, les deux mon général !

                Pour l'API, j'ai été convaincu en essayant moi même il y a longtemps, et j'ai été conforté dans mon opinion par http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/f(...) (si ton labo n'y est pas abonné, demande leur de le faire. C'est très bien comme magazine !)

                Pour TCP/IP en soit, je te renvois sur Mobile IP par exemple (mais il existe d'autres solutions encore) : http://www.tcpipguide.com/free/t_MobileIPOverviewHistoryandM(...) et http://www.acm.org/crossroads/xrds7-2/mobileip.html

                Tu vois, qu'un GC ralentisse mon kernel, je m'en tape complètement, comparé à toutes les pertes qu'on subit à ne pas implanter dès il y a 10 ans des technologies développées pour la mobilité et la distribution. Je pense que de simples statistiques sur le nombre de possesseurs de terminaux mobiles reliés à internet suffit à justifier le changement sans réfléchir plus que ça.
      • [^] # Re: Ah! C'est la saison de la galinette cendrée!

        Posté par (page perso) . Évalué à 4.

        >> Ça risque d'être controversé, vu qu'en général on essaie d'éviter les garbage collector dans les kernels.

        On évite les GC dans les kernels *écrits dans des langages où on a collé un GC sans réflechir aux applications*.

        Un GC, c'est pas un .so que tu lies, et hop c'est fini !
        Un GC, ça s'optimise, ça se configure aux petits oignons tant en même temps qu'on crée le langage (son compilateur ou son interprète) et aussi en même temps qu'on développe son application.
        Alors, certes, ça fait pas plaisir aux gens qui ne jurent que par un seul langage, mais on ne construit pas toutes les voitures avec une seule et unique clef à pipe…

        On citait les machines Lisp plus bas, mais il me semble aussi que Lisaac possède un GC et qu'il a servi à prototyper un OS potable…
        Ontologia, si tu nous lis, ton avis sur ce journal m'intéresse beaucoup !
        • [^] # Re: Ah! C'est la saison de la galinette cendrée!

          Posté par . Évalué à 2.

          Je dirais que cela ressemble beaucoup à Lisaac. Les buts sont très proches.

          Je pense simplement que Lisaac va plus loin dans certain cas (comme la gestion du parralèlisme).

          Lisaac est aussi particulier parce que tout est en lib. Le GC aussi. Ce qui permet de "tuner" si besoin.

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

        • [^] # Re: Ah! C'est la saison de la galinette cendrée!

          Posté par (page perso) . Évalué à 9.

          C'est gentil ça, ça me touche beaucoup :-)
          Nicolas a en grande partie répondu à ta question.

          Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.
          Benoit répète souvent "pas d'allocation à l'insu du programmeur", chose dont je comprend qu'il y a surement un intéret, mais dont je me fiche un peu et qui m'oblige à réfréner mes ardeurs à vouloir implémenter des features très haut niveau dans le langage ;-)

          Donc comme disait Nicolas, tu peux faire ce que tu veux avec le GC, et je suis bien d'accord que ça dépend de la situation. Vu la cible de Lisaac (Embarqué, système), il risque de pas servir si souvent que ça....

          Alors je répond à ta question, parce que c'est gentillement demandé et que ça a commencé à flipper sur la ML Lisaac.
          De ce que j'ai compris de ce langage, particulièrement à lire http://golang.org/doc/go_for_cpp_programmers.html qui est vraiment instructif :
          - Le système "objet" est marrant, original, mais j'imagine un peu limité.
          En gros ça consiste à déclarer que des interfaces (ie des objets avec que des méthodes vides), et de dire qu'un truc est du type de cet objet si tu écrit une (ou plutot les) méthode qui appartient(nnent) à l'interface. Bon.. Je sens que ce genre d'approche c'est limité, et même limité ça peut péter au runtime.
          Enfin on verra.
          - Pas d'assertions ni d'exeptions. Bonjour le debug
          - Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...
          - Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
          - Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
          - Concurrence : correspond bien à l'état de l'art. Ca sera déterminant pour aider le langage à progresser.


          Mais je pense que ce langage va marcher, car il rempli bien les condition définies par Richard P. Gabriel ( Models of Software Acceptance ) http://www.dreamsongs.com/Files/AcceptanceModels.pdf (relire cette présentation, c'est fabuleux !!) :
          - Langage accessible sans nécessiter trop d'abstractions
          - Gurus derrière
          - Grosse boite derrière (pas de gambler ruin possible)
          - Langage ressemblant à l'existant
          - Langage au design relativement simple, cohérent et suffisant pour sa cible.

          Plus généralement, c'est un langage construit à base de techno disponible dans l'industrie, donc un peu dépassée par ce qui se fait dans la recherche. C'est une approche pragmatique, mais qui a pas mal de limites.

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

          • [^] # Re: Ah! C'est la saison de la galinette cendrée!

            Posté par (page perso) . Évalué à 7.

            - Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...

            Ce serait pas le cas du C qui reste à ce niveau là un des meilleurs langage ? Et le cas du C++ aussi ?

            De plus la compilation séparée n'est pas un élément du langage mais principalement du compilateur. C'est celui-ci qui choisit de considérer chaque module indépendament ou comme un tout.

            - Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )

            J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
            En voyant ton exemple je me pause les question suivante :
            - est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
            - est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
            - entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?

            - Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?

            On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
            • [^] # Re: Ah! C'est la saison de la galinette cendrée!

              Posté par (page perso) . Évalué à 3.

              Je trouve que la solution des pointeurs du Fortran sont une bonne solution. On ne les déférence jamais, on n'accède jamais à l'adresse et donc pour les affecter, on utilise un autre opérateur que le = (ou le :=), mais dans ce cas là, le =>.

              Au final, je trouve que cela fait un code bien plus simple que du code C (ou Ada) pour finalement avoir ce que l'on veut.

              Sinon, pour les opérateurs, Fortran a aussi une bonne chose avec les opérateurs de la forme .machin. car cela permet d'avoir autant d'opérateur que l'on veux et pas que des signes cabalistiques dont on ne connaît plus la définition ensuite. Par exemple, il est assez facile de faire un opérateur .scalar. qui prend deux objets et retourne toujours un réel (produit scalaire) alors qu'avec l'opérateur *, on ne sais jamais de quel multiplication on parle...

              Bref, les opérateurs du Fortran permettent d'écrire des formules en infixés comme souvent en math et donc que la formule dans le code soit le plus proche possible de la formule de la définition.

              Cela est parfait dans le cadre du calcul numérique, ce qui n'est pas forcément le cas aujourd'hui de la majorité des codes que l'on manipule. Mais limiter les opérateurs aux seuls symboles est je trouve dommage.
            • [^] # Re: Ah! C'est la saison de la galinette cendrée!

              Posté par (page perso) . Évalué à 4.


              J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
              En voyant ton exemple je me pause les question suivante :
              - est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
              - est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
              - entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?

              On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.

              45_020_089/8! fait environ 1116,56 donc il affichera ce résultat (print).
              La division reste une division, la factoriel une factorielle.
              Et on peut très bien implémenter factoriel dans la lib des réels (4 lignes de code) en prenant la valeur entière.

              - Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?

              On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.


              Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
              D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
              Parce que le programmeur moyen a un niveau assez bas.

              Faut faire des langages qui s'adaptent aux gens, pas l'inverse.

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

              • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                Posté par (page perso) . Évalué à 5.

                On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.

                L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
                Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.

                Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...

                Pour récapituler : les pointeurs sont un outils très puissant dans les mains des bon programmeurs mais une grosse bombe à retardement dans les main des mauvais programmeurs.
                Le problème est que l'on à peu près que des mauvais programmeurs. Donc on oubli les pointeurs, on va pas prendre de risque.

                Pour tout dire, tu prend le paragraphe précédent et tu remplace pointeur par surcharge d'opérateurs et le texte reste parfaitement vrai.
                Tu prend du C++ pondu en SSII et tu regardes à quoi sert la surcharge d'opérateur. Le plus souvent tu te retrouve avoir des objets qui s'additionne ou ce multiplie de manière complètement illogique et le code deviens incompréhensible et tout aussi dangereux qu'avec des pointeurs.

                D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
                Parce que le programmeur moyen a un niveau assez bas.

                Faut faire des langages qui s'adaptent aux gens, pas l'inverse.


                Le problème c'est que lorsque le niveau est si bas, il ne faut pas un langage permissif mais au contraire un langage extrêmement strict et très redondant afin que le compilateur puisse détecter le maximum d'erreurs et afficher des messages les plus clairs possible.

                C'est pour cela que le PHP est une bouse infâme : il a une syntaxe qui lui permet de ne se préoccuper des erreur que le plus tard possible : en général quand il est trop tard. Ajoute à cela le fait qu'il est principalement utiliser sur des machine connectée au net et tu peut en déduire ce que je pense de ce langage.
                • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                  Posté par (page perso) . Évalué à 2.


                  L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
                  Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.

                  Quand tu écris la formule sur une feuille, tu écris bien
                  45020089
                  -------------
                        8!

                  Non ?
                  Le but est de pouvoir l'écrire au plus proche de cela.

                  Pour le reste, je suis d'accord avec toi ! Pas réfléchi ça peut vite devenir catastrophique, mais d'ici là qu'on ait au moins 100 personnes dans le monde qui codent régulièrement en Lisaac, on aura j'espère eu le temps d'écrire une bonne lib de maths qui fassent des opérations usuelles avec une syntaxe sympa et des priorités d'opérateurs réfléchis.

                  Autant les pointeurs, on peut, à mon avis, s'en passer, autant la surcharge des opérateurs est un réel plus, pour faire des libs sympa, réfléchies.
                  Mais bon, on verra...

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

                  • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                    Posté par (page perso) . Évalué à 1.

                    Les pointeurs posent problème au compilateur et l'empêche d'optimiser plein de trucs. Vu que le programmeur peut virtuellement faire n'importe quoi.
                  • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                    Posté par (page perso) . Évalué à 2.

                    Quand tu écris la formule sur une feuille, tu écris bien
                    45020089
                    -------------
                    8!


                    tu peut aussi écrire :
                    45020089
                    --------------- !
                    8
                    Quand tu écrit la division sous cette forme, ça revient à mettre des parenthèses. Dans ton code par contre l'ambiguïté demeure.

                    Et que ce soit programmé par des gens avec de bonnes intentions et le faisant de manière très logique ne change rien au problème. Avoir le même opérateur avec une priorité différente et une sémantique différentes suivant le type rend le programme beaucoup plus difficile à lire.

                    Si tu surcharge les opérateurs pour un type vecteurs par exemple, il devient naturel de ce demander si le '*' correspond au produit par composantes, au produit vectoriel au produit scalaire. Tu trouvera toujours des gens plein de bonnes intentions qui trouverons des raison parfaitement valable de choisir l'un plutôt que l'autre.
                    Le gros problème c'est que quand tu te retrouve face à leur code, tu te demandera toujours si le mec qui à codé la lib à la même logique que toi.

                    C'est, pour moi, un des plus gros points noir du C++. Combien de fois je me suis retrouver devant un code ou un mec à cru malin de redéfinir les opérateur pour rendre son code plus concis par la suite et en théorie plus clair... la plupart du temps tout ce que l'on obtient c'est un code extrêmement difficile à débugger car une expression qui semble évidente fait quelque chose auquel on aurait même pas penser dans nos pire cauchemars.

                    Donc, la surcharge d'opérateur est pour moi quelque chose d'encore plus dangereux que les pointeurs car ses effets pervers peuvent être quasiment invisibles, là ou un pointeur est bien visible. Quand je vois un pointeur, je sais que je dois faire particulièrement attention, pour les opérateur, il est dur de dire s'il y a danger ou pas.
                    • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                      Posté par (page perso) . Évalué à 3.

                      D'ou le fait de pouvoir définir en Fortran ses propres opérateur comme .scalar. qui ne porte pas à confusion car effectivement, la surcharge de l'opérateur * est souvent un enfer pour les relecteurs.

                      Ensuite, une formule de Math doit avoir des paranthèses dès que l'on dépasse quelques opérations car la aussi, l'interprétation ne doit jamais être confuse. Même sur le papier, je met des parenthèses...

                      En calcul numérique, on a trop souvent un code qui tourne mais avec un mauvais résultat. Il faut donc que les formules soit le plus facile à contrôler pour éliminer les bogues le plus facilement possible.
                • [^] # Re: Ah! C'est la saison de la galinette cendrée!

                  Posté par (page perso) . Évalué à 3.

                  L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
                  Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.


                  On ne peux pas en Lisaac mélanger des opérateurs avec des types différents. Le compilateur ne s'en sort plus sinon.
          • [^] # Re: Ah! C'est la saison de la galinette cendrée!

            Posté par (page perso) . Évalué à 2.


            Le GC est désactivable, et pour donner un exemple, il est désactivé dans le code du compilateur, au profit d'une gestion à la main assez rigoureuse. Comme tout est en lib, on peut tout à fait définir le delete de c++.


            Le GC ne marche plus du tout en fait.
        • [^] # Re: Ah! C'est la saison de la galinette cendrée!

          Posté par (page perso) . Évalué à 2.

          Ah, j'oubliais : Le langage Go, le premier, pas celui de google a l'air très très intéressant : http://fr.wikipedia.org/wiki/Go!_%28langage_de_programmation(...)

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

  • # Interrogations...

    Posté par . Évalué à 8.

    Go doit pouvoir être utilisé pour de la programmation système donc c'est un langage compilé et pas interprété.
    La gestion de la mémoire doit être automatique (garbage collector)


    http://fr.wikipedia.org/wiki/Programmation_syst%C3%A8me
    S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ? plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?

    Linus Torvalds disait qu'il ne voulait pas de C++ dans le noyau Linux car il a tendance à cacher la gestion de la mémoire, qui est un élément trop important pour être laissé à de simples algorithmes. En programmation système c'est la même chose en général (gestion fine des ressources, la mémoire en particulier en fait partie).
    En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).

    Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.

    Ça s'apparente donc plutôt une sorte de langage de script compilé, avec une syntaxe proche du C. Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ? (la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ? ) http://golang.org/doc/go_lang_faq.html

    Bref je ne comprends pas trop la position du langage par rapport à ses concurrents, au niveau des performances voulues/atteintes. En revanche les idées derrière l'implémentation de la concurrence sont intéressantes.
    • [^] # Re: Interrogations...

      Posté par . Évalué à 3.

      S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ? plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?

      Parce que c'est l'enfer quand on commence à faire de la programmation parallèle.

      D'autre part, programmation système != programmation kernel, ce n'est pas du tout évident que Go soit adapté pour la programmation kernel. A priori ils s'interessent aux programmes systemes (serveurs, base de données, etc.).

      Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.

      La rapidité de compilation c'est surtout un side effect d'avoir écrit le compilateur from scratch. Ça risque de devenir plus lent avec les optimisations, même si le design du langage permet de conserver une certaine rapidité (surtout dans les couches hautes: la grammaire et la gestion particulière des modules doivent aider).

      la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ?

      C'est très dur (il suffit de voir depuis quand pypy existe), python est un langage trop dynamique pour le compiler/JITter efficacement. Alors que Go possède un système de type entièrement statique (que je trouve assez élégant, c'est une sorte de duck typing statique).
    • [^] # Re: Interrogations...

      Posté par (page perso) . Évalué à 3.

      J'aimerais bien savoir en quoi le C++ cache la gestion de la mémoire ?
      • [^] # Re: Interrogations...

        Posté par (page perso) . Évalué à 6.

        Il ne la cache pas, mais ça peut-être plus difficile de bien comprendre tout ce qui se passe.
        Dans un programme en C, le développeur gère complètement les malloc/free. En C++, le simple fait de fermer une accolade peut avoir pour effet de détruire un objet, qui va en détruire d'autres par ricochets. De simples appellent d'opérateurs sur des objets peuvent provoquer des créations/destructions d'objets.
        Ce n'est en principe pas un problème, mais je comprends que le noyau ne soit pas le meilleur endroit pour ce genre de choses.
        • [^] # Re: Interrogations...

          Posté par (page perso) . Évalué à 10.

          le simple fait de fermer une accolade peut avoir pour effet de détruire un objet

          C'est pour ça que je mets pas ma tasse à café près de l'ordinateur quand je fais du latex.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Interrogations...

      Posté par (page perso) . Évalué à 4.

      >> S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ?

      Quel rapport entre la vitesse et la gestion de la mémoire ?

      >> En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).

      Ben, tu prends un GC temps-réel, et hop.
      Ou alors un GC-hybride…
      Choisir son GC fait aussi partie du développement d'une appli ou du choix d'un langage pour un problème donné…

      >> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?

      Ça dépend du langage. Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique). Inversement, Scheme se compile très bien…

      Après, je te rappelle que les langages de scripts peuvent aussi se compiler, non seulement vers du code machine, mais aussi pour une VM…
      • [^] # Re: Interrogations...

        Posté par . Évalué à 3.

        "Quel rapport entre la vitesse et la gestion de la mémoire ?"

        Si tu as un GC le codeur à tendance à être sale et à créer/détruire plein d'objets, ce qui est couteux. En C, tu as naturellement le réflexe de réutiliser les objets pour des raisons de facilité, or c'est le plus performant.

        >> Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ?

        Si tu regardes le langage shoutout, on peut estimer à un facteur 10 en moyenne la différence de performance entre du C et un script. Parfois, c'est bien pire.

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

      • [^] # Re: Interrogations...

        Posté par . Évalué à 3.

        Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique).

        D'un autre côté une fois qu'on a un interpréteur correct, c'est qu'on a réussi à appréhender la sémantique justement... Et de là à en écrire un compilateur (au moins vers une machine virtuelle), la marche est moins haute.
        D'ailleurs comme tu le dis il existe des compilateurs pour langages de script vers du byte code (une référence se trouve ici, pour python 2.5.2 http://www.python.org/doc/2.5.2/lib/bytecodes.html ). Les opérations d'icelui sont naturelles pour un langage de bas niveau, et ne sont pas "beaucoup" plus haut niveau que de l'assembleur pur. Mis à part un linker il ne manque pas grand-chose au niveau analyse sémantique pour compiler finalement complètement le langage vers du code machine.
    • [^] # Re: Interrogations...

      Posté par . Évalué à 1.

      plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?

      Un GC ne se contente pas de libérer la mémoire, il peut aussi éviter sa fragmentation.

      typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents

      Un bon GC peut être désactivé/réactivé. Tu peux forcer un GC quand ça t'arrange. Et dans le cas des GC générationnels (dont sont dotés les langages que j'utilise) tu peux même spécifier quelle génération collecter. Pour finir un bon GC est souvent configurable.

      Jette un oeil du côté des SBCL ou CCL. Je n'ai jamais eu de longue pause pour le GC avec ceux-ci. J'ai plutôt l'impression que ce préjugés date un peu. Ou alors ce sont les GC de Perl/Python/Ruby (qui ne sont pas très évolués) qui ont engendré cette mauvaise image.
      • [^] # Re: Interrogations...

        Posté par . Évalué à 3.

        Tu as des noms de langage ou d'algo implémenté dans la vrai vie qui tourne avec des pauses très courtes ?

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

        • [^] # Re: Interrogations...

          Posté par . Évalué à 2.

          SuperCollider est un langage avec un GC temps réel http://en.wikipedia.org/wiki/SuperCollider
          IBM a un Java avec un GC temps reel.
        • [^] # Re: Interrogations...

          Posté par . Évalué à 2.

          Comme je l'ai dit juste au-dessus, CCL et SBCL, cesont des implémentations de Common Lisp. Avec un GC générationnel la collecte la plus fréquente ne scanne que les objets de jeune génération, c'est très court. La collecte complète, lançable à la main sur SBCL avec (gc :full t) prend un peu plus de temps, mais c'est rare.

          Sinon comme dit tu peux désactiver le GC pendant les phases plus critiques de ton code. Et il existe d'autres techniques. J'ai lu que chez Orbitz ils mappaient d'énormes fichiers en C++, la partie Lisp les manipulant via des pointeurs (donc un fixnum, le GC ne voyait pas les données). Il y a un message à ce sujet sur google groups, je vais voir si je peux remettre la main dessus.

          Sinon j'ai pas d'exemples de temps réel dur dans un environnement à GC.
        • [^] # Re: Interrogations...

          Posté par . Évalué à 3.

          J'ai retrouvé l'article parlant des techniques utilisées chez Orbitz:
          http://www.paulgraham.com/carl.html

          Sinon en tapant real time garbage collector dans google on trouve beaucoup de trucs intéressants, genre http://lambda-the-ultimate.org/node/2393 (où dans les commentaires quelqu'un évoque SuperCollider)
  • # Certaines choses bizarres

    Posté par . Évalué à 3.

    Je ne dirai rien au niveau des détails techniques vu que je suis pas un spécialiste, mais je trouve certains éléments de la syntaxe bizarre quand même:

    - la visibilité d'un champ/d'une méthode qui se définit par le nom (uppercase ou non)
    - la définition d'une méthode qui est en fait une fonction normale avec un truc en plus

    D'un autre côté, j'aime bien le fait qu'on puisse retourner plus d'une valeur dans une fonction

    Par contre, est-ce qu'il y a la possibilité d'utiliser des bibliothèques existantes ? (Qt, GTK, etc) Si c'est pas le cas ça freinerait quand même pas mal l'adoption pour des applis desktop. Mais peut-être que c'est pas leur but.
    • [^] # Re: Certaines choses bizarres

      Posté par . Évalué à 3.

      Par contre, est-ce qu'il y a la possibilité d'utiliser des bibliothèques existantes ? (Qt, GTK, etc) Si c'est pas le cas ça freinerait quand même pas mal l'adoption pour des applis desktop. Mais peut-être que c'est pas leur but.

      Étant donné que Go est conçu pour de la programmation système, j'imagine que les applications de type desktop ne sont pas du tout leur cible.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Certaines choses bizarres

        Posté par (page perso) . Évalué à 7.

        Y a aussi des bibliothéques systémes ( la libevent, par exemple, openssl, les libs pour taper sur mysql, etc, etc ).

        Et puis, ç'est pas parce que c'est pas la cible que les gens vont pas l'utiliser pour ça :)
    • [^] # Re: Certaines choses bizarres

      Posté par . Évalué à 3.

      Par contre, est-ce qu'il y a la possibilité d'utiliser des bibliothèques existantes ? (Qt, GTK, etc)
      Ça ne m'étonnerait pas que des "bindings" apparaissent si Go intéresse suffisamment de développeurs.
      Après tout, Python (par exemple) n'est pas né avec des bindings GTK et Qt, mais maintenant il y en a.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Certaines choses bizarres

      Posté par (page perso) . Évalué à 2.

      D'après la FAQ, on peut facilement linker du Go avec du C . Pour ce qui est du C++, ils espèrent pouvoir faire ça en passant par une interface SWIG.

      Donc plutôt bof a priori pour Qt, possiblement OK pour Gtk.
    • [^] # Re: Certaines choses bizarres

      Posté par (page perso) . Évalué à 2.

      Moi j'aime bien l'idée d'avoir des interfaces à la duck-typing.

      Le modèle de classe / méthode me fait penser à la simplicité de lua, ce qui permet de l'optimiser à donf sans passer par des tables de fonctions virtuelles.

      Globalement, ça me plait.
  • # Get back ?

    Posté par . Évalué à 4.

    Pas de chance, un nouveau bug à la liste, va falloir changer de nom ...

    http://code.google.com/p/go/issues/detail?id=9&colspec=I(...)
    • [^] # Re: Get back ?

      Posté par (page perso) . Évalué à 4.

      Goog ?
      Gogue (*) ?
      :D

      (*) http://fr.wiktionary.org/wiki/gogue
      • [^] # Re: Get back ?

        Posté par . Évalué à 5.

        Gol.
      • [^] # Re: Get back ?

        Posté par . Évalué à 8.

        Je propose Goldorak (Go !)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Get back ?

      Posté par (page perso) . Évalué à 4.

      C'est effectivement amusant que Google (si ça vient bien de chez Google) n'utilise pas Google pour vérifier si il y a des antécédents.

      Mais le pire, c'est que "Go", c'est franchement nul de chez nul pour faire des recherches. Si je recherche "python array" et "go array" je ne vais clairement pas avoir la même qualité au niveau des résultats.
      • [^] # Re: Get back ?

        Posté par (page perso) . Évalué à 10.

        C'est peut-être fait exprès pour forcer les programmeurs à utiliser la doc plutôt que de googler et tomber sur des conseils douteux sur des forums mal fréquentés (kikoolol PHP).

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

        • [^] # Re: Get back ?

          Posté par (page perso) . Évalué à 4.

          Mais inciter à ne pas passer par Google quand on s'appelle Google, c'est marrant.
          • [^] # Re: Get back ?

            Posté par . Évalué à 2.

            ils pourraient l'appeler "goo" :)

            Je suis d'accord, le nom "go" est trop générique et court pour le rendre pertinent lors d'une recherche d'information, c'est nul comme nom. Tiens, pourquoi pas "null" comme nouveau nom ?

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: Get back ?

              Posté par . Évalué à 10.

              Oh oui! Et puis on programmerait visuellement, avec des patatoïdes colorés qu'on lierait les uns aux autres. Selon leur couleur, les patatoïdes auraient différentes fonctions au sein du programme. Et pour éviter que l'utilisation mémoire ne crève les plafonds, on ajouterait un mécanisme (basé sur la gravité, par exemple) qui empêcherait de faire des constructions trop compliquées. Les commentaires se feraient directement sur des pancartes.

              Sans déconner, ça pourrait avoir un succès mondial ce truc!

              (pardon, fatigue, tout ça)
  • # Programmation noyau et ramasse-miettes

    Posté par . Évalué à 6.

    J'ai lu à plusieurs reprises que l'usage du ramasse-miette dans la programmation d'un noyau était déconseillée, était une mauvaise idée, ce qui disqualifierait Go pour un tel domaine.

    Or je ne puis m'empêcher de penser aux machines LISP. Leur OS était programmé en LISP, et LISP utilise les GC depuis un bout de temps. De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ?

    Questions : ces systèmes LISP furent-ils programmés sans GC et avec typage statique ? Si tel n'est pas le cas qu'est-ce qui explique qu'elles furent non seulement fonctionnelles, mais puissantes et relativement peu buggées (si j'en crois ceux qui en ont eus entre les mains) ? La structure même de la machine ?
    • [^] # Re: Programmation noyau et ramasse-miettes

      Posté par (page perso) . Évalué à 2.

      Le matériel était effectivement adapté au langage utilisé pour logiciels qui tournaient dessus. C'était bien codé dans des LISPs à typage dynamique et avec GC.

      Alors non, ce n'était pas dépourvu de bugs (car les dialectes de LISP étaient nombreux, et pas forcément aussi agréables que l'actuel Common Lisp), tout comme le rappelle Joe Marshall dans son très bon blog où il raconte des histoires de debuggage qu'il a vécues dans les années 80 [1].

      Mais bon, les GC d'alors, c'était pas la panacée, hein. Ni les interprètes et compilateurs…

      Sinon, tu dis : « De plus faut-il rappeler que les LISP sont généralement dynamiquement typés ? », mais je ne vois pas le rapport avec le GC. Enfin, avec le typage dynamique, tu as un tag sur tes données, donc le GC sais différencier un entier d'une adresse, une chaîne de caractères d'un symbole… Ça se nettoie très bien tout ça.
      Puis le typage dynamique n'impose pas qu'on ne type rien ! T'as pleins d'optimisations de typage local, d'évaluation partielles qu'on peut faire quand même…

      [1] : http://funcall.blogspot.com/2009/03/talk-to-greenblatt.html cette série d'articles s'étale sur plusieurs mois.
      • [^] # Re: Programmation noyau et ramasse-miettes

        Posté par . Évalué à 1.

        Au sujet du typage dynamique, oui, je suis tout à fait d'accord. Je présentais juste l'exemple des machines LISP car généralement on présente les langages dynamiquement typés et/ou avec GC comme inapte pour la progra d'un kernel. Il me semble que nous avions là un assez bon contre-exemple.
        • [^] # Re: Programmation noyau et ramasse-miettes

          Posté par . Évalué à 4.

          oui et non, kernel est un mot assez creux, si tu en parles ici les gens n'auront que la vision de celui de Linux (et des autres Unix, des BSD...)

          faudrait ressortir d'autres architectures comme euh les calculateurs HP 48 et compagnie, on ne savait pas forcément où ça commençait et où ça s'arretait, quand encore c'était documenté...

          (et, hop, plein d'objets de base déjà en ROM ! plus besoin de les jeter, dis-donc !)
  • # L'oublié

    Posté par . Évalué à 1.

    Certes Robert Griesemer n'a pas le CV des deux autres comparses néanmoins il a aussi participé à l'élaboration de ce language.

    Sinon c'est chouette d'avoir un nouveau dans la classe. On verra s'il tient ses promesses. En tout cas, il a l'air déja plus sympa qu'Alef, le language concourrant de l'illustre Plan9 :-)
    • [^] # Re: L'oublié

      Posté par (page perso) . Évalué à 2.

      >>> Certes Robert Griesemer n'a pas le CV des deux autres comparses néanmoins il a aussi participé à l'élaboration de ce language.

      Tu a raison j'aurai du donner aussi son nom. Mea culpa.
    • [^] # Re: L'oublié

      Posté par . Évalué à 1.

      En tout cas, il a l'air déja plus sympa qu'Alef, le language concourrant de l'illustre Plan9 :-)

      L'ex-langage concurrent de Plan9, d'ailleurs :-)

      Ça pourrait être très sympa d'ailleurs, sous Plan9.
  • # Quelques petites rectifications et une question

    Posté par (page perso) . Évalué à 1.

    Ken Thomson n'est pas seulement un des auteurs d'Unix, il est le père fondateur d'Unix. De même, il est aussi un des auteurs de Plan9 et un des pères fondateurs de celui-ci. En effet, avec Plan9 il a voulu remettre à plat Unix en prenant en compte l'expérience et le recul sur la conception de ce système (son objectif était de pousser le "tout est fichier" à son point extrême). C'est dans ce contexte que certaines parties de Plan9 ont d'abord été prototypées en Pike avant d'être réécrit en C.

    Maintenant, Rob Pike, le concepteur du langage du même nom, avec, apparemment, l'aide de Ken Thomson, envisage de remettre à plat le C au travers du langage Go. Espérons qu'il ait plus de succès qu'avec Plan9 qui méritait tout de même de réussir.

    Toutefois, je me pose une question : est ce que de nos jours un langage de programmation système doit être impératif pour réussir ou être efficace ? Un langage fonctionnel ne pourrait il pas aussi être pertinent dans la programmation système ?
    • [^] # Re: Quelques petites rectifications et une question

      Posté par . Évalué à 2.

      L'interface vers la machine est forcément à effet de bord. Comment gérer cela proprement en fonctionnel ?

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

      • [^] # Re: Quelques petites rectifications et une question

        Posté par . Évalué à 3.

        Avec des monads bien sûr !
      • [^] # Re: Quelques petites rectifications et une question

        Posté par (page perso) . Évalué à 2.

        Comme l'a répondu kaouete, le concept de monads d'Haskell permet d'y répondre. Voir par exemple le window manager XMonad pour ça.

        Toutefois, ta réponse est pertinente au sens où un des principes des langages fonctionnels est d'être libre d'effets de bords, principe qui a dérivé d'ailleurs vers plutôt la maîtrise des effets de bords (parce qu'il est impossible d'être sans effets de bords ; notre univers n'est il pas entropique ?). Au regard de ceci, on peut douter effectivement de la pertinence de l'usage d'un langage fonctionnel dans la programmation système. A côté de ça, sa maîtrise des effets de bord fait que la programmation fonctionnelle semble, à l'heure actuelle, plus propre et efficace à répondre aux problèmes du parallélisme. (Et le langage Go semble avoir été écrit aussi pour répondre aux défis que posent maintenant les architectures multi-cœurs.)

        En fait, lorsque je posais cette question, j'avais plus en tête son modèle déclaratif qui apporte une approche intéressante dans la résolution des problèmes ; j'ai l'impression de plus en plus que les solutions à nos problèmes informatiques se traduisent plus facilement dans une approche fonctionnelle qu'impérative.
        • [^] # Re: Quelques petites rectifications et une question

          Posté par . Évalué à 2.

          Je ne connais pas les monad, mais j'ai du mal à imaginer plus simple qu'une écriture en mémoire.

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

          • [^] # Re: Quelques petites rectifications et une question

            Posté par (page perso) . Évalué à 2.

            Ou encore l'écriture sur un écran ;-)
            Les monads sont des structures qui enferment la notion d'effet de bord et pour lesquels un ensemble d'opérations est défini. On y trouve par exemple IO pour les entrées/sorties, X pour l'affichage graphique (dans XMonad), State pour la gestion des états, etc. Les monads obéissent en général à un certain nombre d'axiomes. Ceci permet de singulariser et d'identifier les effets de bords dans le but d'éviter de les repartir dans tout le code.
            J'ai trouvé un lien que je pense intéressant pour un peu saisir le concept de monad :
            http://www.haskell.org/haskellwiki/Monad
            • [^] # Re: Quelques petites rectifications et une question

              Posté par . Évalué à 2.

              J'ai essayer de comprendre les monad en lisant "l'implémentation C":

              http://www.reddit.com/r/programming/tb/1761q

              J'ai compris qu'il teste en gros la validité d'un paramètre avant qu'il plante. Cela semble tellement sans intérêt !

              http://sleepingsquirrel.org/monads/monads.html ici il essaye de le faire en perl.

              En gros, il montre comment lier des opérations entre elle. Pourquoi ne pas utiliser une variable qui sert à identifier le flot au lieu d'utiliser une fonction explicite de lien est un mystère.

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

              • [^] # Re: Quelques petites rectifications et une question

                Posté par (page perso) . Évalué à 1.

                Pour l'implémentation en C, c'est plus que tester la validité d'un paramètre. C'est une implémentation du monad Maybe d'Haskell qui permet de simuler sans en avoir les problèmes d'effet de bord du null pointer. Le concept du null ou nil a été introduit par Hoare qui, par la suite, l'a regretté car celui-ci introduit des effets de bords indésirables, ce qui conduit au programmeur d'être sur la défensive. Dans Haskell, une variable peut être de type Maybe a, c'est à dire c'est soit une valeur de type a, soit il est rien (il n'est pas initialisé) ; on dit que c'est une variable ou valeur monadique. La monad Maybe permet de représenter et d'informer de la possibilité qu'une donnée peut être nulle. Ceci permet alors d'utiliser des fonctions sur ces types de données sans se faire avoir par surprise par un effet de bord indésirable (de toute façon le compilateur nous rappelle à l'ordre).

                Pour l'implémentation en Perl, elle est longue et je ne l'ai que rapidement lu. Son objectif semble de modéliser en Perl les monads (structure qui implémente la notion de changement d'état et qui implique donc aussi une séquence nécessaire des opérations). Ici l'objectif est de prendre une valeur monadique (autrement dit une variable) et d'appliquer sur celle-ci des fonctions pour en ressortir une autre valeur monadique. (De cette valeur monadique, on peut en sortir une valeur pure qui peut donc ne plus être modifiée.) Avec bind, on peut appliquer une fonction pure sur des valeurs monadiques. En singularisant les effets de bords, on peut plus facilement les contrôler. Après, selon le langage, ça peut rendre le code lourd.
              • [^] # Re: Quelques petites rectifications et une question

                Posté par . Évalué à 2.

                Pourquoi ne pas utiliser une variable qui sert à identifier le flot au lieu d'utiliser une fonction explicite de lien est un mystère.
                Parce qu'une variable, comme tu la penses, représente ton effet de bord. On est revenu au point de départ.
                Dans un langage fonctionnel, tu n'as pas de variable au sens "impératif", donc tu ne peux pas utiliser ta "simplification". (OK, l'implémentation était ici faite dans des langages impératifs, c'est tentant de les utiliser ...)

                Les monades (avec un "e" en français, il me semble) sont assez complexes, et on met beaucoup de temps à les comprendre (plusieurs années pour moi, sans y être à plein temps dessus quand même). Mais c'est une notion vraiment assez géniale à découvrir, même si, selon moi, sa complexité fait que ce ne sera jamais quelque chose que beaucoup de gens utiliseront.
                • [^] # Re: Quelques petites rectifications et une question

                  Posté par (page perso) . Évalué à 2.

                  >> Les monades (avec un "e" en français, il me semble) sont assez complexes, et on met beaucoup de temps à les comprendre (plusieurs années pour moi, sans y être à plein temps dessus quand même).

                  Euh, une monade, en pratique (i.e. en programmation Haskell), c'est rien d'autre qu'un vulgaire design-pattern.
                  T'as une interface (les types des opérateurs), et les gars se masturbent pour coller tout et n'importe quoi qui colle à cette interface…

                  Des monades, j'en code en OCaml, en Scheme et en Common Lisp quand c'est pratique (typiquement la monade non déterministe (c-à-d la monade Liste)), sinon, je me fais pas chier…


                  Les monades, d'un point de vue catégorique (au sens mathématique du mot « catégorie », là, sont moins faciles à comprendre, oui), mais t'as aucunement besoin de comprendre ça pour coder en Haskell. Ça, c'est de la propagande ridicule (« wéé ! on a des monades, c'est trop top ») trop souvent clamée par des « newbies » qui n'ont rien compris mais qui se donnent l'impression d'appartenir à une classe de gens supra-intelligents. Dire « j'ai pu résoudre mon problème grace aux monades d'Haskell, » c'est comme dire « j'ai pu résoudre mon problème grace au pattern décorator de Java. » Comme si on pouvait pas faire autrement, ni avec un autre langage…
                  • [^] # Re: Quelques petites rectifications et une question

                    Posté par . Évalué à 5.

                    Je crois que j'ai vaguement compris le principe des monades en Haskell, j'essaye de comprendre le concept mathématique (bien plus large), et tu as sûrement raison d'un point de vue pratique.

                    Par contre, il me semble que les monades en théorie de la programmation fonctionnelle, c'est pour que le langage garde son accès "pur" en n'ayant pas d'effets de bords pour garder les bonnes propriétés de la programmation fonctionnelle, intuitivement je dirai en se démerdant pour avoir l'état du système entier en paramètre de la fonction ...
                    Ça peut se voir comme un design pattern, genre un couple (valeur encapsulée*état du système) plus les fonctions générique qui permettent de construire et de manipuler ce type, et les fonctions d'ordre supérieur qui encapsulent des fonction qui traitent de la valeur ...

                    D'un autre côté ça permet de voir l'état du système non plus comme une variable globale qu'on modifie mais comme un "paramètre" d'une fonction qui retourne un autre état du système, c'est l'artifice qui permet de garder la pureté du langage ... j'ai bon ;) ?
                    • [^] # Re: Quelques petites rectifications et une question

                      Posté par (page perso) . Évalué à 3.

                      Dans ton exemple pratique, tu penses uniquement à la monade IO qui est un gros hack pour les effets de bord. La pureté en question, c'est pour se donner bonne conscience; en pratique, c'est aussi sale qu'un effet de bord dans un autre langage. C'est un artifice, oui, et comme argument, ça vaut zéro. C'est pas la monade qui permet ça, c'est le style de programmation : « environment passing style. »
                      Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
                      S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !

                      En revanche, l'idée d'encapsulation, elle, est meilleure.

                      Quand tu écris
                      do
                        x <- extraction
                        return (foo x)

                      c'est comme si tu écrivais
                      do
                      x <- extraction_hors_de_la_boite(boite)
                      met_dans_une_boite(foo x)

                      Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
                      C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
                      Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »


                      Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
                      Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.

                      T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.

                      Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
                      De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^
                      • [^] # Re: Quelques petites rectifications et une question

                        Posté par (page perso) . Évalué à 1.

                        Je ne sais pas si les monades dans Haskell comme les IO sont de gros hacks. Ce que je suis sûr c'est qu'ils me permettent de programmer de façon plus propre en évitant de répartir le code à effet de bord un peu partout. J'ai trouvé que c'était plus facile à déboguer. Au regard de ceci, je trouve que tu exagères avec ton «La pureté en question, c'est pour se donner bonne conscience » ; c'est leur solution pour identifier et isoler les effets de bords afin de mieux les maîtriser et par conséquent garder un code a minima pur. On peut aimer ou non la soupe : dans ce cas, vaut mieux dire «je n'aime pas» que« c'est pas bon».
                        • [^] # Re: Quelques petites rectifications et une question

                          Posté par (page perso) . Évalué à 2.

                          Non. Tu peux très bien en haskell mettre des effets de bord partout.
                          Suffit de tout coder dans la monade IO. C'est comme en POO : tu peux tout faire dans une seule classe et envoyer balader ces classes, ces interfaces et tout ça. Je peux « coder en C » aussi bien en Haskell qu'en Java.

                          Ce qui garde les effets de bords à un strict minimum, c'est le programmeur. J'en met là où j'en veux, quelque soit le langage.
                          Quand à la soupe (et haskell), j'aime et je trouve ça bon. En revanche, je n'aime pas qu'on dise « c'est grâce aux monades » quand ça n'a pas grand chose à voir… Mon code est quasi identique en OCaml et en Haskell, pourtant, en ML, je peux mettre des effets de bord partout…

                          La « pureté » n'a raison d'être qu'au niveau des types, dans la formalisation mathématique. En pratique, ça change que dalle. Ah si, ça te prend 3 fois plus de temps quand tu veux tracer ton code (bon, t'as des moyens, mais ça vaut pas un printf placé ça et là…)
        • [^] # Re: Quelques petites rectifications et une question

          Posté par (page perso) . Évalué à 4.

          monad

          En français on dit monade, c'est un concept mathématique et pas juste une particularité d'Haskell. N'hésitez donc pas à ajouter un « e ».

Suivre le flux des commentaires

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