Reprise du message précédent :
Bouquin que j'avais indiqué 6 posts plus haut  
A+,

Oups  

http://channel9.msdn.com/Events/La [...] tures-of-D
http://channel9.msdn.com/Events/La [...] g-Language
http://www.infoq.com/presentations [...] re-Using-D
 
Pour quelques speachs sur D.

Merci deadalnix, je suis de près tes interventions sur la mailing-list.

Phrase lue dans la m-l:
"I don't trust computers, I've spent too long programming to think that
they can get anything right."

quid de l'embarqué OS-less ? au début je trouvais que le D pouvait être une bonne alternative au C/C++ mais j'ai l'impression que le runtime nécessaire pour faire tourner du D est beaucoup trop complexe.

 
bug interface chaise-clavier hépicétou.

Si tu veux faire de l'embarqué, en D, ça risque d'être assez chaud, je pense (enfin de l'embarqué au sens industriel, pas au sens Android & co, où on développe déjà en Java). C'est en théorie possible, mais en pratique, c'est pas trop prévu pour, en tout cas pas pour les applis avec de grosses limitations mémoire.

 
D en lui même en est capable, mais en effet, le runtime ainsi que phobos ne sont pas prêts pour cela. C'est dommage, et il y a du taff fait dans ce sens, mais à l'heure actuelle, ce n'est clairement pas au niveau. Ceci dit, je sais qu'une alternative a Druntime a été faite pour cela, mais je ne suis pas très au fait de ce projet.
 
Pour l'embarqué dans le sens android/iPhone, GDC sait compiler vers ARM, et il est aujourd'hui possible de le faire. Cependant, c'est encore assez neuf et funky.

La version 2.059 avec UFCS est releasée.
A+,

Par contre, vaut mieux pas upgrader, il y a des régressions importantes.

Coup de bol que tu le signales, j'allais le faire  
A+,

Ouais, ça ça compile plus en 2.059, par exemple:

 
En tout cas, le gagnant des qualifs du Google CodeJam, il ne devait pas avoir la 2.059, heureusement pour lui.

trop d'espaces tue l'espace

 
Yep, mes patch pour SDC ne compilent plus. 2.059 est pas la plus grande release qui soit.

Sinon : http://channel9.msdn.com/Blogs/Cha [...] -much-more

Le truc dingue, c'est qu'avec les toutes dernières nouveautés, c'est avec l'une de ces vidéos que j'ai découvert la toute nouvelle syntaxe des lambda expressions.
 
Ca devient méchamment fonctionnel, là.

Ça date de janvier si je me souvient bien cette syntaxe. Et oui, il y a une volonté d'introduire du fonctionnel dans D. C'est un paradigme qui répond bien aux problématiques de scallabilité et de programmation concurrente, ce qui a pris un grande importance récemment avec les multicores.

Après un grand creux vers 2008-2009, on sent qu'il y a à nouveau un vent porteur, notamment depuis fin 2011.
Les stats de la mailing list:

D.d

D.learn

D.gnu

D.announce

J'ai renommé le topic au vu des évolutions du langage. Bien que j'aurais pu l'appeler C++ + Java + Python + bugs = D

C'est quoi le coté Java ?

Le GC, l'héritage simple, la syntaxe un peu plus propre que celle de C++, les modules, la concurrence. Mais c'est vrai que C++ + Python résume à peu près aussi bien D.

 
Non.
 
La différence struct/class qui existe en D est plus proche de C# que de python ou java. Sinon aucun de ces deux langage n'est fonctionnel, donc on oublie un gros pendant de D. Quand à la concurrence, D apporte des réponse bien supérieures à ce qui se fait en Java. On retrouve des idées qui viennent de PERL par exemple. Viennent ensuite les contrats, et la, sans aucun doute, EIFFEL est la source d'inspiration.
 
Pour les bugs, malheureusement, il y a du travail . Mais D est déjà utilisé dans des projets commerciaux, et avec les binding pour thrift, Facebook envisage de se mettre à l'utiliser (il faut dire que Facebook emploie Alexadrescu). DMD est un vrai sac de noeuds.
 
PS: Ça serait bien de remonter les confs dans les premiers posts, et si quelqu'un connais bien Go, ça le ferait bien un TOPO Go vs D, qui sont pour moi les deux langages avec de l'avenir dans le natif (malheureusement, je ne suis pas assez calé en Go pour le faire).

Go, personne ne l'utilise ou presque, au vu du classement du dernier Google Code Jam.
A+,

Go était depusi le debut un evaste fumisterie intellectuelle de toute façon.
 
Y a t il du travail pour un frontend D pour LLVM ?

D non plus, à ce compte-la

15 personne sur plus de 18 000, peut mieux faire (même si encore une fois, le numéro 1 aux qualifs utilise D)

JoelF > il existe: LDC. Jamais essayé par contre, deadalnix en sait probablement plus la-dessus. Mais du taf pour stabiliser l'ensemble, oui y'en a !

Parce que le frontend est celui de DMD, or le compilo DMD et la lib Phobos sont littéralement criblés de bugs. J'en recense au moins 700 qui sont valides. Rien que stabiliser la lib Phobos ou tout au moins la débugger peut être un bon moyen de se familiariser avec le langage.

Tu as SDC
 
Par contre si tu connais une bonne doc d'utilisation pratique de LLVM, je suis preneur, parce que celle de leur site est un peu faiblarde.
 
A+,

 
Youtube utilise Go. Ce n'est pas assez gros ?

 
Il existe LDC. Il est tout à fait utilisable, et supporte certaines fonction que DMD ne supporte pas (les DSO sous linux par exemple). Une bonne partie du code du frontend est partagé avec DMD, donc beaucoup de bugs sont partagés. Le binaire généré est souvent bien meilleur que celui de DMD, et l'ABI du C est mieux respectée (amuser à linker avec du C en utilisant des structs sur une machine 64bits avec DMD pour voir ce dont je parles).
 
Sinon SDC sur lequel j'ai travaillé ces derniers temps est une implémentation d'un front end LLVM en D pour D. Je suis en train de refactorer le parser et l'AST afin de pouvoir l'utiliser dans des outils autres qu'un compilo, ce qui est impossible avec le frontend actuel (static code analysis, IDE tools, code formatter, etc . . .). Mais ce compilo est encore à un stade ou il ne compile que des programme vraiment triviaux et passablement inutiles.

Pour le Go, le (seul?) bouquin de référence que j'ai, c'est The Way to Go - A Thorough Introduction to the Go Programming Language de Ivo Balbaert publié en 2012 chez iUniverse, et qui fait pas loin de 600pp.
Il existe aussi en allemand le livre Systemprogrammierung in Google Go: Grundlagen, Skalierbarkeit, Performanz, Sicherheit de Frank Müller publié en 2011 chez dpunkt.verlag et qui fait dans les 300pp.
A+,

Je viens de lire "The way to Go" attentivement (j'en avais un exemplaire 'electronique' :whistle: ).
Le bouquin a été édité à l'arrache, car il y figure (dans le texte) des fautes de frappe qu'une relecture attentive aurait du déceler, et le code donné en exemple n'est pas non plus exempt d'erreurs hélas.
Une vaste fumisterie intellectuelle, je ne sais pas, mais en tout cas, son implémentation des notions orientées objet (classes [comme structs] et methodes) donne l'impression d'avoir été conçu par Will Coyote, tellement c'est fait à la colle et aux rustines.
Les idées intéressantes dans le langage sont
1- les fonctions retournant une liste de valeur (de type hétérogène) et non pas une seule valeur. Ça peut éviter d'avoir des paramètres out passés à des fonctions juste pour la valeur de retour
2- la variable prédéfinie _ qui est write-only  
3- les goroutines (si leur implémentation est efficace) qui sont en fait des coroutines, et leur communication par channel à priori bloquant
Bon, il n'y a rien de vraiment innovant la dedans néanmoins, mais un langage compilé combinant tout cela, pourquoi pas.
MAIS
la syntaxe du langage est bourrée de conventions inhabituelles (types déclarés après la variable, valeur de retour après la liste des paramètres, etc) ou de choix qui se révèlent peu judicieux (pas de ; nécessaire en fin de ligne, mais ça a pour effet de bord qu'il faut obligatoirement mettre les accolades ouvrantes de blocs if et for en fin de ligne pour que le compilo n'y mette pas automatiquement un ;) ou désastreux (pas de parenthèsage obligatoire des conditions des if et for, ce qui aboutit a des choses potentiellement génératrices d'erreurs).
Bref, c'est pas un langage élégant du tout, en particulier dans sa partie "orientée objet", et je me vois mal le recommander à quiconque.
 
A+,

Les types déclarés après la variable, valeur de retour après la liste des paramètres, c'est le cas de Pascal, si mes souvenirs me trahissent pas. Pour le reste, Go n'est pas un langage très intéressant à mon avis. Il l'était quand la cible était de faire un C amélioré, mais le langage s'est complètement éloigné de ce but-la.

Oui, mais la syntaxe pascale était plus claire:
a, b: Type;
 
Alors qu'en go, tu aboutis à
a, b Type;
 
et que tu peux aboutir à
a, b Type1, c, d Type2;
qui est loin d'être un modèle de clarté
 
Autre problème:
La notation des pointeurs, elle est certes plus lisible, mais introduit de l'incohérence:
a *[3]int
c'est certes lisible linéairement a est un pointeur (*) sur un tableau de 3 ([3]) entiers (int)
mais si j'ai une fonction:
func fp(a *[3]int) { ... }
je vais avoir un appel avec une notation & en place du *
fp(&[3]int{i, j, k})
Il aurait mieux valu pour plus de cohérence faire une déclaration de pointeur comme
a &[3]int
 
A+,

 
Tu as ça en D avec les tuples. Nul doute cependant que la syntaxe doit être simplifiée dans le futur.
 

 
C'est exactement ce qui m'a rebuté dans Go.
 
Sinon :
http://vibed.org/ <= un framework web en D qui a l'air d'envoyé du lourd.
http://www.altdevblogaday.com/2012 [...] ming-in-c/ Carmack sur la programmation fonctionnelle en C++, avec un passage sur D, et mon commentaire : http://www.altdevblogaday.com/2012 [...] -511625398

Oui, c'est une des zones ou le D pourrait s'inspirer du Perl.
 

Ce serait bien qu'on ait enfin des applis exploitant la puissance du D comme il faut.
Sinon, j'avais lu le lien sur Carmack suite au post dans blabla@prog, mais pas les commentaires.
 

Moi aussi.
 
A+,

je veux un D embdedded    
 
 

Avec une spec erronée, ça commence déjà mal...
A+,

C'est p-ê possible si on crée une lib minimaliste qui n'utilise pas le GC. Ca limiterait certaines features du langage, par contre, je ne sais pas bien lesquelles. Apparemment, les array slices ont besoin du GC.
Malgré les limitations, je pense que ça vaudrait quand même le coup.
Quand Kenta Cho faisait ses shoot'em ups en D1, il avait fait ce choix, et ça marchait bien.

Jonathan Mercier, c'est bioinformatics sur le newsgroup. Faudra lui dire un jour que "Dear" tout seul, ça ne veut rien dire.

 
Oui, ça limiterait aussi aux closures de sortir de leur scope.
 

 
Le truc est encore en beta, mais au niveau performances, ça envoie déjà du TRÈS lourd.

http://forum.dlang.org/post/jncc7h [...] almars.com

Ca veut dire quoi une API bloquante ?
En tout cas, si ce serveur Web est aussi performant qu'il le dit, cela confirme que D est un langage idéal pour les applis serveur. On a déjà l'interface web des newsgroups qui est une belle démonstration de rapidité (surtout que le serveur est partagé). Avant les jeux, je pense que c'est dans ce créneau que D peut s'imposer le plus facilement. Là où Java règne, D peut faire la même chose, en plus rapide, et avec une utilisation plus modérée de la mémoire.

Je pense que c'est à ceci que cela se réfère:

sur le modèle, comme le postait quelqu'un sur reddit

(bon, il y a surement aussi pas mal de diffs)
A+,