La liste des langages-que-je-voudrais-bien-apprendre-mais-j’aurai-jamais-le-temps-avant-la retraite était déjà longue[1] :
Perl (au moins ai-je fait quelques petits exercices il y a quelques années, mais de là à tutoyer le CPAN…) ;
Python (Mise à jour : ah depuis, j’ai pu commencer !) ;
Ruby (apparemment très élégant) ;
Java (survolé un bon livre d’initiation, mais jamais pratiqué, et la verbosité et le mécanisme de gestion des erreurs me font peur) ;
Objective C (le livre était bon mais il m’a fallu un an pour arriver au bout, et si l’élégance et la compacité me séduisent, impossible de commencer à mettre en pratique, surtout que le langage n’est réellement utilisé que sur Mac...)
...
Il manque un langage fonctionnel là-dedans, ou le Lisp, qui paraît-il offre une toute autre perspective sur la programmation.
Et ce n’est pas professionnellement que ça va s’arranger : si le PL/SQL était robuste et assez bien conçu (inspiré du Pascal), il ne sert pas à grand-chose d’autre qu’à tirer tout le jus d’Oracle, et j’ai vidé ici ma bile sur l’ABAP, de toute façon propre à SAP. L’avenir immédiat s’annonce d’ailleurs plus orienté vers des outils de matraquage de bases de données à base de cliquodrome.
Et puis arrive ce D.
Le promoteur est Digitalmars, un éditeur de compilateurs C et C++, suite à la pertinente réflexion suivante :
“It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe it’s time for a new language born out of practical experience implementing compilers.”
« Il me semble que la plupart des “nouveaux”langages tombent dans une de deux catégories : ceux du monde académique avec des paradigmes radicalement différents, et ceux des grandes entreprises avec un accent mis sur les outils RAD et le web. Peut-être le temps est-il venu pour un langage né d’une expérience pratique dans l’implémentation de compilateurs. »
— Michael
La version 1.0 est sortie en janvier. Un article de C’t en dévoile rapidement quelques aspects. Si la syntaxe rappelle furieusement le C, et que le D s’inspire du C++, il n’en dérive pas, et nombre d’améliorations lui évitent de devenir l’aberration que, selon certains et d’après ce que j’en ai entendu, le C++ est devenu.
Au menu : plus de préprocesseur, mais une gestion interne des versions ; des fonctionnalités objet plus propres qu’en C++ (pas d’héritage multiple, l’exemple de la fausse bonne idée) mais sans devenir le corset qu’est Java ; l’équivalent des hash tables de Perl, des delegates, des templates ; pas mal de sucre syntaxique[2] ; un garbage collector rustique ; et (ce qui m’attire le plus) gestion des tests unitaires et design by contract[3].
Au final rien de très nouveau, j’ai l’impression d’une mise à niveau du C, vieillissant et trop proche de la gestion mémoire réelle, au moyen de concepts plus modernes déjà maintes fois implémentés.
Le langage va-t-il trouver son public ? Il est déjà utilisable (intégration GCC, plugin Eclipse...). Bjarne Stroupstrup, le créateur du C++ se moquait de son œuvre un jour : “Within C++, there is a much smaller and cleaner language struggling to get out” : le D est-il celui-là ?
Mais sans point fort ou « étendard » (comme les sites Ruby On Rails pour Ruby), ni mégacorporation derrière lui, comment faire son trou à côté du rouleau compresseur C#, et mordre sur le monstrueux existant en C et C++ (bien que des convertisseurs automatiques imparfaits existent) ou celui en Java ?
Ajout de 2009 : Une discussion sur Slashdot en février montre que le langage vit toujours et a conquis quelques adeptes. Sortira-t-il de sa niche ?
Ajout de 2012 : Le langage vit toujours, 25è des plus utilisés paraît-il.
2017 : Le D est inclus dans les outils GNU
Bibliographie
- Article Wikipédia : http://en.wikipedia.org/wiki/D_programming_language
- Site officiel : http://www.digitalmars.com/d/index.html
Notes
[1] Et encore me limité-je ici aux langages informatiques. J’ai dû abandonner les cours d’espagnol après la naissance du Mimi, et je n’ai jamais donné au chinois le temps que j’aurais voulu - pas facile tout seul.
[2] J’adore cette expression.
[3] Je ne suis toujours pas sûr de savoir concrètement ce qu’implique le DBC, et surtout si à l’usage c’est une si bonne idée que ça.
4 réactions
1 De Steve Schnepp - 11/02/2007, 00:46
Un des énormes intérêts du DBC est de permettre de voir rapidement :
- si ton code est bien utilisé (le contrat d'entrée)
- si ton code ne cause pas de problème dans la suite (le contrat de sortie)
Le souci est que dans le principe c'est vraiment bien, mais la question est de savoir ce que l'on fait lorsque l'on a une erreur dans un contrat lors de l'exécution du code en question. En effet, l'idée de base est que le DBC doit permettre une détection rapide des violations des contrats lors des tests, mais ce qui se passe lors de production n'est pas toujours très clair.
De plus, dans la vraie vie, le problème n'est souvent pas vraiment faible nombre de méthodes de contrôle, mais plutôt la faible volonté de contrôler...
2 De Le webmestre - 11/02/2007, 17:27
@Steve : Tu mets le doigt sur le problème, effectivement : que fait-on des erreurs détectées ? La gestion des exceptions, erreurs, cas tordus, représente facilement la moitié du développement d’un programme non trivial. J’ai vu des programmes (indiens...) ne pas chercher à se compliquer la vie et mettre systématiquement sous le tapis chaque erreur (en PL/SQL : BEGIN... EXCEPTIONS WHEN OTHERS THEN NULL ; END ;). Du sabotage, quoi. Je suis partisan de l’explosion d’un programme le plus tôt possible - au moins le débogage est-il facilité et on ne risque pas de corrompre les données.
3 De Miod - 01/03/2007, 10:34
Tss, tss, tss.. PL/SQL est inspiré d'Ada, pas de Pascal, voyons.
4 De Le webmestre - 01/03/2007, 19:21
@Miod: Je me disais aussi que l’Ada ressemblait furieusement au Pascal, aussi :-)