Discussion :

[Invité]

Oui on était en train de dire que le language D était plus productif que C++, plus facile à apprendre, et permet des choses que C++ ne pourra probablement jamais.

YouTube- Eclipse Descent Compile-Time Debug

Ah oui et j'oubliais : un projet de 10000 lignes compile en 3 secondes.

Bref :

• d'un point de vue langage, D gagne haut la main
• d'un point de vue environnement, il perd haut la main

[deadalnix]

Sous code::block, l'intégration est relativement bien foutue.

[Niark13]

Oui on était en train de dire que le language D était plus productif que C++, plus facile à apprendre, et permet des choses que C++ ne pourra probablement jamais.

Qu'un langage de la fin des années 2000 ait des avantages sur un autre lancé 25 ans plus tôt est normal. D'abord parce que la technique a progressé et d'autre part parce que D bénéficie du recul apporté par C++. Si Walter Bright et Andrei Alexandrescu, qui sont des experts dans leur domaine, n'avaient pas été en mesure de faire mieux, on aurait pu se poser des questions.

Mais pour que D décolle, il faudra :

• Que ses qualités soit suffisantes pour contre-balancer le poids de l'existant, puisqu'il est incompatible avec C++.
• Qu'il réponde à un besoin que les autres langages ne parviennent pas à satisfaire correctement.

À mon avis, le langage risque de décoller si C++ rencontre des difficultés à évoluer. Il me semble que le comité de normalisation de C++ 0x a du faire des concessions sur les fonctionnalités qu'ils souhaitaient voir intégrées au standard initailement : Garbage-Collector, Concepts, modules...
D2 est conçu avec le multithread facile comme objectif, c'est bien. S'ils peuvent répondre à des besoins que C++ 0x aura eu du mal à satisfaire, il y aura là une belle opportunité pour le langage...

Le soutien d'une ou plusieurs multinationales serait bien aussi.

[Klaim]

Ce que je ne comprends pas c'est comment se fait-il qu'ils aient tant de mal à faire des spécifications précises niveau compilateur alors que visiblement c'est quand même des concepteurs super expérimentés?
Ou alors ce n'est plus le cas avec D2?

[Invité]

Je ne sais pas si ce qui se passe dans le front-end D est bien compris par beaucoup de gens tout simplement.

Ce qui est dur, (à mon avis), c'est que bien que le D soit facile à parser, la phase d'analyse sémantique qui suit est complexe, à cause des intéractions entre expansion de templates, CTFE et string mixins (qui sont un peu comme des macros C qui interviendraient après le parsing).

Ces concepts sont récursifs à la compilation:
un string mixin peut utiliser une fonction à la compilation (CTFE) pour créer un nouveau template qui lui même... à un moment, le compilateur dit non mais ce n'est pas bien documenté.

C'est pourquoi le front-end officiel sert de référence pour le langage (un peu comme Python, Perl, et Ruby). Ce n'est pas si gênant vu qu'il est sous une licence libre, mais c'est gênant quand même.

Le livre "the D programming language" devrait notamment contribuer à coucher sur le papier tout ca, d'ailleurs Alexandrescu a largement contribué à assainir le language et éliminer les zones d'ombres.

[deadalnix]

Mais pour que D décolle, il faudra :

• Que ses qualités soit suffisantes pour contre-balancer le poids de l'existant, puisqu'il est incompatible avec C++.
• Qu'il réponde à un besoin que les autres langages ne parviennent pas à satisfaire correctement.

Tu oublies un paramètre tout bête : la popularité.

Pour ce qui est du point 2, il est remplis sans aucun doute. Pour ce qui est du point 1, le poids de l'existant en C++ est tellement lourd que le seul salut à mon avis sera de pouvoir linker du C++ avec du D.

Des mots clefs sont réservés dans le langage pour le faire, mais rien n'est ne place de ce coté la pour l'instant (ni au niveau pratique, ni même au niveau specs).

[spidermario]

Pour ma part, je pense que je me mettrai au D lorsque la version 2 sera la version considérée comme stable.

[deadalnix]

D2 promet en effet des choses sympa. Particulièrement pour le multithreading.

[spidermario]

Mais pas seulement. Il y aura aussi l'introduction du mot-clé "pure" pour indiquer qu'une fonction est pure et n'appelle que des fonctions pures, de réelles fermetures, la compatibilité binaire entre Tango et Phobos...

[deadalnix]

Pour le coup du pure, je ne vois pas bien ce que ça apporte. C'est de toute façon déductible par le compilo si une fonction est pure ou non.

Pour ce qui est de la compatibilité phobos et tango, ce n'est aps une avancé, c'est juste la résolution des merdes de D1.

Mais en effet, phobos 2 promet des choses intéressantes, et il y a d'autres trucs que j'attends avec impatience.

[Florian Goo]

Il y aura aussi l'introduction du mot-clé "pure" pour indiquer qu'une fonction est pure et n'appelle que des fonctions pures

Ah ça par contre j'adorerais le voir en C++.
« pure » c'est un peu comme « const », c'est une garantie. En l'occurrence on a la garantie que la fonction est proprement écrite et qu'elle est bien moins source à bugs.
C'est une fonctionnalité que j'envie des langages fonctionnels.

[screetch]

Pour le coup du pure, je ne vois pas bien ce que ça apporte. C'est de toute façon déductible par le compilo si une fonction est pure ou non.

Pour ce qui est de la compatibilité phobos et tango, ce n'est aps une avancé, c'est juste la résolution des merdes de D1.

Mais en effet, phobos 2 promet des choses intéressantes, et il y a d'autres trucs que j'attends avec impatience.

c'est pas deductible car une fonction peut etre pure si elle appelle des fonctions qui sont egalement pure, ce que le compilo ne peut pas verifier

[deadalnix]

Et pourquoi donc ne pourrait-il pas vérifier ça ?

[screetch]

parce que le compilateur n'est pas un linker.

[SpiceGuid]

C'est de toute façon déductible par le compilo si une fonction est pure ou non.

Parfois le compilo voit comme impures des modifications qui en fait sont pures.
C'est le cas par exemple des changements de représentation, du genre passage de coordonnées cartésiennes en coordonnées polaires. La POO offre plein d'opportunités de changer d'implantation ou de comportement superficiel sans toucher à la valeur abstraite. D'où le mot clé pure, qui est inspiré de Eiffel je crois, comme beaucoup de choses en D.

[Florian Goo]

Plus simplement, c'est impossible à cause des fonctions virtuelles…

[screetch]

je ne suis pas sur que ca soit plus simple mais oui c'est un bon exemple

[deadalnix]

parce que le compilateur n'est pas un linker.

Ok, je parlait des deux dans mon message. Il n'y a de toute façon aucun raison pour que cela ne soit pas détectable lors du processus complet de transformation du source en exécutable.

SpiceGuid > Oui, en effet, l'appel de fonction comme cos est un bon exemple. Ceci dit, on risque de toute façon de se retrouver ici avec un message du genre « Votre fonction pure appelle une fonction impure, corrigez moi ça grand escogriffe ! ».

Est-ce qu'un pragma sur la définition de ces fonction n'aurait pas été amplement suffisant ?

J'ai comme l'impression qu'on va se retrouver comme avec le const du C++ avec ces histoires de fonction impures. Le truc super envahissant qu'on colle partout, alors que le couple compilo/linker devrait être capable de repérer ça de lui-même.

Florian Goo > Je ne suis pas sur de comprendre ce à quoi tu réponds. Mais rien d'impossible ici.

[Florian Goo]

Florian Goo > Je ne suis pas sur de comprendre ce à quoi tu réponds. Mais rien d'impossible ici.

Si tu as une fonction contenant un appel vers une fonction membre virtuelle, tu ne peux pas savoir à la compilation quelle sera la fonction effectivement appelée, donc tu ne peux pas savoir si la fonction appelée sera pure ou non.
Conséquence : impossible de déterminer si une fonction qui appelle une fonction virtuelle est pure ou non.

Il y a aussi le problème des fonctions de bibliothèque dont le compilateur ne peut accéder à la définition. Là encore, comment déterminer si une fonction contenant un appel à une fonction de bibliothèque est pure ou non, si ce n'est en ayant l'information dans la signature de la fonction ?

« const » n'est pas une lourdeur syntaxique qu'on aimerait déléguer au compilateur comme la numérotation des lignes qui était manuelle dans les premiers langages de programmation. C'est une fonctionnalité qui est là pour aider le développeur.
Tu peux très bien coder en C++ sans utiliser « const », comme c'est le cas en Java, si tu trouves qu'il est pratique d'envoyer un objet à une fonction sans savoir si celle-ci pourra le modifier…
C'est pareil pour « pure ».

Enfin, il n'y a pas de couple « compiler/linker » comme tu l'entends. Il est suffisamment difficile d'écrire proprement l'un et l'autre indépendamment. Si en plus ils sont mutuellement dépendants, non seulement la chaine de compilation sera un bloatware, mais en plus elle sera affreusement lente.

[deadalnix]

Ces choses sont déjà faites en java par exemple. Le compilo JIT est capable de savoir si une fonction membre est surchargée ou non et de l'appeler virtuellement ou statiquement. D prévoit aussi de gérer cela à la compilation (c'est d'ailleurs plus facile qu'en java, puisque D ne supporte pas le chargement dynamique de code).

Le problème de la fonction pure est le même. Tout comme pour savoir si l'appel est virtuel ou non, il faut savoir si les fonction possiblement appelées sont toutes pures ou non.

Par contre, ça nécessite d'avoir un (en fait 2 : pure, et pure sous réserve d'appels pure seulement) tag dans la fonction placé par le compilateur que le linkeur saura lire. Et ça marche aussi avec les bibliothèques.