Go : Un nouveau langage chez Google

Posté par (page perso) . Modéré par Florent Zara.
29
12
nov.
2009
Golang
Le langage Go (sous une licence de type 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 cœur 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 les 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 tutoriel 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).

NdM : Merci à patrick_g pour son journal à l'origine de la dépêche.
  • # un clone de Vala ?

    Posté par . Évalué à 2.

    En lisant la description, ça me fait penser au langage Vala : http://live.gnome.org/Vala
    • [^] # Re: un clone de Vala ?

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

      Vala est un langage qui est traduit en C puis compilé en binaire.
      Là on parle de "vrai" langage.
      • [^] # Re: un clone de Vala ?

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

        Je ne vois pas en quoi la phase de transformation d'un souce vers quelque chose d'exécutable peut définir ce qu'est un "vrai" langage. Tu peux préciser ?
        • [^] # Re: un clone de Vala ?

          Posté par (page perso) . Évalué à -8.

          Simplement quelque chose du style :

          r, e := syscall.Open(name, mode, perm); // Retourne 2 valeurs

          est impossible à faire en C (si tu parle du Vala) par contre en assembleur c'est possible.
          • [^] # Re: un clone de Vala ?

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

            Où est-ce qu'il est imposé qu'une instruction du langage source ne peut être traduite qu'en une seule instruction ?
      • [^] # Re: un clone de Vala ?

        Posté par . Évalué à 3.

        Comme le C qui est traduit en assembleur.
      • [^] # Re: un clone de Vala ?

        Posté par . Évalué à 4.

        Il ne faut pas confondre "langage" et "compilateur". Le fait que la compilation s'effectue en deux étapes n'a aucun rapport avec la définition du langage. Rien n'empêche de créer un compilateur plus performant dans le futur.
  • # Le Monde en parle

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

    ... et fait un énorme raccourci qui a l'avantage de donner un gros coup de pub à Python. :-)

    « combine certains aspects du Python et du C++, deux des principaux outils de programmation utilisés actuellement »

    Article complet : http://www.lemonde.fr/technologies/article/2009/11/12/google(...)
  • # système et garbage collector?

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

    Je suis perplexe... Comment peut-on faire un langage système avec un garbage collector. Ca fait peut-être vieux jeu, mais travaillant dans le jeux vidéo, je me vois assez mal utiliser un garbage collector.
    • [^] # Re: système et garbage collector?

      Posté par . Évalué à 2.

      Et comment faire un langage parallèle sans garbage collector, c'est ça la vraie question...
      • [^] # Re: système et garbage collector?

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

        Ca existe, les threads Posix ça permet de faire du parallélisme en C/C++, sans garbage collector. La mémoire est partagée, et la fonction standard malloc permet aux différents threads d'allouer et de libérer de la mémoire.

        Sinon, je suis assez curieux de voir ce que donne ce garbage collector avec Go. J'ai également du mal à imaginer comment cela peut se passer en mode noyau (pas de mémoire virtuelle dans ce cas !).
        • [^] # Re: système et garbage collector?

          Posté par . Évalué à 4.

          Sauf que c'est *beaucoup* plus dur la programmation par thread plutot que la programmation par messages... et il faut décider à qui appartient l'objet pour le libérer, un gc simplifie énormement la vie.

          Je ne crois pas que Go soit fait pour être un langage de programmation kernel... (c'est pour la prog système).
          • [^] # Re: système et garbage collector?

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

            et il faut décider à qui appartient l'objet pour le libérer, un gc simplifie énormement la vie.

            Des solutions classiques (communément appelés Design Pattern, désolé pour l'anglissisme, mais les traductions systématiques ne sont pas toujours adaptées, àmha) pour résoudre les problèmes de ce genre.
            • [^] # Re: système et garbage collector?

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

              Qu'est qui ne te plaît pas dans motif de conception ?
              • [^] # Re: système et garbage collector?

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

                Dans ce cas là, je traduirais plutôt par :
                "conception par motif" (qui n'a pas d'équivalent dans un autre domaine pour son utilisation en français)
                qui est plus long à dire que "Design Pattern" (qui en plus a un bonus d'attaque pipo-bimbo marketing).
                Du coup, "Design Pattern" est plus adapté, plus rapide à prononcer, plus "decision manager compliant", ...

                Autant "baladeur" est une traduction agréable de "walkman", "Cédérom" c'est déjà moins évident pour "CD".
                J'utilise systématiquement courriel (courrier éléctronique <-> electronic mail) parce que l'idée est toujours présente et que le mot est "esthétique" à la prononciation.
                Je suis à 100% pour la francisation des termes, s'ils veulent dire quelque chose.

                Les anglais pourraient aussi traduire "cul de sac" (pour impasse) en "buttbag" à ce moment là :-D
              • [^] # Re: système et garbage collector?

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

                C'est pas la traduction de Design Pattern qui me dérange mais plutôt la traduction des différents motifs : les traductions que l'on peut trouver dans les différents bouquins ne sont pas identiques entre elles, et ne sont pas toujours correctes. Pour moi les motifs de conception sont des solutions techniques mais aussi des outils de communication. Et quand tout le monde n'utilise pas le même vocabulaire pour parler de la même chose, parfois même sans s'en rendre compte, ça induit des complications.
                • [^] # Re: système et garbage collector?

                  Posté par . Évalué à 4.

                  "Motifs de conception" ?
                  J'ai plutôt tendance à voir "patrons de conception", comme quoi, le vocabulaire semble en effet ne pas toujours être le même...
                  • [^] # Re: système et garbage collector?

                    Posté par . Évalué à 4.

                    Oui, « motif » parce que :
                    — ils se répètent ;
                    — ils sont motivés¹.

                    De toute façon, le problème de traduction porte plutôt sur le vocabulaire que forment les motifs (leurs noms propres) que sur le nom que l’on donne à leur genre (motifs ou patrons).

                    ¹ dans le sens « raisonné », pas « qui-n’en-veut » comme Bruno Lochet.
                  • [^] # Re: système et garbage collector?

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

                    Pattern, motifs, patrons... et pourquoi pas gabarits de conception ?
                    • [^] # Re: système et garbage collector?

                      Posté par . Évalué à 8.

                      Pour la traduction de terme pattern, nous avons le choix entre patron, gabarit, motif, modèle ou ne pas traduire.

                      Gabarit est déjà utilisé pour le terme de template (notamment en C++), il désigne un type, ou une fonction, paramétré. La traduction est en fait très fidèle car ces mots référencent, chacun dans sa langue, une pièce de bois servant à en préparer d'autres (en construction navale).

                      Modèle est déjà fortement polysémique et nécessiterait l'adjonction d'une explication. (Bien qu'il soit utilisé pour gabarit dans la traduction du bouquin de Stroustrup, C++, le langage 1999.)

                      Patron est en fait l'étymon de pattern, il a un sens très proche de gabarit, mais il a un second sens en français, celui de «dirigeant», qui peut créer une équivoque, une ambiguïté.

                      Motif est la traduction usuelle de pattern en informatique : pour les expressions régulières, le traitement automatique de texte, etc.

                      Motif porte à la fois le sens de figure, forme, répétée et celui de raison, motivation. Or l'utilisation du terme motif dans le contexte du génie logiciel ne permet pas de distinguer clairement laquelle des deux acceptions fait le plus de sens ; il est en effet autant probable que l'on parle de répétitions ou de formes abstraites, modèles de plusieurs formes concrètes, que de motivations, mobiles, d'utilisations de techniques, de concepts ou de modèles d'ingénierie.

                      Toutefois, — et contrairement à celui de patron —, le second sens de motif (raison, mobile) n'est pas antinomique de la définition des motifs : ceux-ci sont une motivation, une raison, de leur propre application et des concepts qu'ils véhiculent.

                      Motif semble donc un meilleur choix comme équivalent (ou un peu plus, grâce à la notion de motivation que le terme anglais ne porte pas) du terme de pattern.
    • [^] # Re: système et garbage collector?

      Posté par . Évalué à 2.

      Je ne vois pas le rapport.

      J'ai l'impression que beaucoup de vieux GC demande plusieurs seconde pour s'exécuter or il est possible de faire des pauses plus courtes.

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

    • [^] # Re: système et garbage collector?

      Posté par . Évalué à 3.

      Il est possible de faire un delete dès qu'un objet n'est plus utilisé. Que ce soit le langage qui le fasse ou le développeur, ça a quasiment la même rapidité d'exécution.
      Le tout est de faire les delete dès que possible, sans les accumuler pour les faire plus tard.
      • [^] # Re: système et garbage collector?

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

        Le tout est de faire les delete dès que possible, sans les accumuler pour les faire plus tard.

        Ca, c'est assez naïf comme vision. Justement, dans un jeu video où il y a beaucoup de temps réel, reporter un delete a plus tard peut être très important. Et si les delete se produisent de façon automatique, cela peut créer de vrais problèmes puisqu'il ne devient plus possible de le reporter.
    • [^] # Re: système et garbage collector?

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

      J'ai longtemps pensé qu'une gestion de la mémoire avec GC était forcément plus couteuse que faite à la main.

      Et puis j'ai lu des choses comme celles-ci:

      http://www.ocaml-tutorial.org/garbage_collection


      Le fait d'avoir un GC n'implique pas pour autant de se contenter de prendre de la mémoire sur le tas et de laisser le compilateur/l'interpréteur se débrouiller:

      http://www.inrialpes.fr/pop-art/people/bjeannet/mlxxxidl-for(...)
    • [^] # Re: système et garbage collector?

      Posté par . Évalué à 6.

      Ca fait peut-être vieux jeu, mais travaillant dans le jeux vidéo, je me vois assez mal utiliser un garbage collector.

      Dans les années 80 les programmeurs de jeux video se voyaient assez mal utiliser autre chose que l'assembleur.
      (et encore, certains se sentaient bridés par l'assembleur parce qu'ils souhaitaient utiliser les instructions non-documentées du processeur)


      PS : tu as benchmarké ton malloc ? si ça se trouve c'est une grosse bouse mal codée qui te fait perdre de précieux cycles machine
      • [^] # Re: système et garbage collector?

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

        Héhé, je ne crois pas ;)
        Les allocateurs des OS sont souvent lents c'est pourquoi dans le jeu vidéo on en recode un. Donc ce serait quand même con qu'on aie refait un allocateur plus lent alors que notre but est qu'il soit plus rapide. On utilise justement des outils pour connaître précisément où on gagne et ou on peut gagner encore plus.

        Ceci dit, je suis d'accord avec toi, la mentalité des développeurs de jeux vidéo est souvent rétrograde, mais ce n'est pas uniquement par religion. Même si on code en C++, on utilise toujours des instructions CPU que le compilo n'utilise pas même avec l'optimisation la plus poussée ; je pense notamment au SIMD.
        J'essaye pour autant de ne pas tomber dans le cliché "le seul langage valable c'est l'assembleur". C'est juste qu'un GC ne me semble pas pour autant très crédible dans un jeu vidéo, notamment parce que l'on a un besoin trop important de maîtriser ce qui se passe.

        Ceci dit j'ai cru comprendre que ce n'était pas le but de Go que de coder des jeux avec, donc pas de problèmes finalement! ;)
        • [^] # Re: système et garbage collector?

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

          Même si on code en C++, on utilise toujours des instructions CPU que le compilo n'utilise pas même avec l'optimisation la plus poussée ; je pense notamment au SIMD.

          Si tu regardes http://www.linux-kongress.org/2009/slides/compiler_survey_fe(...) certains compilateurs utilisent des instructions SSE (pages 27 et 28) et l'assembleur inline n'est pas toujours pertinent (pages 53, 54, 55).

          Après ça va dépendre du compilateur surtout...
          • [^] # Re: système et garbage collector?

            Posté par . Évalué à 2.

            Concernant l'utilisation d'instructions vectorielles, si on prend un compilo non-libre (icc), oui, il vectorise (mieux que gcc dans l'ensemble, mais gcc est en train de sérieusement combler son retard). Par contre, il faut des contraintes fortes à garantir à la compilateur (ou facilement vérifiable à l'exécution sans prendre trois plombes). Du coup, hors des cas « faciles », il faut encore se faire l'appel d'intrinsics à la main dans le code là où ça a du sens.
  • # Première remarques

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

    J'ai commencé à regarder et ça me semblait pas mal jusqu'à ce que je tombe sur quelques trucs...

    Pourquoi avoir enlevé les parenthèses autour des if, for... On obtient des trucs du genre :
    for i := 0; i < len(a); i++ {
    if a[i] != ' ' {
    s += a[i]
    }
    }

    C'est peut-être moi qui suit bigleux mais franchement je trouve ça beaucoup moins clair. Les parenthèse on quand même l'avantage de bien délimiter chaque parties.

    Et ensuite, pourquoi suivre la mode qui hélas touche de plus en plus de langage, qui consiste à mélanger la syntaxe et la sémantique. Ici on se retrouve à définir la visibilité des variables, fonctions, membres... en utilisant ou non des majuscules.
    Là aussi, je vais peut-être passer pour un con, mais que ce soit le choix des majuscule, des underscores ou de l'indentation ; j'estime que c'est à moi de choisir ce que je trouve le plus lisible, et le langage n'a pas à m'imposer une manière plus qu'une autre.
    Le seul avantage, c'est que ça tue le débat entre les partisans du camelcase ou du jesaispasquoi... Mais pour moi, ça donne plus l'impression qu'il veulent imposer leurs conventions et leur style de code.

    Donc dommage, encore un langage qui n'est pas pour moi, vieux grincheux que je suis ;-(
    • [^] # Re: Première remarques

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

      Moi j'aime bien que le langage limite le nombre de "coding style" , ça aide a la lisibilité entre codeurs.

      Un exemple que tu me fournis : je trouve l'habitude de laisser les accolades ouvrantes en fin de ligne totalement illisible (probablement parce qu'on m'a appris a les mettre a la ligne), et j'imagine que tu trouveras mes sources C illisible pour la même raison. Idem pour les déclaration de fonction, en C il y a 50 façon différentes d'écrire une déclaration de fonction, et quand on est habitue a une certaine façon, les autres sont très pénibles a lire.

      Ce sont des problèmes qu'on ne rencontre par exemple pas en Python. Pas d'accolade, oblige d'intenter tous pareil, ça fait qu'un source python code par un inconnu a de forte change d'être aussi lisible qu'un de ses propre fichier source.

      Pour pour le Go et les accolades, c'est raté, mais pour le reste des contraintes sur la syntaxe, je peux comprendre...
      • [^] # Re: Première remarques

        Posté par . Évalué à -10.

        Ce sont des problèmes qu'on ne rencontre par exemple pas en Python. Pas d'accolade, oblige d'intenter tous pareil, ça fait qu'un source python code par un inconnu a de forte change d'être aussi illisible qu'un de ses propre fichier source.
      • [^] # Re: Première remarques

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

        Donc en gros, on se retrouve avec un langage ou "d'un point de vue personnel" tous les programme, même ceux que moi je suis susceptible d'écrire, sont forcément moche.

        Peut-être que pour d'autre c'est joli, mais je continue de penser que le langage ne devrait rien imposer à ce niveau là.
        • [^] # Re: Première remarques

          Posté par . Évalué à 6.

          Sauf que c'est essentiellement une question d'habitude et de pinaillage, comme tu le l'indiquait en début de commentaire, donc de sujets de troll ...

          Ici on gagne à avoir un référentiel commun pour tout le monde, des styles d'écriture standards que n'importe qui finit par avoir l'habitude de lire, donc au final plus facilement lisible par tout le monde.
          • [^] # Re: Première remarques

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

            Mais au final, tout le monde a un avis différent sur l'esthétique du code et donc on se contente de limiter le nombre de personnes qui vont adopter le langage.

            Par exemple, les identifiant (de classe il me semble mais je ne suis plus sûr) tout en majuscules de Lisaac sont la principale raison qui m'a fait abandonner ce langage qui pourtant contenait pas mal de bonne idées. Mais non, je n'ai pas réussit à m'habituer à ces horreurs.

            De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.

            Sans parler du fait que toutes ces conventions qui sont utilisées de manière implicite par le compilateur rendent le programme plus difficile à comprendre pour une personne externe.

            Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.
            • [^] # Re: Première remarques

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

              Si tu juges un langage uniquement sur sa syntaxe, ben ... je sais pas trop quoi dire mais ça me parait tellement réducteur. Certes, la syntaxe n'est pas anodine et je peste sur la syntaxe old school de CMake par exemple, mais de là à refuser d'utiliser un outil parce que sa syntaxe est pourrie, ça me dépasse. Quid de la facilité d'utilisation en général, de la pertinence à résoudre simplement ou pas les problèmes qui se posent à toi, du jeu de bibliothèque, de l'expressivité du code, de la maintenabilité, de l'intérêt des nouveaux concepts, de la performance, de la portabilité ?


              De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.


              Une indentation bien particulière oui. Poser plus de problèmes qu'elle n'en résout, je suis pas d'accord. Le code est plus lisible, il y a moins de caractères à taper, et il est indenté de façon uniforme. Bon, de toute façon, j'ai jamais compris cet argument. C'est OK d'imposer un langage de programmation pour donner des ordres à un ordinateur, c'est ok d'utiliser une indentation cohérente pour faciliter la séparation sémantique des blocs mais c'est pas ok que cette séparation sémantique fasse partie du langage. C'est ok de forcer à utiliser un point-virgule à la fin de chaque ligne, c'est ok d'utiliser plein de caractères ésotériques pour la programmation ( &!<*{;]:?}[ ) mais c'est pas ok d'avoir moins de caractères pour programmer.


              Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.


              De même, un codeur (comme moi) qui lit du ruby dit : j'y comprends rien. Et il dit la même chose quand il lit du lua, du perl, du SmallTalk, du lissac, du Haskell et du LISP. Mais avant de dire que le langage est une grosse merde et le codeur un gros brlanleur, je me dis que peut-être je devrai me documenter un peu plus sur le langage.
              • [^] # Re: Première remarques

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

                Je ne le juge pas uniquement sur la syntaxe, mais cela fait partit de tout ce qui entre en compte dans mes choix. Et le fait que je trouve les boucle for de Go illisible par exemple est un élément vraiment bloquant pour moi.
                Quand tu relis du code pour vérifier qu'il fait bien ce que tu pense ou que tu traque un bug, la lisibilité est un facteur très important. Et je préfère un langage un peu moins expressif mais parfaitement lisible, à un code ambiguë où, sous prétexte de taper quelques caractères de moins, on a supprimer des délimiteurs redondant mais qui facilitent énormément la lecture.

                C'est le même problème avec l'indentation en python. L'idée de base de forcé les gens à indenter correctement leur code est louable même si je suis contre. Le problème c'est que même en faisant ça, les gens réussissent à te faire des horreurs. Il suffit de voir que les guidelines continue quand même de parler de la manière d'indenter le code et que certains pondent des horreurs comme celle-là : http://lapagearegis.free.fr/guidedestyle.html qui conseillent de mélanger les espaces et les tabulations.
                Donc, quoi que tu fasses, tu peux être sur que ceux qui veulent foutre le bordel réussirons à le faire d'une manière ou d'une autre.

                L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.
                Ils sont redondant de la même manière que dans les langues naturelles il y a de nombreuses redondances. Tout comme les ; en fin de ligne ne sont pas toujours nécessaire, mais ils permettent d'indiquer clairement ou ce termine une instruction et ou commence la suivante.

                L'objectif de tout cela est de faciliter la lecture du code. De manière idéale, lorsque tu lis du code, tu ne devrait pas avoir à réfléchir sur les aspects syntaxiques ; tu devrais voir directement à quoi correspond chaque instructions et l'effort mental ne devrait concerner que la logique du code pour essayer de comprendre ce que fait le programme et voir si c'est bien ce que tu veux.
                • [^] # Re: Première remarques

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

                  > les boucle for de Go illisible par exemple
                  et si on voyait la même chose avec une coloration syntaxique efficace ? (prenant en compte tout le langage)
                  par exemple ce qui se trouve entre for/if/while/... et { pourrait être mis en évidence, et dans ce cas on aurait :
                  - lisibilité avec un bon éditeur (ce qui pour moi est bien plus important que la lisibilité sans)
                  - moins de caractères à tapper, moins de parenthèses oubliées
                  - conséquence du dernier, plus "fiable" dans le sens où si on ne peut pas avoir d'erreur (de frappe, d'attention) sur les parenthèses c'est un plus (genre if(myFunction(getMyParameter()) { qui est faux)
                  alors oui, un bon éditeur pourrait aussi le mettre ne évidence, mais en fait oui les parenthèses ne servent à rien dans ce cas...
                  • [^] # Re: Première remarques

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

                    Cela me rappelle le ColorForth par Chuck qui est un Forth colorié avec encore moins de symbole. Cela pose des problèmes à l'impression et puis, à force de trop réduire, cela n'est pas forcément plus lisible.

                    La couleur est un plus mais ne doit pas être essentielle (en plus, il y a des daltoniens en nombre non négligeable).
                    • [^] # Re: Première remarques

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

                      c'est bien pour ça que je parle d'un éditeur avec coloration syntaxique (et non d'un langage utilisant la couleur comme élément syntaxique)
                      Déjà chacun peut choisir la couleur qu'il veut, le thème qu'il veut et pas (peu) de problèmes pour ça. De plus, il n'y a pas que la couleur, mais aussi la mise en forme (gras, italique, souligné, etc)

                      Mais par contre, qui imprime encore du code ? A quoi ça sert ?

                      > La couleur est un plus mais ne doit pas être essentielle
                      Oui, elle ne doit pas être essentielle pour le code, mais les outils sont importants pour coder efficacement.
                • [^] # Re: Première remarques

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

                  L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.


                  Note que le seul cas où il y a ambiguïté visuelle en Python est le cas où d'une part, le programmeur a mélangé allègrement tabulation et espaces, et d'autre part, ton éditeur n'est pas configuré comme l'éditeur de l'auteur original (et encore, uniquement dans un mode défavorable; s'il a choisi 2 espaces pour une tabulation et que tu en utilises 8, le code sera encore lisible parfaitement). Si t'es sous vim, tu pourras rectifier la situation en 3 secondes et ça doit être possible sous d'autres éditeurs.

                  Note que la même situation peut se produire avec du C++. Le code sera tout aussi moche et plein d'ambiguïtés visuelles, mais tu pourras encore le compiler. Est-ce que c'est mieux ou moins bien ? je ne saurai dire...

                  D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :


                  int * a, b, c, d; // oops, qui est un pointeur et qui ne l'est pas ? Ou est donc l'aide des délimiteurs ?

                  for( i=0, i < 10, i++) // ah ah, le délimiteur me fait-il sauter aux yeux cette erreur de syntaxe pourtant patente ?

                  for( i=0; i <37 && pasFini == true; i++ ) ; {
                  .... // fait des trucs mais il ne le fait qu'une fois au lieu de 37 fois. Merci aux délimiteurs.
                  }




                  Je ne suis pas non plus d'accord que les délimiteurs rendraient le code plus lisible. Après quelques années à faire du python et à me déshabituer de la syntaxe C/C++, un code chargé de symboles abscons comme ces deux derniers langages me semble beaucoup plus illisible que du code python qui me semble clair et surtout aéré.

                  Aller, un petit exemple à deux balles :

                  l = [1,2,3,4,5]
                  for i in l :
                  .... print i



                  int array[] = { 1, 2, 3, 4 ,5 };
                  std::vector l( array, array + sizeof( array ) / sizeof( int ) );
                  for( std::vector::iterator it = l.start(); it != l.end(); ++it ) {
                  .... printf( "%d\n", *it );
                  }


                  Merci à linuxfr qui ne permet pas de taper facilement du code !

                  En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.

                  Donc pour en revenir à nos moutons, en ce qui me concerne, je me réjouis que les concepteurs d'un nouveau langage pensent aussi à sa lisibilité en utilisant une syntaxe légère. Les jeunes barbus sont choqués, les vieux barbus regardent ça avec une moue dédaigneuse et un vague sourire en coin (ah plan 9, ça, c'était quelque chose) et les jeunes boutonneux regardent soit avec un enthousiasme démesuré, soit avec des yeux de merlans frits.
                  • [^] # Re: Première remarques

                    Posté par . Évalué à 3.

                    Le problème de python avec ses blocs fait par indentation c'est les codes transmit par des boulets, les erreurs du style :1,$<<<<< (puis :x), ou autre.

                    Si par une raison ou une autre il y a suppression de l'indentation, t'es bon pour te farcir tout le code. Quand c'est pas toi qu'il l'a écris et que tu a du mal à comprendre ce qui se passe, je te garantis que ça te vaccine à vie d'utiliser un langage sans accolade (ou tout autre chose pour délimiter les blocs).

                    L'idée est excellente à la base, mais tout les éditeurs du monde savent (re)formater du code en le réindentant comme il faut pourquoi s'embêter à faire quelque chose qui peut poser des problèmes très long à résoudre ?

                    Et pour ce qui est des caractères gagnés,personnellement je fais pas du golf quand je programme et j'utilise régulièrement des générateurs de codes à partir d'UML qui font beaucoup. Certains utilisent aussi des IDE comme eclipse ou netbean ou configure leur emacs/vim pour qu'il insère automatiquement les parenthèses et autres. En fin il existe des outils qui permettent de vérifier les style de programmation pour garantir l'homogénéité du code.

                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: Première remarques

                      Posté par . Évalué à 3.

                      les erreurs du style :1,$<<<<< (puis :x)

                      Heu, ça c'est pas du Python.
                      Si t'utilises un éditeur de texte mal fichu c'est pas la faute du langage de programmation ;)
                  • [^] # Re: Première remarques

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

                    D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :

                    Mon affirmation ne portait pas sur l'ensemble du langage mais uniquement sur la partie délimitée par le délimiteur. Ce que je disait c'est qu'avoir des parenthèse autour de la condition dans les if ou dans les boucles c'est bien plus lisible et beaucoup moins ambigue à mon gout. Cela ne veut pas dire que le reste de la syntaxe ne pose pas de problèmes.
                    Le C est plein de problèmes à ce niveaux là, mais dans ce cas, pourquoi gardez tout ces problème et en rajouter d'autres ? Pourquoi ne pas plutôt juste corriger les problèmes existants ?

                    En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.

                    Tu ne triche pas sur le C++ mais quelques petites remarques :
                    - La STL à été fait avec les pieds par des manchots aveugle qui voulait ce venger du reste du monde ;
                    - Pour un exemple comme celui là, utiliser un vector ne sert qu'à perdre du temps, il faudrait comparer sur des exemple un peut plus intéressants ;
                    - Tu prend exactement un des pires cas de la STL (qui démontre très bien d'ailleurs l'absurdité de beaucoup de chose dans cette bibliothèque.)

                    Si on oubli les outils de torture et que l'on ce place dans une situation un peu réaliste pour du C, tu 98% de chance d'avoir la taille de ton tableau quelque part dans une variable accessible. Si ce n'est pas le cas, il y a de fortes chances que tu ait un problème et le code devient :
                    for (int i = 0; i < len; i++)
                    printf("%d\n", tab[i]);

                    Qui est déjà beaucoup plus lisible que la version C++....

                    Alors, en soit ça peut sembler plus complexe et plus verbeux que ta version en python, mais l'avantage c'est que ta boucle est quasiment identique si tu veux parcourir ton tableau dans l'autre sens, ou si tu veux afficher les indices en même temps que les valeurs, ou parcourir deux tableaux en même temps.

                    Donc sur un exemple on à l'impression d'être perdant, mais sur une utilisation générale, tu y gagne en homogénéité : tous les parcours seront codé sur le même modèle.
                    C'est vraiment une question de gouts mais moi j'ai fait mon choix ;-)

                    Donc pour en revenir à nos moutons,[...]

                    Je pense que je rentre maintenant dans la case vieux barbus, vu que je ne suis pas choqué mais que j'ai plutôt tendance à regarder ce genre de nouveau langage avec un petit sourire en coin ;-)
                    C'est domage, je ne pensait entrer dans cette catégorie que l'an prochain, et merde, j'ai pris un an d'avance
                    • [^] # Re: Première remarques

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

                      J'ai pris un tableau d'entier pour simplifier mais il est évident que l'utilisation d'une boucle avec ce type de complexité en C++ ne se justifie que par exemple pour parcourir une structure custom (genre arbre) qui te retourne un itérateur, et qui contient aussi une structure custom.

                      Dans ce cas, la STL est bien adapté et la syntaxe est bien celle que je décris, en python comme en C++.
                  • [^] # Re: Première remarques

                    Posté par . Évalué à 1.

                    Déjà on peut rendre le code un peu plus claire avec l'instruction "using namespace" (et en utilisant du C++ jusqu'au bout) :
                    using namspace std;
                    int array[] = { 1, 2, 3, 4 ,5 };
                    vector l( array, array + sizeof( array ) / sizeof( int ) );
                    for(vector::iterator it = l.start(); it != l.end(); ++it ) {
                    ....cout << *it << endl;
                    }


                    Les itérateurs C++ sont très intéressant par leur compatibilités avec le C. Les algos de la STL utilisent un iterateur de début et un itérateur de fin. Tu peut y mettre simplement des pointeurs ça marcheras aussi bien. Si ça te fais si mal d'écrire vector::iterator bientôt tu pourras utiliser auto.

                    Ensuite comme dis beagf pour le C, avec les iterateurs C++ tu as des fonctionnalités que tu n'a pas en python (ni même avec du C d'ailleurs). Faire un parcours en sens inverse consiste uniquement à changer le type de l'itérateur. De la même manière tu peut indiquer comme constantes les données de ton conteneur.

                    J'apprécie par rapport au foreach que tu peut trouver dans pleins de langages. La notion d'itérateur, elle permet de concevoir des algorithmes sur n'importe quel conteneur tout en pouvant (pour l'utilisateur de la fonction) choisir l'ordre de inverse ou pas et si les données sont constantes ou pas.

                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: Première remarques

                      Posté par . Évalué à 4.

                      La notion d’itérateur existe en python, hein. Et même si l’itérateur qui lit en sens inverse n’existe pas de base, c’est l’affaire de quatre lignes pour en faire un (pas optimisé, certes). Avantage par rapport à ceux de C++, c’est que faire un iterateur perso, en python, c’est trivial, l’affaire d’une fonction (et avec les closures, c’est encore plus simple). En C++, c’est déjà plus coton.
                      • [^] # Re: Première remarques

                        Posté par . Évalué à 2.

                        J'ai pas encore eu besoin d'en créer mais c'est vrai qu'il faut créer une classe à l'interieure d'une classe. Pour en revenir au message au quel je répond, la STL elle propose pour tout ces conteneurs les 4 types d'itérateurs.

                        Sinon l'avantage c'est qu' pour une boucle de parcourt en C++ tu peut choisir facilement l'ordre et la propriété const ou non sans changer de syntaxe.

                        Je viens de regarder en python, je vois pas comment dans le "foreach", on peut choisir l'ordre.

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                        • [^] # Re: Première remarques

                          Posté par . Évalué à 1.

                          Sinon l'avantage c'est qu' pour une boucle de parcourt en C++ tu peut choisir facilement l'ordre et la propriété const ou non sans changer de syntaxe.

                          Dans un langage où "const" existe j'imagine que c'est chouette, oui.

                          Je viens de regarder en python, je vois pas comment dans le "foreach", on peut choisir l'ordre.

                          Déjà il n'y a pas de foreach en python.
                          Ensuite tu peux utiliser reversed():

                          >>> l = range(5)
                          >>> l
                          [0, 1, 2, 3, 4]
                          >>> reversed(l)
                          <listreverseiterator object at 0x7f1eb0c6be90>
                          >>> for i in reversed(l): print i
                          ...
                          4
                          3
                          2
                          1
                          0
                          • [^] # Re: Première remarques

                            Posté par . Évalué à 2.

                            Est-ce que reversed() est une fonction ou bien une construction spéciale du langage ? Est-ce qu’elle construit la liste inversée ou bien permet-elle de parcourir une liste (ou autre) à rebours ?

                            Parcourir une liste à rebours est bien différent de construire une liste inverse pour ensuite la parcourir dans l’ordre.
                            • [^] # Re: Première remarques

                              Posté par . Évalué à 2.

                              reversed() est une fonction que tu pourrais écrire toi-même. La preuve, je te fais une implémentation naïve en trois lignes :

                              def reversed(l):
                              … for i in xrange(len(l)-1, -1, -1):
                              ……yield l[i]

                              Voire, encore plus court :

                              def reversed(l):
                              … return (l[i] for i in xrange(len(l)-1, -1, -1))

                              (la construction (f(x) for x in iterable) est assez récente, c’est une sorte de map que l’on retrouve dans les langages fonctionnels, mais qui travaille (et renvoie) sur des itérateurs au lieu de listes)

                              Et c’est bien une méthode de parcours, pas la construction d’une liste en sens inverse.
                            • [^] # Re: Première remarques

                              Posté par . Évalué à 3.

                              C'est une fonction, qui si la méthode __reversed__ de l'objet existe va l'appeler, sinon une technique générique est utilisée.

                              http://docs.python.org/reference/datamodel.html?highlight=re(...)
                            • [^] # Re: Première remarques

                              Posté par . Évalué à 2.

                              reversed est un builtin de python, tout comme range. et il retourne un itérateur, pas une nouvelle collection inversée:
                              assert 'reversed' in __builtin__.__dict__
                              assert 'range' in __builtin__.__dict__
                              l=range(5)
                              rl=reversed(l)
                              assert l[3]==3
                              l[3]=2
                              assert list(rl) == [4, 2, 2, 1, 0]
                              
                        • [^] # Re: Première remarquesn

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

                          nan mais franchement les iterateurs c++ c'est de la merde en branche, je comprends pas comment on peut defendre ce truc lourdingue et verbeux. Mes boucles c'est 99% du temps un truc qui itere du debut à la fin, alors les rbegin et les rend je m'en fustige le cristallin, et je donnerais cher pour avoir un vrai foreach qui marche de base dans mes compilos c++ et qui ne me demande pas d'ecrire des dizaines de caractères inutiles et redondants !
                      • [^] # Re: Première remarques

                        Posté par . Évalué à 0.

                        pour itérer en sens inverse:
                        for i in reversed(range(10)):
                          print i
                        
                    • [^] # Re: Première remarques

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

                      Ou encore, en C++

                      std::vecor l { 1, 2, 3, 4, 5 };
                      for (int i : l)
                      . . . std::cout << i << std::endl;

                      (à compiler avec l'option -std=c++0x dans gcc)
                      • [^] # Re: Première remarques

                        Posté par . Évalué à 2.

                        Tu me l'apprends. Gof c'est pour « Gang of four » ?

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Première remarques

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

                  des horreurs comme [...] mélanger les espaces et les tabulations

                  C'est pourtant la seule manière qui permettent d'avoir une indentation correcte quelle que soit la taille d'une tabulation, pour peu qu'on respecte ces trois règles simples:
                  - Afficher les tabulations comme n espaces (et non le nombre d'espaces nécessaires pour aller à la prochaine colonne multiple de n)
                  - Ajouter (respectivement supprimer) une tabulation pour ajouter (respectivement supprimer) un niveau d'indentation
                  - Utiliser la même classe des caractères de la ligne du dessus pour aligner (utiliser une tabulation si le caractère de la même colonne et de la ligne au dessus est une tabulation et espace sinon).
                  Ça donne par exemple, pour les langages obsolètes (-- est une tabulation) :

                  void f()
                  {
                  --int --i;
                  --char--j;
                  ...
                  }


                  Ou pour des langages modernes :

                  def plop truc
                  --truc = if truc.nil?
                  -- --0
                  -- else
                  -- --truc.to_i
                  ...
                  end
                  • [^] # Re: Première remarques

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

                    Là par contre je ne suis pas du tout d'accord. La seul manière d'avoir une indentation correcte quelle que soit la taille d'une tabulation et de n'utiliser que l'un ou l'autre.
                    Tout mélange finira par t'apporter des problèmes : avec ta méthode :
                    bip
                    --bop
                    -- bap
                    --bop
                    ----bap

                    Rien ne t'oblige à utiliser la même indentation pour les deux "bap" alors que ça doit être le cas.

                    Et j'irais même plus loin, la seule méthode d'indentation correcte consiste à utiliser une tabulation par niveau, ce qui permet à chacun de choisir la largeur de ses tabulation et de voir un ode à son gout.
                    Les tabulation étant très simple à remplacer par des espaces, les plus grincheux sont contents aussi. (alors que dans l'autre sens on retrouve des problèmes)

                    Pour ce qui est de l'alignement vertical, qui est une chose différente de l'indentation, mais que l'on trouve dans ton premier exemple, l'utilisation de tabulation me semble inapproprié. Tu te trouve à éloigner parfois très fortement le nom de la variable de sa déclaration ce qui peut rendre la lecture difficile.
                    Le plus simple est souvent de ne faire cet alignement que de manière intelligente, en regroupant les variables ou autres de manière cohérente et en utilisant des espaces.
                    • [^] # Re: Première remarques

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

                      Ton exemple ne correspond pas à ma méthode, puisque tu utilises des espaces pour rajouter des niveaux d'indentations. Les espaces ne doivent servir qu'à aligner si la ligne du dessus contient des caractères autres que des tabulations (comme dans le deuxième exemple, en ruby : utiliser uniquement des tabulations dans ce cas n'indentera pas correctement si tu utilises des largeurs de tabulations différentes).
                      • [^] # Re: Première remarques

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

                        Je comprend pas ta méthode. Pour quoi faire :
                        def plop truc
                        --truc = if truc.nil?
                        -- --0
                        -- else
                        -- --truc.to_i
                        ...
                        end

                        Plutôt que :
                        def plop truc
                        --truc = if truc.nil?
                        ------0
                        ----else
                        ------truc.to_i
                        ...
                        end


                        C'est bien plus simple et lisible à mon avis d'indenter du même espacement dans tous les cas.
                        Je ne vois pas dans ce cas qu'elle est la logique qui te fais utiliser un espace à partir de la troisième ligne.
                        • [^] # Re: Première remarques

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

                          Pour aligner le else avec le if. Il y a plus que trois espaces en fait.
                          • [^] # Re: Première remarques

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

                            Dans ce cas, pourquoi ne pas plutôt écrire :

                            def plop truc
                            --truc =
                            ----if truc.nil?
                            ------0
                            ----else
                            ------truc.to_i
                            ...
                            end


                            Ça n'utilise que des tabulations et l'alignement est à mon gout bien plus clair, on voit bien à quel if correspond le else mais surtout on voit bien qu'il y a un if dans l'affectation.
                            Ça fait une ligne de plus, mais de nos jours, on n'est plus vraiment limité à 20 ou 25 lignes à l'écran.

                            Le faire tel que tu le fait me semble dangeureux. Cela nécéssite que toutes les personne qui travail sur le même code que toi reglent leur éditeur pour qu'il reproduise l'indentation de la ligne précédente à l'identique. C'est le genre de truc qui finit toujours par merder et faire perdre un max de temps parce qu'un boulet à fait un commit sans vérifier.
                            • [^] # Re: Première remarques

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

                              Si je comprends bien, ta solution au problème d'indentation consiste à ne jamais utiliser d'alignement vertical... Ce n'est pas tellement ce que j'appelle une solution.

                              Le faire tel que tu le fait me semble dangeureux. Cela nécéssite que toutes les personne qui travail sur le même code que toi reglent leur éditeur pour qu'il reproduise l'indentation de la ligne précédente à l'identique. C'est le genre de truc qui finit toujours par merder et faire perdre un max de temps parce qu'un boulet à fait un commit sans vérifier.

                              N'est-ce pas le cas quel que soit la méthode d'indentation choisie ? Si une personne utilise une autre convention que les autres, ça fout tout en l'air, je ne vois pas en quoi c'est plus dangereux avec la méthode que je préconise qu'avec une autre.
                              • [^] # Re: Première remarques

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

                                Si je comprends bien, ta solution au problème d'indentation consiste à ne jamais utiliser d'alignement vertical... Ce n'est pas tellement ce que j'appelle une solution.

                                Dans ma solution, le "if" et le "else" sont alignés verticalement, de même que le contenu du "if" et le contenu du "else".
                                Ma solution consiste à indenter en debut de ligne avec uniquement des tabulations, hors l'indentation est justement un alignement vertical.

                                De même, à mon avis il ne faut jamais utiliser de tabulation en dehors du début de ligne, l'alignement vertical à l'interieur des lignes ne doit ce faire qu'avec des espaces, donc si je reprend un de tes exemple au dessus, je le préfère de cette manière (avec les ~ pour symboliser les espace) :
                                void f()
                                {
                                --int~~~i;
                                --char~j;
                                ...
                                }


                                L'idée c'est de s'assurer que l'on puisse avoir un affichage à son gout tout en minimisant les risque que l'indentation deviennent incohérente.
                                La configuration par default de la majorité des éditeur consiste à utiliser les tabulations pour indenter, donc il y a peu de chances qu'une personne indente de manière incohérente sans le savoir.
                                Et pour les utilisateurs capable de modifier la config de leur éditeur, ils peuvent avoir l'aspect qu'ils désirent. Moi j'aime les grande indentation, donc mes tabulations sont reglées sur 8 espaces, alors qu'un pote préfère les petite donc il règle ses tabulations sur 2 espaces. Résultats on à tous les deux une indentation à notre gouts avec le même code.
                                Et en utilisant des espace pour lalignement à l'interieur des lignes, ont gardent tous les deux un alignement correct dans les lignes.

                                Avec ta solution, ça marche beaucoup moin bien. Moi j'aime les indentations homogène, si un codeur commence à mettre des espace comme dans ton code, certaine parties sont visuellement indentées avec plus d'espace que d'autres.
                                De même avec des tabulation régles sur 8 espaces, pour avoir des débuts de lignes qui me plaisent, l'alignement vertical avec des tabulation devient horrible, les variables sont séparées de eur type par plus de 8 espaces...
              • [^] # Re: Première remarques

                Posté par . Évalué à 3.

                mais de là à refuser d'utiliser un outil parce que sa syntaxe est pourrie, ça me dépasse

                Dans ce cas-là, pourquoi s'enthousiasmer pour Go alors que ocaml existe ?
    • [^] # Re: Première remarques

      Posté par . Évalué à 2.

      Carrément d'accord avec toi !

      Les parenthèses sont bien pratiques alors que là ça rend la ligne plutôt illisible, ça demande un effort supplémentaire de lecture. Idem pour le typage des variables, déjà que l'on tombe sur des codes où les noms des variables sont pas du tout explicites si en plus on sait plus ce que la personne a voulu mettre dedans ca devient la grosse misère :-(

      Dernier point, c'est la "pauvreté" des librairies qui pourrait être un frein... s'il faut attendre encore 2 ou 3 ans pour voir apparaitre des librairies qui simplifient la vie comme par exemple en java les Commons librairies, c'est pas intéressant non plus :-(

      Pas pour moi non plus, vieux grincheux que je suis aussi ;-)
      • [^] # Re: Première remarques

        Posté par . Évalué à 2.

        Pas pour moi non plus, vieux grincheux que je suis aussi ;-)

        En même temps y'a pas de release ni de specification stable, pour l'instant c'est surtout pour faire joujou et voire la réaction de la communauté...
    • [^] # Re: Première remarques

      Posté par . Évalué à 8.

      Pour les parenthèses, je ne suis pas sûr qu'elle soit vraiment nécessaire et que ce n'est pas un simple question d'habitude.

      Le point qui me choque plus, c'est par exemple la déclaration de variable où il apparaît que :
      var s string = " "
      est équivalent à :
      s := " "

      Je n'aime pas ce genre de raccourcis qui vont être utilisés par certains et pas par d'autres.

      Dans le même genre, les points virgules sont autorisées en fin de ligne mais sont inutiles. Pourquoi les autoriser dans ce cas ? Je n'ai pas le droit de mettre un point d'interrogation à la fin de ma ligne, pourtant, on pourrait l'ignorer de la même manière.
      • [^] # Re: Première remarques

        Posté par . Évalué à 1.

        Dans le même genre, les points virgules sont autorisées en fin de ligne mais sont inutiles. Pourquoi les autoriser dans ce cas ? Je n'ai pas le droit de mettre un point d'interrogation à la fin de ma ligne, pourtant, on pourrait l'ignorer de la même manière.
        C'est pratique de les autoriser, cela permet par exemple de grouper plusieurs instructions sur la même ligne aux fins d'améliorer la lisibilité.
        • [^] # Re: Première remarques

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

          > grouper plusieurs instructions sur la même ligne afin d'améliorer la lisibilité

          Dans quels cas ?
          Pour ma part j'ai très souvent l'impression que condenser le code de cette manière améliore très très rarement la lisibilité (sauf pour le développeur qui trouve que c'est mieux, concis toussa,, mais finalement pour ne pas dire lisible que par lui ou pour réduire un nombre de ligne inutilement)
          • [^] # Re: Première remarques

            Posté par . Évalué à 2.

            Dans une de mes machines, des trous sont disposés en quinconce, je regroupe les cotes en x et en y. Ce n'est pas follement indispensable mais ça me plaît et je trouve que ça améliore la lisibilité en condensant un peu le code là où il a peu d'intérêt algorithmique en regroupant des termes de même nature.

            dx1 := -600; dx2 := -124; dx3 := 352
            dy1 := 1025; dy2 := 1300; dy3 := 1575; dy4 := 1850
            -- dz := 0

            puis par la suite :

            create Result.make_from_array
            (« create {POSITION_ROBOT}.make (dx1, dy1, dz),
            create {POSITION_ROBOT}.make (dx2, dy2, dz),
            create {POSITION_ROBOT}.make (dx3, dy3, dz),
            create {POSITION_ROBOT}.make (dx1, dy3, dz),
            create {POSITION_ROBOT}.make (dx2, dy4, dz) »)

            ou

            aller_xy_absolu (x, y: INTEGER) is
            do
            x_consigne := x; y_consigne := y
            [...]
            end


            Voilà, c'est du sucre syntaxique, pas de quoi verser le sang, mais je trouverais dommage d'avoir à s'en passer par je ne sais quel intaigrisme.
          • [^] # Re: Première remarques

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

            Condenser le code sur une ligne peut être une bonne idée. Il ne faut pas être intégriste sur ce point.
            Voici un exemple : if (ça va pas) { je fais ci ; je fais ça; on n'en parle plus } c'est pareil que
            if (ça va pas)
            {
            je fais ci ;
            je fais ça;
            on n'en parle plus
            }
            Ce genre de programmation permet de faire des programmes où l'on peut avoir un algorithme complet sur un écran sans faire de scrolling. C'est plus facile à lire, c'est moins fatigant et c'est plus productif... Sauf si on est payé à ligne de code !
            Il ne faut pas faire cela pour les parties essentielles du code mais on peut souvent le faire pour gérer les conditions initiales ou les tests d'erreur.

            J'ai travaillé de 1975 à 1982 sur des ordinateurs HP9825 où l'on ne pouvait voir et éditer qu'une ligne de code à la fois. Il fallait de temps en temps sortir un listing pour voir le programme dans son ensemble. Ensuite, j'ai travaillé pendant longtemps avec des terminaux 24 lignes de 80 caractères. C'était d'un confort rêvé ! Et puis un jour, en 1989, j'ai vu un écran qui affichait 60 lignes de code... Le paradis !
            Maintenant, j'ai chez moi un écran 26" de 1920x1200 et je trouve ça encore plus confortable. Plus on a une vue d'ensemble du programme, et plus c'est efficace et reposant.

            Il faut donc éviter de faire un code qui allonge inutilement le listing et rend sa lecture pénible.
            • [^] # Re: Première remarques

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

              autant je comprend bien l'exemple précédent, autant celui là je suis contre, tout comme l'absence d'accolades.
              Car si ça peut sembler sympa en lecture, en debug ça devient horrible.
              Imaginons un bug sur 'je fais ça', comment y placer un point d'arrêt ... sans réecrire le code ?
              Comment savoir si je suis rentré dans le corps if ?
              Comment je rajoute un 'else' également ?
              Même sans être en debug, cela est génant. En debug, on interdit d'autant les possibilités d'édition à la volée.


              > Il ne faut pas faire cela pour les parties essentielles du code mais on peut souvent le faire pour gérer les conditions initiales ou les tests d'erreur.

              oui, mais le problème (en tout cas tel que je le vois tous les jours) c'est que si on autorise quelque chose, tout en sachant exactement pourquoi on l'autorise une fois, il y aura toujours un autre pour le faire là où il ne faut pas.
              Et au final, on se retrouvera avec de la merde genre :

              for(..montemplatemoisi... idx = 0; idx < ...plopplop.getLength() && plop(); ++idx) if
              {
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
                plop
              }
              else
              {
                plop
                plop
                plop
                plop
                plop
                plop
              }

              (^- code véridique, je l'ai gardé au travers de mes boulots comme condensé de mauvais examples)

              En gros, si dans l'absolu je suis d'accord que c'est pas méchant et que ça peut apporter un mieux sur certains points, du moment que c'est bien utilisé, je trouve que les inconvénients (en terme de maintenance) sont bien plus nombreux.
            • [^] # Re: Première remarques

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

              > Maintenant, j'ai chez moi un écran 26" de 1920x1200

              Et grace aux formidables IDE modernes avec leurs moultes fenetres dockables et toolbars recouvertes de boutons, tu te retrouves quand même avec une fenetre de 80 colonnes et 25 lignes pour editer le code (et en plus ça rame)
          • [^] # Re: Première remarques

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

            Je le fais très rarement mais par exemple en bash en début de script, il m'arrive d'écrire


            commande=$1; shift

            Ainsi, on vide la pile d'un élément en même temps que la copie. Je trouve cela moins dangereux que de mettre le shift à la ligne suivante ou on se demande bien ce que viens faire ce truc la !
    • [^] # Re: Première remarques

      Posté par . Évalué à 2.

      [..]qui consiste à mélanger la syntaxe et la sémantique.

      La syntaxe définit la sémantique. Tu peux aussi dire "oui mais on m'oblige à utilise des accolades pour la définition de mes blocs, bouh!" bein ouais, derrière l'accolade il y a une sémantique, on aurait pu aussi choisir des begin / end.

      Personnellement je trouve cela pas trop mal, ça parait restreindre les libertés à première vue mais ça rend le code plus lisible... un peu comme l'indentation en Python.
  • # Pas de tarball :/

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

    C'est un peu ennuyeux la tendance montante qu'il y a à faire des releases sans fournir de tarball, ni de version.

    Je sais que c'est chiant à faire, mais c'est plus propre si quelqu'un veut faire un paquet pour faciliter la vie des autres.
    • [^] # Re: Pas de tarball :/

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

      Sauf que là, il n'y a pas de release, ils ont juste rendu public un projet qui est au stade, disons alpha avancé. C'est donc normal qu'il n'y ait pas de tarball ni de version. Le but, c'est de jouer avec et de faire des retours d'expérience, voire de participer à la construction...
  • # hmmm Android...

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

    J'ai lu en survolant le site qu'il y avait une version du compilateur pour ARM, qui avait été teste sur Android... Vu l'implication de Google dans le développement du langage ca me semble une très bonne nouvelle, Go me semblant vachement plus sexy que Java a première vue...
  • # Python et Google

    Posté par . Évalué à 4.

    Je me pose une question : est-ce que ce ne serait pas le début d'un abandon de Python par Google ?
    Ils estiment peut-être que les performances de Python ne sont pas suffisantes étant donnés leurs besoins et la montée en charge de leurs plate-formes.
    Mais du coup quid de Unladen Swallow ?
    • [^] # Re: Python et Google

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

      Il y a justement une discussion sur ce sujet (l'utilisation de Python par google) sur la liste de Unladen Swallow. La conclusion est simple et sans fioriture : google aime bien python mais il y a plein de tâches pour lequel il n'est pas du tout adapté.

      Par un des auteurs de Unladen Swallow :


      Well, simple common sense is going to limit Python's applicability when operating at Google's scale: it's not as fast as Java or C++, threading sucks, memory usage is higher, etc. One of the design constraints we face when designing any new system is, what happens when the load goes up by 10x or 100x? What happens if the whole planet thinks your new service is awesome? Any technology that makes satisfying that constraint harder -- and I think Python falls into this category -- *should* be discouraged if it doesn't have a very strong case made in its favor on other merits.
      • [^] # Re: Python et Google

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

        Moi je trouve que ça soulève surtout des questions sur la pertinence du modèle centralisé des services comme le développe google (d'un point de vu technique et social hein, d'un point de vu économique ça leur rapporte plein de brousouf le seul critère déterminant du modèle économique en vigueur).

        Certes pour un moteur de recherche, ça se justifie sans trop de problème, même si google publiait son moteur, ça ne me servirait à rien de l'installer à la maison. En revanche, pour des services comme gmail, google doc et autre, on crée un gigantesque point critique sans que ce ne soit techniquement justifié. Au contraire cela engendre des problèmes d'échelle qui n'existerait pas dans un modèle décentralisé.
        • [^] # Re: Python et Google

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

          Euh, je vois pas le rapport avec la choucroute ?

          On parle d'un langage développé en Open Source, incidemment par des employés de google. On parle ensuite des limitations techniques de Python, notamment dans le cadre d'application qui doivent tenir une très forte montée en charge et tu ressors le vieux laïus du grand méchant google.

          [mode offensif] Tu le sors à chaque fois qu'il y a qu'il y a marqué google dans un commentaire ?
          • [^] # Re: Python et Google

            Posté par . Évalué à 5.

            notamment dans le cadre d'application qui doivent tenir une très forte montée en charge et tu ressors le vieux laïus du grand méchant google.

            ??? Je ne lis pas ça comme ça.
            Son commentaire signale que la question de la "scalabilité" ne se pose que dans le cas d'une centralisation conséquente des données, ce qui me semble assez bien vu.
  • # Typage statique/dynamique

    Posté par . Évalué à 5.

    Bonjour à tous,

    je suis développeur. Je développe quasiment uniquement avec des langages qui subissent une phase de compilation (C, C++, Java, C# ).

    Comme la dépêche mentionne la politique de typage de Go, j'en profite pour poser quelques questions aux utilisateurs de python et ruby au sujet de cette fameuse politique de typage.

    D'après ce que j'ai lu, python et ruby sont tout les deux très expressifs : on fait beaucoup avec peu de code. Python et ruby ne m'avertissent qu'au moment de l'exécution de certaines erreurs que je peux avoir commis :
    - mauvais nom de variable : afficher (personne.DatttteDeNaissante )
    - mauvais type : afficher( divise(entier1, chaine2) )

    Du coup, si j'ai bien compris la philosophie, je dois écrire des tests pour tout. Y compris ce qui ne peut échouer que parce que les langages ne m'avertissent de certaines erreurs qu'à l'exécution.
    ( jusqu'ici j'ai bon ? ).
    De mon point de vue, je perds un peu l'avantage de l'expressivité puisque même pour du code trivial, je dois écrire un test si je veux m'assurer que le code est bon.

    Alors au quotidien, comment vous faites ? Vous écrivez des tests pour avoir 100% de couverture de votre code ? Vous livrez tel quel et vous corrigez si qqn tombe sur un bug idiot ? Il y'a des outils qui font certaines vérifications ? Eclairez moi.
    • [^] # Re: Typage statique/dynamique

      Posté par . Évalué à 8.

      En fait, si on veut éviter les bugs, il faut écrire des jeux de tests quel que soit le langage. Les vérifications effectuées à la compilation évitent quelques erreurs courantes, mais sont loin d'être suffisantes. Donc, puisqu'il faut de toutes façons écrire des tests, l'absence de ces vérifications n'est pas forcément trop génante en théorie.

      En pratique, pour plein de programmes, on n'écrit pas de tests, ou alors pas suffisamment. Cependant, ce sont souvent de petits scripts écrits à la va-vite, qui sont assez petits pour ne pas créer trop de casse-tête. En tout cas, c'est mon expérience suite à l'utilisation intensive de Ruby pendant des années.

      Une pratique de programmation que j'apprécie et que j'applique pour les gros projets consiste à commencer par les tests, qui deviennent alors une sorte de spécification de programme. Ensuite, j'écrit le programme afin qu'il passe tous les tests. Je trouve cette manière de faire très agréable.
      • [^] # Re: Typage statique/dynamique

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

        Autant je suis d'accord sur la bonne pratique qui consiste à ecrire ses tests avant et avoir une bonne couverture...

        ...Autant je reste convaincu qu'un compilateur intransigeant ça t'évite de perdre des gains de productivité énormes.
        Je vais prendre un cas extrême Caml :

        J'ai pas tant que ça coder en caml, mais quand le compilateur te dis "ok c'est bon, vas-y rien à dire"., c'est quand même très rare d'avoir un bug.

        Mon expérience de SSII bientôt derrière moi :-) m'a montré que l'essentiel des erreurs (en javouille) qu'on se coltine sur des gros ou moyens projets sont de deux ordres :
        - Erreurs imbitables venant du framework lui même imbitable (genre spring et consort)
        - Call on null le plus souvent et qq cast exception.

        Un bon compilateur qui fais du templating automatique (ie. exécution partielle sur tout ce qui est possible), de la détection de call on null, etc... ça t'évite beaucoup de problème.
        Il se trouve que caml avec son inférence de type, rempli pas mal ces tâches, d'où le fait que ça merde rarement après la compil.

        Bref, on a des machines bi-core à 2Ghz à 500€, on a pas mal de connaissance en IA, on peut apprendre à faire des compilateurs un tant soit peu intelligent et on aura énormément de productivité à gagner.

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

    • [^] # Re: Typage statique/dynamique

      Posté par . Évalué à 2.

      Python et Ruby et Perl et les autres langages dis "interprétés" sont compilés au moment de l'exécution. Quand je dis compilé, il s'agit en fait d'un abus de langage, car ils ne sont pas compilés en langage natif, mais au moins en représentation interne à l'interpreteur.

      Voilà pourquoi tu ne peux pas voir les erreurs de compilation autrement qu'en les exécutant. Il existe cependant des options dans les interpréteurs pour qu'ils exécutent uniquement la compilation en mémoire, si vraiment tu ne veux pas exécuter le code.

      Donc finalement, ça ressemble au langage compilés natifs.
      • [^] # Re: Typage statique/dynamique

        Posté par . Évalué à 5.

        À la vérification des types prêt ...
        • [^] # Re: Typage statique/dynamique

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

          Python a beau être quasi totalement dynamique, il existe de bons analyseurs statiques, à prendre pour ce qu'ils sont : des analyseurs statiques incapables de comprendre un code dynamique.
          D'ailleurs il faut être mille fois plus lisible dans le code dynamique : il évite souvent des lourdeurs dûes aux lourdeurs, mais au prix d'être un peu plus difficile à démêler.
      • [^] # Re: Typage statique/dynamique

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

        > (...) sont compilés au moment de l'exécution (...) Voilà pourquoi tu ne peux pas voir les erreurs de compilation autrement qu'en les exécutant.

        Pas d'accord. D'une part, comme tu le dis toi-même, tu peux les mettre en mode compilateur, où ils produisent des fichiers objets sans les interpréter (fichiers .pyo pour Python par exemple). De la même manière, avec beaucoup moins d'intérêt bien sûr, tu pourrais faire un compilateur C qui exécute immédiatement l'exécutable produit.

        L'absence d'erreur lors de la compilation n'a rien à voir directement avec le fait que ces langages sont interprétés. C'est purement lié au typage dynamique, certes souvent associé aux langages interprétés, mais rien ne l'impose.

        On pourrait imaginer un langage compilé avec types dynamiques (qui ne "péterait" donc qu'à l'exécution), ou à l'inverse un langage interprété avec typage strict, qui bloquerait dès la phase de compilation.
    • [^] # Re: Typage statique/dynamique

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

      En PHP tu peux tout à fait diviser par une chaine... ça fera juste une division par zéro ^_^
    • [^] # Re: Typage statique/dynamique

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

      mauvais nom de variable en perl :
      use strict;
      my $date;
      $datte="oops";

      erreur :)
    • [^] # Re: Typage statique/dynamique

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

      Note qu'il existe aussi pleins d'erreurs qu'un compilateur de langage statique ne décelera jamais.

      Tu as raison sur le fait que malgré tous les argument qu'on peut avancer, au final, la syntaxe de Python peut introduire des bugs qui peuvent générer une exception qui font planter l'application alors que certains de ces problèmes auraient été attrapés par des langages à vérification de typage statique type C++.

      Et pourtant, mon expérience personnelle, qui semble partagée, est que mes programmes C++ ont bien plus de bugs que mes programmes Python.

      On peut réfléchir à d'autres aspects. Par exemple, une étude d'IBM montrait que le nombre de bugs produit par un programmeur donné par nombre de lignes tapées est constant quel que soit le langage utilisé.

      Certaines constructions en python peuvent faire en 3 lignes ce qui prend une dizaine voire une vingtaine de ligne en C++. Ceci expliquerait peut-être cela, tout n'est pas dans le typage, statique ou pas, mais plus dans l'esprit du langage.
      • [^] # Re: Typage statique/dynamique

        Posté par . Évalué à 1.

        Tu as un lien vers cette étude d'IBM ? C'est vrai que c'est ce que je constate aussi...
      • [^] # Re: Typage statique/dynamique

        Posté par . Évalué à 3.

        L'étude en question parle du nombre de bug, pas le temps pour les trouver, ni le temps pour les corriger.

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

      • [^] # Re: Typage statique/dynamique

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

        D'où la supériorité indéniable de perl qui, lui, en fait plus en une seule ligne. \o/
      • [^] # Re: Typage statique/dynamique

        Posté par . Évalué à 3.

        Tu as raison sur le fait que malgré tous les argument qu'on peut avancer, au final, la syntaxe de Python peut introduire des bugs qui peuvent générer une exception qui font planter l'application alors que certains de ces problèmes auraient été attrapés par des langages à vérification de typage statique type C++.

        Et pourtant, mon expérience personnelle, qui semble partagée, est que mes programmes C++ ont bien plus de bugs que mes programmes Python.


        Ce n'est pas tant la syntaxe de Python mais bien sa sémantique et son typage dynamique qui sont en cause ici.

        Tu dis que tu as plus de bugs dans tes programmes C++, mais combien de ces bugs proviennent du manque de GC et du caractère globalement bas niveau de C++ tel qu'écrit par la plupart ? C++ n'est pas l'épitomé du typage statique, pour ma part des langages comme OCaml ou Haskell me paraissent nettement plus représentatifs des langages modernes à typage statique : inférence de type, système de type extrêmement riche et expressif, haut niveau d'expressivité du langage lui-même, à tel point que certains programmes sont plus courts en Haskell qu'en Python/Perl/Ruby tout en encodant bien plus de garantie dans le système de type... Quelle est ton expérience avec ces langages ?

        --
        Jedaï
  • # Parlons du langage D par rapport à Go

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

    patrick_g (dont j'adore ses dépêches) en parle à la fin: quid du langage D?

    J'ai suivi le langage D quasiment depuis son début. Même si je ne code pas avec, je suis toujours surpris par sa finition. Fini les commandes preprocesseur, gestion des templates, un Garbage Collector désactivable, etc...
    C'est, selon moi, ce que le C++ aurait dû être s'il n'y avait pas eu la contrainte de compatibilité avec le C (contrainte qui apporte aussi ses avantages, j'en suis bien conscient).

    Du coup, même si j'aime beaucoup ce que fait Google, j'ai peur que le langage Go aie une couverture médiatique plus importante uniquement parce que c'est Google qui est derrière.
    Pour ceux qui ont l'habitude du D et qui aurait testé le Go, quels sont les bons/mauvais points que l'on peut compter sur chacun des ces deux langages?
    • [^] # Re: Parlons du langage D par rapport à Go

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

      D'après un commentaire sur Reddit, Go est au C ce que D est au C++. ;-)

      D'après ce que j'ai pu en lire (pas essayé moi-même), D inclut manifestement beaucoup plus (trop ?) de fonctionnalités que Go. Par ailleurs, D a un sérieux problème de développement : deux version majeures incompatibles, manque de taille critique, plusieurs bibliothèques standard (?)... Je n'ai pas tout retenu, mais des critiques ont récemment fusé sur ces sujets.
  • # Portage Haiku

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

    sans préjuger des problèmes de syntaxe et autre sémantique, j'ai commencé un portage sur Haiku...
    le patch courrant :
    http://revolf.free.fr/beos/patches/golang-haiku-002.diff
    • [^] # Re: Portage Haiku

      Posté par . Évalué à 0.

      ed n'existe pas dans Haiku !? Moi qui croyais que c'était un Unice...
  • # Rapidité de compilation

    Posté par . Évalué à 0.

    La question que personne ne pose, c'est pourquoi privilégier la vitesse de compilation ? Ils indiquent que la compilation sera 80 à 90% plus rapide, alors que l'exécution sera plus lente, d'environ 10%.

    Auraient-ils en tête de lancer des compilations à tire-larigot sur leurs serveurs ? Un service de développement en ligne peut-être ?
    • [^] # Re: Rapidité de compilation

      Posté par . Évalué à 5.

      Si le but est de concurrencer/remplacer les langages interprétés que sont Python/Perl/Ruby, ça se tient assez bien. En accélérant la compilation, on se rapproche (un peu) du temps de compilation de ces derniers. Et en échange, on ne perd qu'un tout petit peu de vitesse d'exécution comparé aux langages compilés usuels, donc on reste largement plus rapide que les-dits langages interprétés.

      Non?
    • [^] # Re: Rapidité de compilation

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

      D'après ce que j'ai lu, Google a une méga-tonne de code C++, qui prend énormément de temps à compiler, ce qui gêne leurs développeurs. Leur but c'est donc d'avoir un langage pour remplacer C++ dans l'usage qu'ils en font, ainsi peut-être que Java.

      En gros, le compilateur semble très nettement plus rapide que le compilateur C++, et plus rapide également que Jikes, qui n'est pourtant pas lent.

Suivre le flux des commentaires

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