Hier est sorti la première version de Go, le langage de Google destiné à faire du système. Cette première version est l'aboutissement du developpement de Go depuis le début. Plusieurs packages ont migré dans la hiérarchie pour plus de cohérence. Les programmes qui seront écrits pour cette version 1 auront l'assurance de fonctionner avec les futures versions 1.X qui viendront.
Plus d'informations sur cette version 1 :
http://blog.golang.org/2012/03/go-version-1-is-released.html
Le site web de Go :
http://golang.org/
Un jour quand j'aurai le temps, je ferai une jolie critique négative de ce langage. J'en suis l'évolution, mais je crois que je ne coderai jamais en Go tellement il y a de choses que je n'aime pas, notamment dans la syntaxe. Il y a cependant de bonnes idées dont, à mon sens, les interfaces.
# Interface graphique
Posté par Calvin0c7 . Évalué à 4.
Est-ce qu'il y a un genre de toolkit graphique livré avec (genre awt ou swing avec Java) ?
Et si non (parce que j'en ai pas trouvé sur leur site) ça peut utiliser quoi d'existant (GTK ? Qt ? genre).
[^] # Re: Interface graphique
Posté par Pascal Terjan (site web personnel) . Évalué à 9.
D'après http://go-lang.cat-v.org/library-bindings :
# Quel avenir?
Posté par drakmaniso . Évalué à 3. Dernière modification le 29 mars 2012 à 17:46.
Moi c'est exactement l'inverse, il y a pas mal de chose que j'aime, notamment au niveau de la syntaxe.
Enfin un descendant de C qui se départit des maladresses de son aïeul, notamment la notation des types "à l'envers" qui a introduit tout un tas d’ambiguïtés dès que les types se sont un peu compliqués. L'omission des parenthèses pour les if et consorts clarifie aussi le code, même s'il demande un petit temps d'adaptation.
En fait, la seule chose qui me retient de coder en Go, c'est que j'ai beaucoup de mal à croire en son avenir… Peut-être trouvera-t-il sa place dans quelques domaines, mais je le vois mal remplacer C comme langage bas niveau universel.
[^] # Re: Quel avenir?
Posté par brendel . Évalué à 1.
C'est quoi que tu appelles la notation des types à l'envers ?
[^] # Re: Quel avenir?
Posté par claudex . Évalué à 9.
Comme ça
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quel avenir?
Posté par Philip Marlowe . Évalué à 5.
a_type a_variable; au lieu de a_variable: A_TYPE
[^] # Re: Quel avenir?
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 7. Dernière modification le 29 mars 2012 à 18:31.
J'imagine que c'est le fait de déclarer le type avant la variable (int x) alors que dans Go c'est l'inverse (x int). Ce qui apparemment peut avoir des intérêts quand c'est des types compliqués : http://golang.org/doc/articles/gos_declaration_syntax.html
Même si bon, après avoir fait du C ou d'autres langages qui s'en sont plus ou moins inspirées pour la syntaxe, perso c'est plutôt en lisant les exemples de Go que je me suis dit «ah tiens, c'est à l'envers» :) La force de l'habitude…
(Edit : [:grillai])
[^] # Re: Quel avenir?
Posté par Dr BG . Évalué à 6.
Ou un retour aux sources pour ceux qui ont appris à programmer à la fac avec Pascal.
Je me souviens que les pointeurs en Pascal ne me posaient aucun problème, ce qui n'a pas été le cas quand on a ensuite vu le C.
[^] # Re: Quel avenir?
Posté par neil . Évalué à 2. Dernière modification le 29 mars 2012 à 20:30.
C'est aussi la notation standard en mathématiques ou en informatique théorique.
[^] # Re: Quel avenir?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Wouah !!! Les souvenirs…
Houla, tu cherches le troll des langages là !!
[^] # Re: Quel avenir?
Posté par drakmaniso . Évalué à 4. Dernière modification le 29 mars 2012 à 19:49.
Oui, c'est bien de la position du type par rapport à la variable dont je parle.
Il est clair qu'on a (presque) tous l'habitude de lire les types C, mais qui n'a jamais froncé les sourcils devant un mélange de pointeurs/références savamment imbriqués à l'aide de parenthèses? Les pointeurs de fonctions, notamment, sont la plupart du temps complexes à lire.
[^] # Re: Quel avenir?
Posté par rewind (Mastodon) . Évalué à 7.
Bon, puisque tu insistes, voilà tout ce qui ne me plaît pas dans la syntaxe (http://golang.org/ref/spec) :
;: c'est con, soit on les rend obligatoire, soit on les enlève complètement, là on est le cul entre deux chaisesα(à part un clavier grec) ? Aucun, du coup, ça rend plus difficile la mise en commun de codeif,for, etc : je préfère mettre une seule parenthèse autour de l'expression plutôt qu'à l'intérieur à cause d'une précédence débile…goto: ça met Go au niveau de PHP, qui a également introduitgotoalors qu'il est parfaitement inutile et serait avantageusement remplacé par des structures adéquates pour les très rares cas oùgotoa une utilité (traitement d'erreur, chemin complexe).et ça, c'est juste pour la syntaxe…
Après, je dis pas, C et ses suivants ne sont pas parfait, très loin de là, mais avec Go, pour moi, on a une régression.
[^] # Re: Quel avenir?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 29 mars 2012 à 20:56.
En ce qui concerne les goto, ils ont toujours été présents dans le C, et le sont encore. Et comme tu le dis, ils ont leur utilité.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quel avenir?
Posté par Marotte ⛧ . Évalué à 1.
Ya des goto dans PHP dis-donc… Je pratique PHP depuis plusieurs années, je ne les ai jamais utilisés ! Je croyais que ça n'existait que dans les langages de la famille BASIC.
Je comprends que goto puisse avoir une utilité dans certains (très rares) cas. Mais pour le traitement d'erreur il y a les exceptions (try, catch), c'est plus propre.
C'est marrant, l'autre jour je me demandais si un langage de programmation qui aurait des caractères unicode (genre flèches et symbole mathématiques) pour les opérateurs aurait une quelconque utilité… Ok, pas facile à saisir mais ça ferait un code visuellement attrayant.
[^] # Re: Quel avenir?
Posté par ribwund . Évalué à 2.
Généralement seul un sous-ensemble de unicode est accepté (par exemple les lettres mais pas les symboles).
[^] # Re: Quel avenir?
Posté par dyno partouzeur de drouate . Évalué à 4.
Genre APL, un vrai langage d'homme.
[^] # Re: Quel avenir?
Posté par drakmaniso . Évalué à 2.
Je suis d'accord en ce qui concerne les tableaux et les identifiants unicode, ce ne sont pas des choix très heureux.
Par contre, pour avoir codé un peu en Lua, je suis fan de l'absence de parenthèses dans les if, et de l'absence de point virgule en fin de ligne. Ça rend le code beaucoup moins chargé, on peut se concentrer sur l'essentiel plutôt que d'avoir à filtrer mentalement tous les caractères superflus.
Je ne vois pas du tout quel est le problème avec la précédence tes opérateurs? Elle me semble parfaitement saine et classique:
Après, je n'ai pas essayé de coder en Go, peut-être ai-je loupé quelque chose?
[^] # Re: Quel avenir?
Posté par rewind (Mastodon) . Évalué à 3.
Un petit exemple :
n'est pas égal en Go (mais égal en C) à
parce qu'en C,
|et+ont une précédence différente en C, alors qu'en Go, c'est la même. Que+et-ait une précédence identique, ça se comprend tout à fait. Mais là, c'est mis au même niveau que d'autres opérateurs qui n'ont strictement rien à voir et qui ne devrait pas avoir la même précédence.[^] # Re: Quel avenir?
Posté par reno . Évalué à 10.
Personnellement je déteste ces précédences stupides (je parle du C ET de Go): les seules précédences qui ont un sens c'est celle qu'on a appris en math (+ - * /),
le reste ça devrait échouer a la compilation pour forcer a mettre des parenthèses!
3 | 2 + 1 --> erreur de compilation: le programmeur doit mettre '(3 | 2) + 1' ou '3 | (2 + 1)'.
[^] # Re: Quel avenir?
Posté par neil . Évalué à 4.
En logique (qui est une branche des maths) il y a aussi des opérateurs, et ils ont aussi une précédence, qui est la même qu'en C et en Go pour le ET et le OU par exemple, si on les considèrent comme && et ||.
[^] # Re: Quel avenir?
Posté par daimrod . Évalué à 0.
Oui mais on parle ici de précédence entre des opérateurs logiques et des opérateurs arithmétiques. Autant mettre de parenthèses ça évite de retenir des règles pas vraiment utiles et souvent différentes entre les langages.
[^] # Re: Quel avenir?
Posté par ckyl . Évalué à 8.
Je te suis complètement la dessus. Je mets toujours les parenthèses même quand elles pourraient être absentes. Du code c'est fait pour être lu et pour être facile à débugger. C'est tellement plus rapide de comprendre une ligne quand le découpage est déjà fait, et ça évite les bugs cons en forçant le développeur à expliciter ce qu'il a en tête.
Bref c'est pas par ce qu'on peut s'en passer qu'il faut s'en passer. Du coup les règles de précédence on s'en tape un peu non ?
[^] # Re: Quel avenir?
Posté par reno . Évalué à 2.
Si tous le monde respectait ces règles oui..
Mais alors dans ce cas pourquoi ne pas avoir un langage qui force a respecter ces regles?
[^] # Re: Quel avenir?
Posté par rewind (Mastodon) . Évalué à 3.
Sauf que tu oublies une précédence que tu utilises sans t'en rendre compte, celle de l'affectation
=, car oui,=est un opérateur en C et dans la plupart de ses descendants, avec une précédence qui lui permet d'être exécuté en dernier. Donc, si je suis ton raisonnement, on devrait par exemple écrire :Mais personne ne le fait, parce que ça semble naturel à tout le monde que
=est en haut de l'arbre d'expression. Donc, pour moi, c'est la même chose avec le reste, il y a des ordres naturels. Si par exemple j'écris l'expression suivante :Tout le monde va la parenthéser de la même manière, à savoir :
Et honnêtement, je préfère la première version à celle-ci. Surtout quand dans le même temps, certains font l'apologie de l'absence de parenthèses après le
if.Le seul problème de précédence en C (connu depuis très longtemps) est la précédence de
&et|, qui était utilisé pour&&et||avant que ces derniers n'apparaissent dans le langage, et qui du coup, ont gardé leur précédence. Ce qui pose problème de nos jours parce qu'on aimerait écrire :Mais on ne peut pas, on est obligé de parenthéser l'expression à gauche du
==. Cette erreur n'a jamais été corrigée dans les langages qui descendent du C, comme Java ou PHP.[^] # Re: Quel avenir?
Posté par lendemain . Évalué à 4.
entre
2 + 3 * 4 < 10 && 3 >= 3 / 3 - 4 || 5 % 3 == 3
et
(((2 + (3 * 4)) < 10) && ((3 >= (3 / 3) - 4) || ((5 % 3) == 3)))
je préfère
((2 + 3 * 4) < 10) && ((3 >= (3 / 3 - 4)) || (5 % 3 == 3))
[^] # Re: Quel avenir?
Posté par Dr BG . Évalué à 2.
Tu as oublié un groupe de parenthèses à la fin : (5 % 3) == 3
[^] # Re: Quel avenir?
Posté par drakmaniso . Évalué à 5.
Le problème c'est que lorsqu'il y a des règles de précédences plus complexes que celles de Go, d'après mon expérience chaque programmeur en retient une partie différente, et relire le code d'autrui peut devenir problématique.
Je me suis souvent retrouvé à rajouter des parenthèses que je savais inutiles dans mon code, parce que je savais que telle ou telle précédence n'est généralement pas connue (l’opérateur ternaire me vient à l'esprit, notamment).
Si tu connais par cœur l'ensemble des règles de précédence de C, alors crois-moi, tu es une exception. Je préfère de très loin avoir des règles moins fournies mais faciles à retenir.
[^] # Re: Quel avenir?
Posté par Jux (site web personnel) . Évalué à 7.
Les identifiants unicode ça ouvre un tout nouveau monde d'obfuscation de code. On va pouvoir faire le "International Go Obfuscated Code Contest".
[^] # Re: Quel avenir?
Posté par claudex . Évalué à 10.
Pour moi, l'intérêt de l'optionnalité c'est de ne pas les utliser normalement mais de pouvoir quand même mettre plusieurs instructions sur une ligne (ce n'est pas toujours utile mais parfois ça présent mieux).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quel avenir?
Posté par Moonz . Évalué à 3.
Même choix que Ruby, Lua, Python, CoffeeScript. À ton avis, pourquoi tous ces langages ont fait ce choix ?
Ça permet de clarifier grandement
char *foo[3](tableau de 3 char* ou pointeur sur un tableau de 3 char ?).[^] # Re: Quel avenir?
Posté par rewind (Mastodon) . Évalué à 2.
Il y a des
gotoen C, PHP, Go, etc, ce n'est pas pour ça que l'idée est brillante hein.Je ne dis pas que ce sont des abrutis, je comprend parfaitement la raison, mais, pour moi, c'est une erreur, ça complexifie le langage inutilement. Et d'ailleurs, dans la spec de Go, ils précisent bien qu'aucun exemple dans la spec n'utilisera de
;, que c'est plus "idiomatique", autre manière de dire que normalement, ça sert à rien. Donc ça ne sert à rien mais on le met quand même…[^] # Re: Quel avenir?
Posté par claudex . Évalué à 2.
Dans java, la convention, c'est les noms de classes débutant par une majuscule, tu ne trouveras aucun exemple dans la doc avec un nom de classe en minuscule. Donc, les noms de classes entièrement en majuscules ne servent à rien mais on les met quand même. Et ça ne choque pas plus que ça. Si quelqu'un veut coder avec des noms de variables débutants par une majuscules et des noms de classes débutant par une minuscule, c'est son problème, ce n'est pas au langage de l'en empêcher.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quel avenir?
Posté par Dr BG . Évalué à 2.
Mouais enfin c'est très différent : ce n'est qu'une convention qui n'a rien à voir avec la grammaire du langage, tout comme l'indentation du code. Je préfère la justification disant que ça permet tout de même d'écrire plusieurs instructions sur la même ligne si on en a envie.
[^] # Re: Quel avenir?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
c'est vrai qu'un truc comme ça :
ça fait super envie :D
[^] # Re: Quel avenir?
Posté par reno . Évalué à 8.
C'est moche mais ça se lit très bien: un pointeur vers un tableau de 4 entiers.
Beaucoup plus simple a comprendre que la version en C!
[^] # Re: Quel avenir?
Posté par Octabrain . Évalué à 1.
En français oui, on lit dans cet ordre, "pointeur vers un tableau de 4 entiers". Il n'y aurait pas d'autres langues où ça se lirait à l'envers ? (un peu comme le possessif "'s" en anglais qui est à l'inverse du français)
[^] # Re: Quel avenir?
Posté par reno . Évalué à 2.
Le possessif n'est pas obligatoire en Anglais: a pointer to an array of 4 int.
Il y a probablement des langues où ce n'est pas le bon ordre, mais l'Anglais est la langue de l'informatique..
[^] # Re: Quel avenir?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 0.
Faudrait moinsser aussi le commentaire qui répond à mon commentaire, sinon c'est pas crédible et on ne comprend plus rien.
Ceci dit avec deux commentaires moinsés sur 2, on dirait que le fait que je n'aime pas trop Go soit mal vu… Ca doit être parce que c'est vendredi ;)
[^] # Re: Quel avenir?
Posté par reno . Évalué à 1.
Bof, tu ne peux toujours pas supposer que 'x Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul".
[^] # Deuxième essai
Posté par reno . Évalué à 2.
Bof, tu ne peux toujours pas supposer que x est inférieur à x + 1 est vrai, ni que abs(x) retourne un entier positif (enfin je pense, je n'ai pas trouvé la version pour un entier).
Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul"!
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# En même temps...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à -1.
C'est sûr que côté avenir, à en croire les deux index, Tiobe et lang-index que je consulte régulièrement, ça va être tranquille.
Bon, on pourra me dire que c'est comme les sondages en période électorale, ça vaut pas grand chose :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.