Je ne connais personne qui code en C++ sans EDI ou éditeur avancé style Vim/emacs.
Je trouve que c'est une bonne chose d'éliminer les redondances dans le code.
Version imprimable
C'est ce que j'appelle "le cas normal".Citation:
Je ne connais personne qui code en C++ sans EDI ou éditeur avancé style Vim/emacs.
Je dis que c'est naïf parcequ'il arrive que tu ais du code a toucher sans avoir d'editeur sous la main ou encore parcequ'il y a un probleme avec l'editeur (par exemple eclipse).
Après tout, les languages de programmation sont fait pour l'homme d'abord, avant les outils.
A priori non, personnellement je n'ai vu que des jeux et applications amateur en D. C'est déjà pas mal.Citation:
Ça commence à être utilisé dans l'industrie, le D ?
Le problèmes c'est qu'en plus, c'est hors jeu pour tout ce qui est informatique de gestion :
- Pas d'API SGBD
- Pas d'API pour imprimer, même basique
- Librairies GUI en peau de banane
- IDE en tôle ondulée (rouillée)
Bref, D a aucune chance de se démarginaliser s'il se borne à des applications console sans interface graphique. La meilleure façon de remédier à cela serait que les contributeurs décident ensemble d'un unique IDE et qu'ils focalisent leurs efforts dessus. Ca permettrait à terme d'avoir un outil puissant et des fonctions avancés (visual designer, unit test, documentation etc..).
On est dans le scénario catastrophe typique où tout le monde fait un projet dans son coin qui se meurt après 1-2 ans, au lieu de se recentrer autour d'un outil spécifique qui s'imposerait comme standard.
Je ne pense pas que ce soit un cas catastrophique parceque le language évolue et qu'au moins pas mal de gens l'essayent. Effectivement il manque des choses pour qu'il soit plus utilisé en industrie, mais comme il faut en moyenne 10 ans pour qu'un language arrive a maturité (commence a être sérieusement utilisé) ben on peut dire que c'est plotot bien partie si il y en a qui font déjà des jeux en OpenGL (la première fois que j'ai entendu parler de D c'était a cause d'un shoot experimental).
Pour l'ide, je sais pas si c'est l'idéal de se concentrer sur un seul, je me dit que Code::Blocks + Eclipse ça serait mieu (histoire de couvrir l'ensemble des utilisateurs potentiels).
Eventuellement une implémentation d'entreprise (genre Microsoft) serait a mon avis plus efficace( surtout en exploitant un VisualStudio, comme ils ont fait avec IronPython par exemple, ou encore F#).
Dans tous les cas on y est pas encore, c'est sur.
Pour les libs d'impression etc, effectivement ce qui manque le plus c'est toutes les libs auxquelles on a accès en C++. Ya peu de bonne raison de les produires pour les vendeurs, a parti si un marché se crée (dans le jeu vidéo? pourquoi pas mais c'est un milieu qui a du mal a évoluer techniquement hors rendu graphique et IA...).
En tout cas ya pas mal de features interessantes et d'autres que je trouve étrangement pas très logique. A voir comment ça évolue. On devrait aussi parler de Go de google qui entre dans la même catégorie de langauge (système). Après tout ce sont les deux potentiels challenger dans cette catégorie (même si ça dépends des 10 ans a venir).
C'est exact.
Donc on doit avoir un certain nombre de libs disponibles ?
Un binding D de GTK, par exemple, doit être possible ?
Après une petite recherche, il semblerait que ça existe : http://www.gtk.org/language-bindings.html
Oui, mais ça reste très limité comparé au nombre de libs dispo pour C++.
Mais effectivemetn ya "au moins" la compatibilité avec le C.
Appeler du code C++ depuis du code D ne serait que la partie émergée de l'iceberg : Pour utiliser confortablement du code C++ depuis un autre langage, il faudrait aussi pourvoir dériver d'une classe C++ et redéfinir des fonctions virtuelles, avoir un modère de gestion des ressources compatible, être capable de transmettre les exceptions entre les différents langages dans les deux sens...
Pour avoir fait pas mal de C++/CLI pour interfacer du C++ et du C#, je peux dire que sans ces aspects, l'interfaces entres langages demande des efforts très importants, probablement trop pour que je jeu en vaille la chandelle dans nombre de cas.
Bien sûr mais comme dit JollyLoic c'est pas forcément un choix sans risques. Les développer toi-même est vraiment assez risqué alors que d'autres technos t'offrent ça out-of-the-box avec des outils d'édition à l'appui.
En ce qui concerne les IHM, il existe déjà des bindings sur GTK et wxWidgets, également Qt. Mais je fais difficilement confiance à des projets qui reçoivent un commit tous les 6 mois (j'exagère un peu) et qui n'ont pas de roadmap clairement établie. Si tu devais te retrouver bloqué et être livré à toi-même sans support à cause d'un bug, ce serait un sacré coup dur sur tes délais.
Idem pour l'aspect SGBD, as-tu réellement envie de développer un binding sur les libs C de postgres ou mysql alors que java ou .Net t'offrent des drivers testés et activement développés? Avec en plus toute une palette d'ORM éprouvés?
Ce que je veux dire, c'est que je ne dis pas que les choses sont impossibles avec D, si on se base sur des bindings C, tout est possible. Simplement que c'est pas un choix facile par rapport aux risques et au travail supplémentaire que cela engendre.
Oui, ça explique effectivement bien pourquoi une adoption de D par l'industrie est pour l'instant impossible.
Il faudrait qu'une entreprise influente s'y intéresse, ou bien (comme ça a pu être le cas pour Python) que la communauté du libre l'adopte de façon significative pour que le langage ait un avenir industriel.
Plus d'info sur le sujet : http://stackoverflow.com/questions/2...-have-a-future
Plus je progresse en C++, plus je me dis qu'on a besoin d'un successeur de ce langage qui commence à devenir quelque peu overbloated.
Je m'en vais feuilleter le bouquin d'Alexandrescu pour voir à quel point D mériterait d'être évangélisé…
Personellement, je pense que D a de très bonne idées, et d'autres moins bonnes, mais tant que je n'ai pas tout lu le bouquin, je n'aurais pas tous les arguments des créateurs.
Selon moi quelque chose plus proche de C++ mais avec certaines feature du D (thread-local par défaut + shared , différence concrète et utile entre struct et class, modules...) serait encore plus interessant que le D.
Il faudrait aussi que la communauté D s'affiche et cesse de se disperser dans tout un tas de projets foireux :
http://dsource.org/forums/index.php
Ca manque gravement de coordination tout ça...
si le D avait un cross-compiler c'est presque sur que je développerais avec :)
mais je ne crois pas qu'il y ait un cross-compiler D pour mips, arm ou powerpc, malheureusement
Oui justement l'arrivée du D2.0 était censé remettre certaines pendules a l'heure mais je ne pense pas qu'on puisse voir immédiatement l'effet. Il va falloir voir comment ça évolue dans les mois (voir années) a suivre.
Il me semble que gcc utilise un pseudo-langage intermédiaire (un peu comme le CIL) pendant la compilation et que les binaires étaient compatible. De plus, je n'ai pas vue de choses qui était incompatible entre le D et le C++ qui empêcherais une classe D d'hériter d'une classe C++.
Mais bon, je ne fais que supposer.
Es ce que l'on ne pourrais pas imaginer un équivalent de boost.python pour D ?
Disclaimer : Je n'ai jamais fait de D, j'ai juste lu quelques articles.
J'ai l'impression que le modèle objet n'est pas le même, par exemple l'absence d'héritage multiple doit pas mal influencer la manière dont les fonctions virtuelles sont gérées...
En cherchant d'autres exemple, je suis tombé sur :
Je n'ai pas utilisé boost.python non plus. Je pense qu'on doit pouvoir arriver au même genre de fonctionnalités, avec le même genre de limites, qui impose d'écrire pas mal de code intermédiaire (par exemple :Citation:
Features To Drop
Link compatibility with C++. The C++ runtime object model is just too complicated - properly supporting it would essentially imply making D a full C++ compiler too.
http://www.boost.org/doc/libs/1_44_0...tual_functions)
C'est le moins qu'on puisse dire :
- pas d"héritage multiple
- struct et class sont radicalement différent (sémantique de valeur et sémantique d'objet, respectivement) - ça pose des problèmes avec les objets c++;
- le compilo définit à la compilation si il y a besoin de virtualité sur un fonction membre, ou pas - non-précisé par l'utilisateur
- garbage collector par défaut (mais pas de vm)
- thread-local par défaut...
En gros je vois pas comment les deux languages peuvent être directement compatible. Au mieu, on pourrait pouvoir manipuler un pointeur vers un objet C++ et appeler des méthodes... et encore je suis pas sur qu'il n'y aurait pas des complications.
Donc en gros on pourrait au mieux faire pour D un truc comme C++/CLI est fait pour le C#.
Et d'expérience, même si c'est fonctionnel, c'est lourd, c'est peu élégant, et c'est une source de bugs.
Eventuellement, on peut utiliser D comme un language de script. D'après la doc, le language est suffisamment simple à implémenter pour même pouvoir tourner sur une VM si besoin (et d'après eux les expressions sont context-independant contrairement au C++).
Si on approche le language comme ça ça peut être interessant, mais pas pour un scripteur qui y connait peu en programmation...
A priori le plus simple c'est d'avoir une interface en C qui encapsule par exemple du code C++ de manière a ce que D puisse aussi avoir une interface de son coté qui encapsule le C. Tout un programme...
Pour les GUI/SGBD etc, c'est pas grandiose en effet.
Pour l'IDE je conseille de se tourner vers Visual D, c'est développé par un seul gars mais c'est bien actif et ça apporte la complétion et un débugger.
Pour ta critique sur dsource, oui il y a plein de projets inutiles et/ou abandonnés mais bon, le fait est que les gens font pas mal de projets inutiles quel que soit le langage. :)
D est utilisé dans quelques boites, par exemple celle-ci: http://www.sociomantic.com/careers
leur blog en parle: http://blog.sociomantic.com/2010/04/...eriences-in-d/
J'avais aussi demandé qu'ils inscrivent la mailing list sur nabble afin d'avoir une présentation forum comme ici :
http://lucene.472066.n3.nabble.com/
avec groupage des posts et fonction "rechercher" plutôt que cette m***e :
http://www.digitalmars.com/pnews/ind...italmars.D.ide
où les fils de discussion sont juste impossibles à suivre. Ma demande a été juste ignorée...
Juste mais le problème c'est que le mec qui cherche des ressources sur D il tombe là dessus et il voit que plus rien ne bouge depuis 2007. Et même pour les projets qui reçoivent des contributions il n'y a aucune description, aucune roadmap, rien.Citation:
Pour ta critique sur dsource, oui il y a plein de projets inutiles et/ou abandonnés mais bon, le fait est que les gens font pas mal de projets inutiles quel que soit le langage.
Ce que je dénonce, c'est qu'il y a visiblement une communauté active et désireuse de contribuer, juste que ses efforts sont dispersés dans tous les sens et que rien n'est coordonné. C'est vraiment du gâchis et le résultat rebute sans doute bien du monde.
Pour les newsgroups, il y a plusieurs interfaces Web dont une seule est à peu près utilisable (et encore). Utilise ces liens ou alors un client news.
Les plus intéressants sont digitalmars.D et digitalmars.D.announce
http://www.digitalmars.com/webnews/n...=digitalmars.D
http://www.digitalmars.com/webnews/n...ars.D.announce
Après pour dsource.org, pas mal de développeurs ont migré vers bitbucket parce que le site est trop souvent down.
Pour les infos sur le langage et la communauté autour http://prowiki.org/wiki4d et le canal #D sur freenode sont des bonnes ressources.
Il y a (eu) une discussion très interessante sur les différences entre Go (de Google) et D (qui visent tous les deux a être des langages systèmes mais sont différents par leur approche - simplicité pour Go VS C++Killer/multi-paradigm pour D ) avec intervention d'Alexandrescu en prime.
Discussion très polie et courtoise, enrichissante, surtout si on est interessé dans ces languages ainsi que dans C++, Python, Ruby, Java...
La discussion : http://groups.google.com/group/golan...091e27ab?pli=1
Une note sur le fait qu'Alexandrescu dit que visiblement le probleme des dispersion politique de la communauté serait réglé. Ce qui serait une bonne chose si c'est vrai (difficile a vérifier sans suivre).
Si on se fie aux newsgroups, le binding en D pour Qt serait sur le point de ressuciter.
Oui j'ai cru voir passser l'info aussi. Pour l'instant j'ai juste récupéré de quoi faire du SFML avec D voir un peu ce que ça donne. Mais je m'y mettrais pas immédiatement.