- 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 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.
Aller plus loin
- L'annonce de Go sur LWN (avec des commentaires intéressants) (23 clics)
- Un article consacré à Go sur Astechnica (26 clics)
- Heise Online parle aussi de Go (12 clics)
- Go sur Wikipedia (déjà !) (264 clics)
- L'annonce sur le blog de Google (10 clics)
- Site officiel du nouveau langage (61 clics)
# un clone de Vala ?
Posté par Loic Dreux . Évalué à 2.
[^] # Re: un clone de Vala ?
Posté par creak (site web personnel) . Évalué à -6.
Là on parle de "vrai" langage.
[^] # Re: un clone de Vala ?
Posté par lolop (site web personnel) . Évalué à 10.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: un clone de Vala ?
Posté par Clément David (site web personnel) . Évalué à -8.
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 Marc (site web personnel) . Évalué à 7.
[^] # Re: un clone de Vala ?
Posté par neologix . Évalué à 3.
[^] # Re: un clone de Vala ?
Posté par jcr83 . Évalué à 4.
# Le Monde en parle
Posté par Boa Treize (site web personnel) . Évalué à 6.
« 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(...)
[^] # Re: Le Monde en parle
Posté par ribwund . Évalué à 2.
http://www.eweek.com/c/a/Application-Development/Survey-Pyth(...)
# système et garbage collector?
Posté par creak (site web personnel) . Évalué à 4.
[^] # Re: système et garbage collector?
Posté par ribwund . Évalué à 2.
[^] # Re: système et garbage collector?
Posté par zerkman (site web personnel) . Évalué à 7.
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 ribwund . Évalué à 4.
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 LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: système et garbage collector?
Posté par psychoslave__ (site web personnel) . Évalué à 6.
[^] # Re: système et garbage collector?
Posté par darkleon (site web personnel) . Évalué à 1.
"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 Bungee Tux . Évalué à 1.
[^] # Re: système et garbage collector?
Posté par Dr BG . Évalué à 2.
Baladeur est un peu plus qu'une traduction de walkman puisque ce dernier est une marque déposée par Sony :-)
[^] # Re: système et garbage collector?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Comme quoi, je pense qu'il faut laisser du temps au temps pour que le concept derrière un mot trouve sa signification.
[^] # Re: système et garbage collector?
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: système et garbage collector?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: système et garbage collector?
Posté par windu.2b . Évalué à 4.
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 Sylvain Sauvage . Évalué à 4.
— 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 Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: système et garbage collector?
Posté par Sylvain Sauvage . Évalué à 8.
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 Dr BG . Évalué à 8.
rationnelles :-)
[^] # Re: système et garbage collector?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 goeb . Évalué à 3.
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 Philippe F (site web personnel) . Évalué à 7.
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 jseb . Évalué à 5.
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(...)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: système et garbage collector?
Posté par Antoine . Évalué à 6.
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 creak (site web personnel) . Évalué à 2.
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 hsyl20 (site web personnel) . Évalué à 1.
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 lasher . Évalué à 2.
# Première remarques
Posté par beagf (site web personnel) . Évalué à 10.
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 case42 (site web personnel) . Évalué à 6.
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 Loic Dreux . Évalué à -10.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . Évalué à 2.
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 Thomas Douillard . Évalué à 6.
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 beagf (site web personnel) . Évalué à -1.
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 Philippe F (site web personnel) . Évalué à 8.
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 beagf (site web personnel) . Évalué à 3.
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 CrEv (site web personnel) . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 CrEv (site web personnel) . Évalué à 1.
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 Philippe F (site web personnel) . Évalué à 7.
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 barmic . Évalué à 3.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Première remarques
Posté par Antoine . Évalué à 3.
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 beagf (site web personnel) . Évalué à 3.
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 Philippe F (site web personnel) . Évalué à 2.
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 barmic . Évalué à 1.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Première remarques
Posté par Moonz . Évalué à 4.
[^] # Re: Première remarques
Posté par barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Première remarques
Posté par Antoine . Évalué à 1.
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 Sylvain Sauvage . Évalué à 2.
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 Moonz . Évalué à 2.
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 ribwund . Évalué à 3.
http://docs.python.org/reference/datamodel.html?highlight=re(...)
[^] # Re: Première remarques
Posté par Sebastien . Évalué à 2.
[^] # Re: Première remarquesn
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Première remarques
Posté par Sebastien . Évalué à 0.
[^] # Re: Première remarques
Posté par Gof (site web personnel) . Évalué à 4.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Première remarques
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
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 beagf (site web personnel) . Évalué à 2.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . Évalué à 2.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . Évalué à 2.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
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 beagf (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 3.
Dans ce cas-là, pourquoi s'enthousiasmer pour Go alors que ocaml existe ?
[^] # Re: Première remarques
Posté par Xavier FACQ . Évalué à 2.
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 ribwund . Évalué à 2.
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 gentildemon . Évalué à 8.
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 Philip Marlowe . É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 CrEv (site web personnel) . Évalué à 3.
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 Philip Marlowe . Évalué à 2.
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 Pierre Jarillon (site web personnel) . Évalué à 3.
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 CrEv (site web personnel) . Évalué à 3.
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 Troy McClure (site web personnel) . Évalué à 10.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 Ummon . Évalué à 2.
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 Misc (site web personnel) . Évalué à 7.
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 Boa Treize (site web personnel) . Évalué à 4.
# hmmm Android...
Posté par case42 (site web personnel) . Évalué à 5.
# Python et Google
Posté par neologix . Évalué à 4.
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 Philippe F (site web personnel) . Évalué à 6.
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 psychoslave__ (site web personnel) . Évalué à 5.
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 Philippe F (site web personnel) . Évalué à 0.
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 Antoine . Évalué à 5.
??? 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 snt . Évalué à 5.
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 Yusei (Mastodon) . Évalué à 8.
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 Ontologia (site web personnel) . Évalué à 9.
...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 nomorsad . Évalué à 2.
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 Thomas Douillard . Évalué à 5.
[^] # Re: Typage statique/dynamique
Posté par feth . Évalué à 1.
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 Boa Treize (site web personnel) . Évalué à 5.
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 desfrenes (site web personnel) . Évalué à 3.
[^] # Re: Typage statique/dynamique
Posté par Jul (site web personnel) . Évalué à 2.
use strict;
my $date;
$datte="oops";
erreur :)
[^] # Re: Typage statique/dynamique
Posté par Philippe F (site web personnel) . Évalué à 5.
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 wilk . Évalué à 1.
[^] # Re: Typage statique/dynamique
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Typage statique/dynamique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Typage statique/dynamique
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Typage statique/dynamique
Posté par Albert_ . Évalué à 2.
[^] # Re: Typage statique/dynamique
Posté par Chaddaï Fouché . Évalué à 3.
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 creak (site web personnel) . Évalué à 4.
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 Boa Treize (site web personnel) . Évalué à 4.
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 Francois Revol (site web personnel) . Évalué à 6.
le patch courrant :
http://revolf.free.fr/beos/patches/golang-haiku-002.diff
[^] # Re: Portage Haiku
Posté par benja . Évalué à 0.
# Rapidité de compilation
Posté par Philippe Martin . Évalué à 0.
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 Larry Cow . Évalué à 5.
Non?
[^] # Re: Rapidité de compilation
Posté par Boa Treize (site web personnel) . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.