Ya pas que le C dans la vie (ya aussi l'asm ppc et le code objet MIPS mais bon, c'est une autre histoire ...)
Quand aux différences entre langage procédural (type C), et langage orienté objet (C++), elles sont bien minces face aux différences entre un langage impératif et un langage fonctionnel ou bien déclaratif.
Si tu n'as _jamais_ vu d'interet à la POO en dehors de la création de GUI, c'est que tu n'as pas encore assez programmé (ou alors dans des domaines pas assez variés). Amuse toi à faire par exemple de la modélisation géométrique et tu comprendra tout de suite.
Le python est un langage très attrayant. Il permet de faire allègrement du procédural, de l'objet, un peu de fonctionnel (voir beaucoup selon l'humeur, mais quelque fois peut efficace si on force trop la dose, il faut de temps en temps garder le comportement lié à l'impératif qui reste plus utilisé par les développeur python en tête pour ne pas coder un truc qui va ramer), utilise intensément le duck typing, permet de faire de l'introspection extrêmement dynamique.
Qu'en aux cours de programmation pour débutant, n'importe quel langage permettant d'illustrer le concept d'algorithme peut faire l'affaire (d'ailleurs Python en est un excellent pour le coup). Puis tant qu'à faire autant illustrer le plus vite possible les autres concepts de programmation et faire de l'OCaml / Prolog / etc... le plus tot possible histoire de pas être biaisé par le tout impératif.
Quand au langage D, c'est sans doute un bon langage quand on vient du Python. Perso ya quelques point qui me chagrinent un peu et aussi le support dans le monde du LL est assez léger (c'est ptet dommage, ça).
Ce que j'aime bien : tout ce que tu as cité.
+ le support des closures et quelques autres constructions autorisant du code évolutif et très modulaire.
Ce que j'aime moins :
Features To Drop (<- donc pas dans le D) :
# Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures. <-- limitation un peu arbitraire à mon gout, peut etre que le choix a été fait avec lhorrible mode 16 bits des X86 en tete, mais il est dommage de se couper de tout un domaine de l'embarqué.
+ writefln est un nom ridicule (mais printf aussi, sauf que printf était la avant ;)))
Les exceptions que peuvent lever les fonctions n'ont pas l'air d'être spécifiable dans une white list. C'est dangereux dans certain cas, et ca peut aussi parfois etre moins pratique que des codes d'erreurs du coup.
La syntaxe des contrats est inutile à mon gout, (le concept de contrat un peu moins, sauf que ca existait déjà avant que le terme soit "inventé") d'autant que tester ne serait ce que des invariants de boucle est essentiel si on veut un vague semblant de sureté et que la syntaxe est super lourde pour faire ça.
Certaines limitations sont bizarres, on dirait que les concepteur du compilo ont buté sur un pb qu'ils ont pas su régler :
ex. Pas de récurrence croisé entre des constructeurs de signature différente d'une même classe. (je crois pas que ca soit interdit en C++, mais faut être pervers pour en avoir besoin de toute façon)
Le concept de Nested Class n'est pas vraiment utile sans closure sur les classes en question et sans dynamicité des types et de types first class citizen, ce qui n'est pas à l'ordre du jour du fait même de ce que D cible comme implémentation. Ils auraient donc mieux fait de ne pas faire de Nested Class du tout.
Le type de 128 bits (reservé pour usage futur) est bizarre : sans faire de SIMD, le besoin en taille de mot vient plus de l'adressage mémoire que des capa de calcul, et on verrait mal un processeur généraliste implémenter des mots de 128 bits juste pour optimiser les calculs sur les entiers long vu le cout que ca aurait.
Certaines constructions sont curieuses :
struct S
{ int x;
invariant int y;
}
(avec l'allocation de y qui est en fait de plus potentiellement déportée)
Enfin certains points du site oueb énoncent des affirmations catégorique sur des sujets soumis à caution et j'ai typiquement horreur de ce genre de chose. Manque d'esprit critique ! bouh c'est mal :P
En conclusion je pense que D est un langage respectable mais on a la sensation d'un langage plutôt conséquent mais concu par trop peu de monde, contrairement à Python par exemple ou les nouveautés sont toujours incluse de manière à ne rien déstabiliser et à garder une grande cohérence, voir à augmenter la cohérence.
Bref j'ai un arrière gout de petit manque de cohérence pour le D, qui peut être aurait gagné a être encore un peu plus épuré tout en incluant quelques constructions "acédémiques" évoluées supplémentaires (une petite touche fonctionnelle ? ;), sans toutefois que ce petit manque soit rédhibitoire.
[^] # Re: peut etre que...
Posté par Guillaume Knispel . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 6.
Quand aux différences entre langage procédural (type C), et langage orienté objet (C++), elles sont bien minces face aux différences entre un langage impératif et un langage fonctionnel ou bien déclaratif.
Si tu n'as _jamais_ vu d'interet à la POO en dehors de la création de GUI, c'est que tu n'as pas encore assez programmé (ou alors dans des domaines pas assez variés). Amuse toi à faire par exemple de la modélisation géométrique et tu comprendra tout de suite.
Le python est un langage très attrayant. Il permet de faire allègrement du procédural, de l'objet, un peu de fonctionnel (voir beaucoup selon l'humeur, mais quelque fois peut efficace si on force trop la dose, il faut de temps en temps garder le comportement lié à l'impératif qui reste plus utilisé par les développeur python en tête pour ne pas coder un truc qui va ramer), utilise intensément le duck typing, permet de faire de l'introspection extrêmement dynamique.
Qu'en aux cours de programmation pour débutant, n'importe quel langage permettant d'illustrer le concept d'algorithme peut faire l'affaire (d'ailleurs Python en est un excellent pour le coup). Puis tant qu'à faire autant illustrer le plus vite possible les autres concepts de programmation et faire de l'OCaml / Prolog / etc... le plus tot possible histoire de pas être biaisé par le tout impératif.
Quand au langage D, c'est sans doute un bon langage quand on vient du Python. Perso ya quelques point qui me chagrinent un peu et aussi le support dans le monde du LL est assez léger (c'est ptet dommage, ça).
Ce que j'aime bien : tout ce que tu as cité.
+ le support des closures et quelques autres constructions autorisant du code évolutif et très modulaire.
Ce que j'aime moins :
Features To Drop (<- donc pas dans le D) :
# Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures. <-- limitation un peu arbitraire à mon gout, peut etre que le choix a été fait avec lhorrible mode 16 bits des X86 en tete, mais il est dommage de se couper de tout un domaine de l'embarqué.
+ writefln est un nom ridicule (mais printf aussi, sauf que printf était la avant ;)))
Les exceptions que peuvent lever les fonctions n'ont pas l'air d'être spécifiable dans une white list. C'est dangereux dans certain cas, et ca peut aussi parfois etre moins pratique que des codes d'erreurs du coup.
La syntaxe des contrats est inutile à mon gout, (le concept de contrat un peu moins, sauf que ca existait déjà avant que le terme soit "inventé") d'autant que tester ne serait ce que des invariants de boucle est essentiel si on veut un vague semblant de sureté et que la syntaxe est super lourde pour faire ça.
Certaines limitations sont bizarres, on dirait que les concepteur du compilo ont buté sur un pb qu'ils ont pas su régler :
ex. Pas de récurrence croisé entre des constructeurs de signature différente d'une même classe. (je crois pas que ca soit interdit en C++, mais faut être pervers pour en avoir besoin de toute façon)
Le concept de Nested Class n'est pas vraiment utile sans closure sur les classes en question et sans dynamicité des types et de types first class citizen, ce qui n'est pas à l'ordre du jour du fait même de ce que D cible comme implémentation. Ils auraient donc mieux fait de ne pas faire de Nested Class du tout.
Le type de 128 bits (reservé pour usage futur) est bizarre : sans faire de SIMD, le besoin en taille de mot vient plus de l'adressage mémoire que des capa de calcul, et on verrait mal un processeur généraliste implémenter des mots de 128 bits juste pour optimiser les calculs sur les entiers long vu le cout que ca aurait.
Certaines constructions sont curieuses :
struct S
{ int x;
invariant int y;
}
(avec l'allocation de y qui est en fait de plus potentiellement déportée)
Enfin certains points du site oueb énoncent des affirmations catégorique sur des sujets soumis à caution et j'ai typiquement horreur de ce genre de chose. Manque d'esprit critique ! bouh c'est mal :P
En conclusion je pense que D est un langage respectable mais on a la sensation d'un langage plutôt conséquent mais concu par trop peu de monde, contrairement à Python par exemple ou les nouveautés sont toujours incluse de manière à ne rien déstabiliser et à garder une grande cohérence, voir à augmenter la cohérence.
Bref j'ai un arrière gout de petit manque de cohérence pour le D, qui peut être aurait gagné a être encore un peu plus épuré tout en incluant quelques constructions "acédémiques" évoluées supplémentaires (une petite touche fonctionnelle ? ;), sans toutefois que ce petit manque soit rédhibitoire.