Pourquoi la langue "D" ne reprend-elle pas ?

Question

Toute personne utilisant langue "D ?

Pourquoi n'est-il pas plus populaire ?

Answer 1

Je pense que c'est l'argent des entreprises.

Les créateurs de D, DigitalMars, ne sont pas vraiment des acteurs importants dans le monde des affaires à notre époque.

Son public cible était à l'origine les programmeurs Java et/ou C++.

Mais d'un côté, le problème est que la plupart des programmeurs Java 8 à 5 n'investiront pas dans quelque chose comme D, à moins qu'il n'y ait un ordre du sommet, et les personnes au sommet ne connaissent pas D, parce qu'il n'est pas mentionné dans les cercles d'entreprise. Au lieu de cela, Microsoft a poussé C#, qui vise le même public mais qui a un grand nom d'entreprise.

D'un autre côté, les programmeurs C++ sont des durs, moi y compris, et bien que nous reconnaissions que le D réduirait le masochisme de nos vies, nous sommes accros à la douleur :) Pour être honnête, j'attends toujours D avec impatience, mais je n'ai pas eu l'occasion de l'utiliser.

Answer 2

Il existe deux bibliothèques standard <obsolete as of D2> et 3 ou 4 compilateurs diversement cassés <La qualité des mises en œuvre s'est grandement améliorée. mais d'autres l'ont déjà mentionné.

Une fois que vous avez choisi une bibliothèque <Phobos est la seule bibliothèque standard de facto de D2>. (phobos pour moi), et obtenu un compilateur qui fonctionne à peu près, vous découvrez que D (le langage) a beaucoup de petits problèmes. A eux seuls, ils sont mineurs, mais ensemble, ils rendent la programmation en D quelque peu pénible.

• L'Unicode est traité d'une manière quelque peu étrange - il existe trois types de chaînes unicode différents : char[], wchar[] et dchar[]. <pour UTF-8, UTF-16 et UTF-32 respectivement> - le standard est char[], dans lequel l'unicode est stocké encodé en tant que utf-8 - et les conversions entre utf-8 et les points de code (dchar) sont nécessaires à divers endroits. <Où ? (et sont parfois implicites) <points de code pendant l'itération - pas d'allocation implicite de mémoire> . char[i] donnera cependant le ième octet, et non le ième point de code <Le faire autrement aurait des coûts cachés de performance. ... Les chaînes de caractères sont également mutables <D2 chaînes de caractères sont immuables> vous devez implémenter vous-même la copie sur l'écriture.

• Les tableaux sont étranges. Certains sont statiques, d'autres sont dynamiques. int[] x = null ; fait de x un tableau vide. Les tableaux associatifs littéraux (qui sont une excellente fonctionnalité) avec des chaînes de caractères comme clés doivent avoir toutes les clés de la même longueur ou utiliser une modification syntaxique pour contourner un problème de déduction de type. <fixed in D2> - ça marche mais c'est un peu moche.

• Les tableaux ne sont pas des objets ordinaires, et ne possèdent pas de méthodes d'instance en tant que telles (pas d'indexOf par exemple) - mais il existe des règles étranges < c'est une caractéristique D - méthodes d'extension / UFCS > concernant les fonctions qui sont dans la portée et prennent un tableau comme premier argument pour créer l'illusion de méthodes d'instance...

• Vous pouvez parfois appeler les méthodes sans les parenthèses. <fonctionnement ( @property méthodes)>

• Les fonctions qui forment des fermetures ou sont attachées à des objets (c'est-à-dire des méthodes) ne sont pas les mêmes que les fonctions normales, elles sont appelées délégués et vous devez être conscient des différences. <Les pointeurs de fonction sont comme en C, les délégués ont un pointeur de contexte supplémentaire>.

• Les chaînes littérales (char[]) peuvent être définies avec x "40fe", pour spécifier les octets en hexadécimal qui composent le tableau utf-8. Le site web de D indique que la spécification d'une séquence utf-8 illégale est autorisée, mais mon compilateur n'est pas d'accord. <Non reproductible avec DMD 2.031 ou 1.046, probablement PEBKAC>

• Les modules de la bibliothèque standard (phobos) prennent souvent des arguments sémantiquement incorrects comme arguments de fonction (par exemple, ils prennent char[] alors qu'ils devraient prendre ubyte[]). probablement spécifique à Phobos1 ou vous obliger à utiliser des conventions étranges ( ubyte b; inputStream.read(b); au lieu de ubyte b = inputStream.readUByte(); . <std.stream est obsolète, utilisez ranges/std.stdio>

• Il y a bien une boucle for-each, mais la syntaxe n'est pas adaptée à Python ou même à Java : foreach(ubyte b, char c; "abcdef"){ ... } . for(ubyte b, char c in "abdef"){ ... } serait plus agréable (mais pas beaucoup...). L'inférence de type est optionnelle pour b et c cependant.

• Vous ne pouvez pas créer une classe en lecture seule en const class X {} parce que "les méthodes ne peuvent pas être const ". <Fonctionne dans la dernière DMD2

• La syntaxe du casting : ubyte u = cast(ubyte) 300; est trop verbeux. <By design, to aid code review>

• Vous pouvez transférer des valeurs invalides dans un type d'énumération : enum X : ubyte {a=0, b=1}; X z = cast(X) 10; ne donne aucune erreur - z est maintenant de 10. <br />Il en sera de même pour l'écriture sur un pointeur casté. A dessein, cast Remplace les contrôles du compilateur>

• Le sentiment que j'ai est que si je continue à évaluer D, je trouverai d'autres petits problèmes qui n'ont pas vraiment d'importance tant que vous faites X et Y, mais je ne veux pas faire X et Y...

• Il est vraiment difficile de chercher sur Google des choses relatives à une langue appelée "D" : http://www.google.com/search?q=d+modules <Solution>

Answer 3

Tout d'abord : La plupart des développeurs de logiciels à qui je parle ont au moins entendu parler de D et l'ont mentalement relié aux propriétés que vous avez mentionnées dans votre question (généralement, c'est rapide + la façon dont C++ aurait dû être implémenté en premier lieu). C'est en soi un niveau de réussite que 99% de tous les langages de programmation créés n'atteindront jamais.

Il y a cependant quelques raisons pour lesquelles il ne joue pas dans la même cour que Java/Python/C#/Ruby/etc.

• Le langage lui-même est un successeur de C++ bien fait - et sain. Mais il n'est pas assez différent des autres langages de type statique pour vraiment attirer l'attention. C'est suffisant pour un "ah, c'est vraiment bien" amical, mais pas pour "gee ! I ont pour l'utiliser".
• Il n'y a pas d'application phare qui vous oblige à apprendre le D. Un programmeur moyen a tellement envie de travailler avec ce langage qu'il se donne la peine d'en apprendre un nouveau.
• Les langages de programmation dynamiques tels que JavaScript, Ruby et Python ont conquis une grande partie du marché des langages, ce qui complique la tâche des langages de vérification de type en temps de compilation.
• Le monde de l'entreprise est dans une large mesure un monde de JVM. Il est possible que Java soit bientôt remplacé en tant que langage de développement d'applications, mais son successeur fonctionnera très probablement sur la JVM, car il s'agit d'un logiciel assez mature et stable, doté d'une vaste communauté et d'énormes bibliothèques. La plupart des nouveaux langages JVM, tels que Scala sont compatibles avec le code Java déjà écrit.

Et un dernier point, très subjectif : J'ai l'impression que les langages classiques de type C/C++/Java sont un peu passés de mode dans la partie de la communauté des développeurs qui aime découvrir de nouveaux langages.

Mais tout cela dit, D a l'air vraiment bien et semble résoudre les problèmes qu'il promet de résoudre d'une manière solide et rapide. Il n'y a aucune raison pour qu'il ne trouve pas sa niche.

Answer 4

Selon moi, l'un des principaux obstacles à une adoption plus large est que le langage évolue encore très rapidement. D1 est/était une tentative relativement conservatrice de créer un meilleur C++ en ajoutant certaines leçons apprises au cours des 20 dernières années de langages comme Java et Python. C'est un bon langage, mais il n'a pas d'énormes fonctionnalités qui tuent, il est donc compréhensible que les coûts de changement soient suffisants pour décourager les gens.

D2, quant à lui, est encore en phase alpha, mais représente une innovation beaucoup plus importante. Il tente de combler le fossé entre la programmation fonctionnelle et impérative, avec des fonctionnalités telles que :

1. Const transitif (Tout ce qui est accessible à partir d'un objet const/immutable est lui-même const/immutable).
2. Fonctions pures. Vous marquez une fonction comme pure et le compilateur lui impose de ne pas avoir d'effets secondaires visibles de l'extérieur. Elle peut cependant utiliser librement un état mutable tant qu'il n'est pas visible en dehors de la fonction pure.
3. Partagé. Ce n'est pas encore implémenté, mais l'idée est de faire en sorte que toutes les données ne soient pas partagées entre les threads par défaut, que le compilateur insère automatiquement des barrières de mémoire, etc. lorsque cela est nécessaire si les données sont partagées, et que le système de type empêche le partage accidentel.

D2 ajoute également quelques fonctionnalités pour rendre D plus convivial pour les auteurs de bibliothèques, comme le retour par référence, l'alias this (en fait un opérateur de cast implicite), les arguments d'alias de modèle (en fait, passer n'importe quel symbole de compilation comme argument à un modèle), les contraintes de modèle (similaires aux concepts C++0x), et les vraies fermetures.

Le message à retenir ici est : donnez du temps à D. D1 est un langage agréable, mais relativement conservateur. La plupart des fonctionnalités les plus impressionnantes se trouvent en D2, mais il est encore en phase alpha.

Answer 5

Pas de bibliothèques matures et de documentation de support en général (la plupart du travail est effectué par des volontaires qui font quelque chose pendant un moment puis s'en vont).

Aussi, je pense que le récent schisme que Tango a créé n'aide pas D du tout.