D est un langage voisin du C++, mais où les fonctionnalités auraient été intégrées avec goût. Pour Walter Bright, le créateur de D, il n'y a pas une fonctionnalité particulière qui définit D, c'est le tout qui facilite le développement et la maintenance sans avoir à abandonner la vitesse du C/C++. Pour ceux qui viennent du C/C++, D fournit :
- un ramasse miettes (Garbage Collector) par "défaut", bien qu'on puisse gérer soi-même la mémoire en cas de besoin.
- une syntaxe de programmation des templates plus propre et plus puissante.
- pas de préprocesseur, le langage fournit des fonctionnalités similaires.
- le support de la programmation par contrat.
- gère les tableaux dynamiques, les tableaux associatifs ce qui fournit une meilleure syntaxe.
- "scope guards" (que je ne sais pas traduire): une alternative au classique try/finally permettant d'écrire du code plus robuste en cas d'exception (cf le lien).
Tout cela et bien d'autres choses avec une vitesse d'exécution similaire au C/C++ mais avec des temps de compilation très rapides.
Pour ceux qui viennent du C#/Java, la liste est plus courte, mais un gros avantage: pas de machine virtuelle ou d'interpréteur.
Voir le lien vers le comparatif pour une liste plus complète.
Il n'y pas un mais deux (!) compilateurs pour développer en D :
- DMD (Digital Mars reference compiler, Windows & Linux, x86): compilateur gratuit dont seul le frontal est libre.
- GDC: compilateur totalement libre basé sur GCC.
Mon avis personnel : une bonne alternative au C++ (ou de Java/C#), avec une communauté importante, mais encore un manque de bibliothèques.
Aller plus loin
- D Programming Language (37 clics)
- Comparaison de D avec C, C++, C#, Java (42 clics)
- Scope guards (6 clics)
- D sur Wikipédia (31 clics)
- D sur dmoz (9 clics)
- FAQ sur D (6 clics)
# Petit clin d'oeil matinal
Posté par Minos . Évalué à 8.
http://linuxfr.org/comments/399822.html#399822
Blague mise à part, je m'en vais tester ça, ça a l'air intéressant.
[^] # Re: Petit clin d'oeil matinal
Posté par Christophe Roland (site web personnel) . Évalué à 5.
le langage alpha:
http://www.irisa.fr/centredoc/publis/PI/1994/irisapublicatio(...)
le langage bêta:
http://www.daimi.au.dk/~beta/
le langage gamma:
http://www.cogent.ca/index.html?http://www.cogent.ca/Softwar(...)
pour ne citez qu'eux...
# Encore un nouveau langage
Posté par koopa . Évalué à 7.
Peut etre que le pragmatisme du "D" lui évitera de rester dans l'ombre comme Ada et Eiffel. (La programmation par contrat, le ramasse-miette, le typage fort, ca fait presque 20 ans que ca existe dans Eiffel.)
En tout cas je lui souhaite bonne chance.
PS:
J'ai l'impression que pour réussir un langage doit bénéficier d'une dynamique externe :
Par exemple:
Windows -> Visual Basic
Unix -> C -> C++
Internet -> Java, PHP, et bientot Ruby (on Rails)
[^] # Re: Encore un nouveau langage
Posté par patrick_g (site web personnel) . Évalué à 3.
====> Je sors
[^] # Re: Encore un nouveau langage
Posté par zebra3 . Évalué à 2.
Comme quoi il y a des exceptions, et c'est que qu'on peut souhaiter à D !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Encore un nouveau langage
Posté par dgsconseil . Évalué à 1.
[^] # Re: Encore un nouveau langage
Posté par zebra3 . Évalué à 2.
Et d'ailleurs, il me semble que Mandr{ake,iva} utilise un max de Perl pour ses outils système, on ne peut pas dire pour autant que c'est grâce à ça que Perl est tellement utilisé, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Encore un nouveau langage
Posté par reno . Évalué à 1.
Pour avoir essayé de corriger un bug qui m'ennuyait dans un outil de Mandrake et avoir fuit devant du Perl (langage illisible s'il en est et a mon avis pas vraiment adapté pour codé un IHM dans ce cas la), je confirme.
[^] # Re: Encore un nouveau langage
Posté par Harry Da . Évalué à -1.
Parceque bon Ruby, de l'installation à l'apprentissage c'est comment dire...plus long. On est tous d'accord que le deploiement de Django (un simple mod_python) est plus rapide et facile que RoR avec Mongrel. Il se peut que je sois en retard donc si quelqu'un peut donner des info plus conrètes sur Mongrel (J'avais testé au tout début, cela à du changer) je prend :)
Alors oui AJAX (Encore que Django+DOJO fonctionne trés bien) toussa c'est cool pour faire mousser les moules, c'est super hype, on brille en soirée avec...mais apprendre un nouveau langage alors que je connais déjà Python trés peu pour moi.
Attention ce qui me rebute ce n'est pas d'apprendre un nouveau langage, c'est d'être "obligé" d'en apprendre pour faire quelque chose que j'aurai put facilement faire avec un langage que je connais déjà (ie : Pyrhon). Et la structure de RoR est compliquée au possible comparée à celle de Django (C'est un point de vue totalement personnel).
Et puis pour moi du code python est plus perene que du code Ruby :)
[^] # Re: Encore un nouveau langage
Posté par Alex . Évalué à 3.
Surement, mais en fait je connais pas Mongrel, mais sans mongrel, rails nécessite juste le lancement de webrick, l'install de mod_ruby ou fastcgi
Enfin c'est quand même pas l'interet principal de rails, d'un autre coté j'apprécie de pas avoir à faire du javascript pour faire un minimum d'ajax
Ben la curiosité, en tout cas c'est mon cas. Je connais ruby et pas python, mais pour essayer une techno qui me semble interessante, pourquoi pas, surtout que finalement pour essayer pas besoin d'apprendre un langage, les ressemblances entre chacun d'eux suffisent généralement à comprendre le langage voisin, pis a se former ptit à ptit sur le tas
Bon jai rien à dire, jconnais pas Django, mais promis j'irai voir. Mais que veux tu dire par "structure de RoR est compliquée au possible" ?
Perso cest ce qui m'a attiré dans ruby, sa structure claire
[^] # Re: Encore un nouveau langage
Posté par Harry Da . Évalué à 3.
Bon j'avoue que ça ne me dérangerai pas que Django permette directement la création d'AJAX :). Mais j'entend tellement l'amalgame RoR = AJAX
Je me suis mal exprimé : je parlais évidemment dans un environement professionel. Si je me suis un peu tourné vers RoR et Ruby c'etait par curiosité, chez moi :), donc je suis totalement d'accord avec toi.
Quand je suis allez du coté de RoR j'etait déjà conquis par Django et j'avais bien assimilé sa structure. Mon jugement étais donc probablement un peut faussé. Mais n'empèche que l'on fait difficilement plus simple comme structure que celle de Django : un fichiers de conf, les urls, les models, les vues et les templates (je chématise).
Je conseil à tous le monde d'allez voir la "concurrence" commme je l'ai fais. Ce n'est pas facile de rester objectif et d'oublier son premier choix mais on peut avoir de belle surprises :)
Quoi qu'il en soit je reste sur mes premières idées :
Du code Python est plus perène que du code Ruby
Il y'a plus de personnes qui connaisses Python que de personnes qui connaisses Ruby.
Il faut aussi penser aux personnes qui reprendrons le site dans l'avenir. Pour moi Python est le meilleur choix pour assurer sa maintenance et son évolution à long terme. (Putain elle claque trop cette phrase, daycideur prayssay de demain sort de ce corp)
[^] # Re: Encore un nouveau langage
Posté par Yann Lugrin (site web personnel) . Évalué à 5.
D'un autre coté, tu ne pourrai pas écrire ceci si ceux qui se sont mis à utiliser python quand il était encore peut connu avais suivi le même raisonnement.
Je pense qu'il faut surtout trouver des outils qui conviennent et avec lesquels on est à l'aise quand on en à le choix. Si j'utilise RoR et Ruby c'est bien pars que ils me conviennent mieux que Python (et Djengo ou turbogears par exemple). Je connais relativement bien python, j'en ai fait pendant plusieurs années mais Ruby me conviens mieux et puisque j'ai le choix...
Je reviens aussi sur la mise en production, le couple apache2 / mongrel fonctionne à merveille et est très simple à mettre en place.
[^] # Re: Encore un nouveau langage
Posté par reno . Évalué à 7.
- ces deux langages n'étaient au départ utilisables qu'en payant cher des compilateurs alors que les compilateur C/C++ du moment étaient gratuits ou pas trop cher.
- utilisation des ressources du langages et du compilateur, a leur débuts la mémoire était une ressource rare donc le GC était un probleme, et au moins pour Eiffel, il y avait aussi un problème de ressources du compilateur qui était gourmand.
Certes maintenant, il existe des compilateurs gratuits et le probleme des ressources est réduit, mais ils ont perdu "l'attrait de la nouveauté" entre temps..
Et Java a bien montré que l'effet de mode est un puissant moteur pour l'adoption d'un langage dans l'industrie.
Je ne sais pas si D réussira a s'implanter, mais avec DMD et GDC (j'avais oublié le lien http://sourceforge.net/projects/dgcc/ ), il a évité les deux premiers problèmes, c'est encore un langage jeune et il a une communauté active, maintenant que la spec du langage est en version 1.0, cela permettra aux compilateurs de se focaliser sur leur finition, et au développeurs de librairie de vraiment se lancer, on verra ce que cela va donner..
# mon avis
Posté par TImaniac (site web personnel) . Évalué à 6.
J'avoue que j'ai du mal à comprendre le rapport avec ces 2 langages au niveau confort de programmation...
Pour ceux qui viennent du C#/Java, la liste est plus courte, mais un gros avantage: pas de machine virtuelle ou d'interpréteur.
Non, ca c'est le gros désavantage : on perd la couche d'abstraction avec le matos, on perd tous les services de sécurité, les services d'introspection, la portabilité binaire, les services de remoting, et j'en oublie sûrement (au passage ils "oublient" toutes ces fonctionnalités dans leur tableau de comparaison, ils font juste mention du typeof).
Le gros avantage par rapport à C# ou Java, c'est surtout les perfs. C'est en partie lié à l'absence de machine virtuelle, certes, mais surtout au côté "programmation bas-niveau" (tout est relatif, mais bon : pointeurs, pas de vérif, toussa).
Bref, D est plus un remplacant du C/C++ qu'une alternative à C#/Java : pas les mêmes objectifs et donc pas forcement les mêmes utilisations apropriées.
Bon j'espère maintenant que D va être normalisé, ca serait vraiment cool d'avoir un vrai remplacant à ce batard de C++.
[^] # Re: mon avis
Posté par Stibb . Évalué à 2.
Mais, principalement pour des raisons de perf, un très grand nombre de petit ou moyen projets peuvent être écrit en D au lieu de certains langages, comme Python, qui auraient été choisit pour ne pas s'embeter avec les pointeurs.
Il est indéniable que lors du choix du langage à utiliser, D a toutes ses chances. Il ne faut pas qu'il reste "un autre langage", mais qu'un grand nombre de personne acquiesse de sa puissance. Après cette preuve de stabilité, D risque de devenir incontournable.
Par contre, il est indéniable qu'au niveau perf, il est quasiment au même niveau que le C++ (et aussi en occupation mémoire). C'est son grand avantage par rapport à Java et C# (et ne nécessite aucune DLL/librarie)
Ecrire en D est assez aisé, mais il manque certaines choses:
- la doc est certes assez grosse, mais manque cruellement d'exaustivité sur certains points particulier. Un Wiki serait bienvenue.
- la dernière fois que j'ai voulu utiliser le compilo GPL j'ai galerer comme un malade. dmd marche nettement mieux.
- Les binding Wx ou GTK manquaient cruellement de stabilité, j'espère qu'ils ont été développer.
- un IDE serait effectivement le bienvenu. J'utilise CodeBlocks mais le support était encore limité au syntax enlightenment. L'auto-completion puissante, ainsi qu'une aide en ligne seraient les bienvenue, eux aussi, et permettraient d'apprendre le langage encore plus rapidement.... CB propose un object browser qui ne demande qu'à être completer. Pas trouvé de plugin D pour eclipse jusqu'à maintenant.
[^] # Re: mon avis
Posté par reno . Évalué à 2.
D'un autre coté, les newsgroup dédiés a D sont très actif, ce qui compense pas mal.
Il y a des wiki bien sûr comme http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage mais je crois que aucun n'a le statut de "wiki officiel", ce qui est dommage, je suis d'accord.
>- la dernière fois que j'ai voulu utiliser le compilo GPL j'ai galerer comme un malade. dmd marche nettement mieux.
>- Les binding Wx ou GTK manquaient cruellement de stabilité, j'espère qu'ils ont été développer.
>-un IDE serait effectivement le bienvenu.[..]
L'idée de passer la spec de D en version 1.0 est justement d'inciter à la stabilisation des compilateurs, des librairies, et au développement des outils autour du langage..
[^] # Re: mon avis
Posté par Gilles G. . Évalué à 2.
je pense que cette remarque est liée à:
- fonctionnement en modules (pas de préprocesseur)
- syntaxe cohérente, indépendante du contexte
- gestion propre des exceptions et programmation par contrat
Sinon, tu dis:
Puis:
L'auteur faisait le raccourci: machine virtuelle=>lenteur, donc vous dites la même chose...
[^] # Re: mon avis
Posté par reno . Évalué à 4.
Oui, j'avoue, mais regarde la pour un comparatif entre Java et D au niveau perf CPU et utilisation mémoire:
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Assez édifiant non?
Bon bien sûr les benchmarks, c'est toujours à prendre avec des pincettes..
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 1.
Si une fonction n'est lancée qu'une fois il y a peu de chance pour que la JVM ai eu le temps de l'optimiser au mieux.
Pour ma part j'ai transcrit dernièrement du code C vers du Java (en l'occurence un algo de code correcteur d'erreur) et les performances sont plus qu'honorables. La première fois que la méthode est exécutée ça peut être dix fois plus lent, mais une fois optimisée par la JVM j'ai constaté une dégradation des perfs inférieure à 10%.
[^] # Re: mon avis
Posté par reno . Évalué à 2.
Regarde http://shootout.alioth.debian.org/debian/faq.php#fullcpu
La différence de temps n'est pas énorme <20% entre des conditions de mesure qui avantage ou désavantage Java, alors que les différence de CPU entre Java et D peuvent être bien supérieur (jusqu'à un ordre de grandeur de différence).
Maintenant comme je disais bien dans le doc, l'avantage c'est bien l'absence de VM (ça fait ça en moins à gérer), le gain de performance est un bonus.
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 2.
D'autre part tous les langages ne semblent pas logés à le même enseigne.
Par exemple, vu la grosse différence entre C et Java pour le test pidigits j'ai regardé le code C. Je sais pas ce que c'est sensé faire mais c'est visisiblement des calculs sur de grands entiers. Sauf que le programme C utilise la bibliothèque GMP, codé en C certes, mais avec des optimisations en ASSEMBLEUR.
Pour avoir déjà testé GMP je peux t'assurer que ces optimisations en assembleur c'est pas que de la frime! (tu gagnes facilement un facteur 5 voir plus sur certains calculs). D'ailleurs pour ceux que ça intéresse la lib OpenSSL a également de telles optimisations (très efficaces pour le calcul d'exponentielles modulaires).
Dans la version Java on utilise la classe BigInteger qui est du java à 100% (oui j'ai vérifié).
Euh... y a comme qui dirait triche là! Et association de malfaiteur en plus puisque la version D est complice!
[^] # Re: mon avis
Posté par Antoine . Évalué à 2.
Utiliser une bibliothèque, c'est de la triche ?
Java n'a qu'à utiliser GMP au lieu de réinventer la roue...
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 1.
Parceque GMP est la seule bibliothèque disponible en C? Au cas ou tu aurais un doute, ce n'est pas le cas, même si c'est sans doute une des plus performante maintenant. Zut alors encore des gens qui ont réinventé la roue!
Ce test est sensé comparer les perf de 2 langages. Ici on a l'impression que Java est très lent pour ce genre de calculs alors que ce sont les optimisations en assembleur qui boostent les perfs du programme en C. Si on refaisait le test avec un lib écrite exclusivement en C on aurait des résultats beaucoup plus proches entre les deux langages.
Il est tout à fait possible de faire appel à GMP depuis un programme Java. Avec Swig c'est même relativement facile.
Mais est-ce que la comparaison aurait toujours un sens?
[^] # Re: mon avis
Posté par Antoine . Évalué à 4.
Un langage n'a pas d'intérêt sans bibliothèques. Quand on utilise un langage, on n'a rien à branler que les bibliothèques sous-jacentes soient optimisées en C, assembleur ou Javascript.
Donc je répète : si les bibliothèques disponibles pour Java ne sont pas au niveau de celles disponibles pour C, tant pis pour Java.
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 3.
GMP n'est pas une bibliothèque standard du C, au contraire de BigInteger de Java. Out of the box tu as tout ce qu'il te faut en Java. En C il va falloir que tu fasses des recherches sous Google pour trouver les références d'une bibliothèque, qui ne sera pas forcément GMP d'ailleurs, et qui ne sera pas forcément aussi performante.
A l'origine d'ailleurs la classe BigInteger faisait appel à du code en C ou C++ (mais sans assembleur) puis les gars de SUN se sont aperçu que leur nouvelle implémentation Java était pratiquement aussi rapide et même plus rapide pour des calculs sur des petits nombres, pour lesquels le coût d'appel à une lib externe devenait non négligeable par rapport à la durée du calcul proprement dit. Ils ont donc préféré garder la version Java qui offre au final on a une classe intégrée, relativement performante et surtout indépendante de l'architecture.
Il existe peut-être des lib Java non intégrées au JDK plus performantes dans ce domaine (JScience peut être une piste). Et comme je l'ai déjà dit, si le besoin s'en fait sentir tu peux très bien faire une belle interface Java pour GMP (et l'appeller libJavaGMP!) et tu auras quasiment les mêmes perfs que le programme C. Mais tu perdras en portabilité (ça peut ne pas être un problème) et dans le cadre de ces benchmarks beaucoup de monde risque de trouver, à mon avis à raison, que permettre au programme Java d'appeler du code externe C/assembleur ne permet pas d'avoir une vue représentative des perfs du langage en lui-même qui sont pourtant visiblement un des buts de ces benchmarks.
[^] # Re: mon avis
Posté par Antoine . Évalué à 3.
C'est marrant, Python a aussi une classe intégrée, indépendante de l'architecture et en plus elle est trois plus rapide que Java.
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
(et évidemment, c'est beaucoup plus concis et lisible en Python)
Bon, mais merci pour la discussion.
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 3.
Pour les performances, rien ne vaut un petit test.
De base je constate effectivement que dans les conditions précisées sur le site le programme Python s'exécute plus vite que la version Java (par un ratio d'environ 4 avec 500 comme argument)! Sauf que j'estime que le démarrage d'une JVM est relativement long dans le cadre de ces benchmarks et que les optimisations du JIT ne sont pas non plus négligeables.
Donc pour tenter de minimiser l'effet de démarrage de la JVM j'ai mis une boucle for pour exécuter 10 fois la fonction main et j'ai fait de même pour la version Python:
J'ai lancé la JVM en mode client qui ici est plus rapide que le mode -server. Je sais pas pourquoi c'est le cas ici, mais de toute façons lancer une JVM en mode server pour un aussi petit programme est stupide vu qu'elle va se lancer nettement plus lentement.
Pour info la première exécution du main du programme Java s'effectue en environ 530 ms et tombe à environ 300 ms. L'optimisation du JIT n'est tout de même pas négligeable.
Un simple time -p me donne pour Python:
real 2.82
user 2.48
Et pour Java:
real 3.39
user 2.58
Tiens, bizarre la version Python reste certes plus rapide mais on est loin du facteur 3.
L'écart se ressert si on augmente le nombre d'itération et/ou la valeur de l'argument. Par exemple avec 200 itérations:
Python:
real 54.63 / 53.60 (version compilée)
user 49.45 / 48.66 (version compilée)
Java:
real 60.18
user 47.08
Si je ne m'abuse la version officielle de Python est codée en C et j'imagine que c'est également le cas de la partie chargée de traiter les grands nombres. L'aspect "interprétation" n'intervient que très peu dans ce programme, d'où la faible différence avec la version compilée.
Moi j'en conclu que si on laisse le temps à la JVM de se lancer (un petit bout de programme comme celui-là c'est vraiment la pire des situations pour une VM), on obtient des résultats assez différents.
Alors Python a une classe intégrée performante, mais au final pas franchement plus que celle de Java et manifestement elle n'est pas non plus optimisée avec de l'assembleur. Mais de toute façon je crois qu'un binding GMP pour Python existe...
[^] # Re: mon avis
Posté par taratatatata . Évalué à 2.
A noter que je n'ai pas vu ce temps de chauffe dans des applis Mono. AOT?
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 1.
Une petite précision pour la classe BigInteger: j'ai affirmé qu'elle était plutôt bien optimisée. Mais en fait je faisais référence au calcul d'exponentielles modulaires qui offre des perfs comparables à d'autre lib C/C++ (sans assembleur). Mais il paraît qu'elle n'est pas super optimisée pour les autres opérations comme la multiplication car elle n'utilise pas des algorithmes optimaux (?).
Ca pourrait être intéressant d'essayer la lib JScience qui prétend obtenir de meilleures perfs en addition et multiplication (mais est-ce vrai pour toutes les tailles de nombre?). Par contre en exponentiation modulaire, gardez BigInteger, avec JScience c'est assez catastrophique.
Pour ce qui est des performances des applis Swing elles se sont beaucoup améliorées avec les dernières versions de Java. Sous des applications comme NetBean ou Eclipse, pour citer de gros programmes, la première fois que je clique sur un menu on sent un très léger retard qui ne se produit plus par la suite. Mais sinon les deux sont aussi réactifs qu'une application native.
J'ai également déjà codé des GUI en Java et avec une JVM récente le lancement me semble aussi rapide qu'une application native (ce qui n'a pas toujours été le cas!).
L'idéal serait que les optimisations de la JVM puisse être mise en cache pour éviter de refaire le boulot à chaque lancement. Je sais pas si c'est prévu mais maintenant que java est en GPL on va peut-être voir apparaître des choses intéressantes. Au pire une compilation native via GCJ pourra être viable.
Pour Mono je ne sais pas. Je ne connais aucune application intéressante.
[^] # Re: mon avis
Posté par Frédéric Lopez . Évalué à 1.
Question idiote, mais pourquoi la classe BigInteger n'est-elle pas implémentée en assembleur plutôt qu'en Java natif si ça offre tellement plus de performances ?
[^] # Re: mon avis
Posté par VoixOff . Évalué à 2.
[^] # Re: mon avis
Posté par Alex . Évalué à 2.
De plus je ne pense pas que le but de java soit d'avoir les meilleurs perfs qui soit, surtout sur des libs mathématiques
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 1.
C'est juste que ça m'énerve que sur ce test on puisse penser que le C écrase littéralement tous ses concurrents alors qu'en fait c'est le code assembleur qui devrait récolter tous les lauriers.
[^] # Re: mon avis
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: mon avis
Posté par reno . Évalué à 2.
Donc en C d'utiliser GMP et en Java d'utiliser BigInteger pour faire des calculs sur des grands entier, cela correspond bien a du code typique et cela ne me choque pas particulièrement.
Ceci dit merci pour l'info, j'ignorais que GMP contenait des optimisations en assembleur.
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 0.
C'est juste que ce test donne l'impression que Java est intrinséquement lent pour ce genre de calculs alors qu'en fait il s'en sort plutôt bien. D'autre part BigInteger est intégré au JDK et donc le choix logique, alors que GMP n'est pas une lib "standard" du C (même si c'est le choix sans doute le plus judicieux).
[^] # Re: mon avis
Posté par alice . Évalué à 1.
Ce n'est pas un oubli, c'est juste des fonctionnalités qui ne sont pas du ressort du language, mais du compilateur et des API. Rien n'empêche la création d'une version de D qui s'exécute dans une machine virtuelle avec les services que tu décris.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Ces fonctionnalités sont fortement dépendantes du type de machine cible. Pour celà les plateformes de type .NET/Java propose une "vue" différente de la machine physique : une machine virtuelle, et c'est elle qui propose la plupart de ces services. Le langage par ses possibilités offertes suppose/exploite les fonctionnalités proposées par la machine cible. Le compilateur étant là pour faire la traduction dans le langage de la machine cible (réelle ou virtuelle).
Bref, c'est tout un éco-système, du langage à la machine cible en passant par le compilateur qui offre ces fonctionnalités. Et c'est pourquoi les plateformes comme .NET/Java ont une machine virtuelle, pour proposer tous ces services. Et c'est pour la même raison que D ne peut avoir ces services, parcqu'ils ont fait le choix de ne pas avoir de machine virtuelle.
Rien n'empêche la création d'une version de D qui s'exécute dans une machine virtuelle avec les services que tu décris.
Avoir D qui tourne sur une machine virtuelle, pourquoi pas, mais sans modification/support du langage, la plupart des services seront inaccessibles.
[^] # Re: mon avis
Posté par alice . Évalué à 1.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Ah bon ?
Et la syntaxe pour écrire des méta-données intégrée au langage Java ca sert à quoi ?
A quoi sert les mots clés instanceof ou typeof ?
Si le langage autorisait comme l'autorise le C/C++ l'exécution de code binaire (asm) comment tu ferais de l'introspection sur le code ?
Si le langage autorisait des optimisations du style 'inlining" pour des méthodes, comment tu la retrouverais par introspection ? (genre le compilo s'amuse à inliner les méthodes get* et set*, ca serait rigolo pour les bean...)
A quoi ressemblerait un template àla C/C++ dans l'exécutable par introspection ?
On est d'accord, le service d'introspection n'est pas fourni par le langage, mais ill faut que le langage se plie à un certain nombre de contraintes et propose quelques fonctionnalités (genre méta-données).
[^] # Re: mon avis
Posté par lasher . Évalué à 3.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Et bon, globalement, il peut rarement inliner, si l'objet cible est défini dans un .class séparé et que celui-ci est amené à évoluer, c'est la merde quand même... Cela dis ca n'empêche pas un inlining au moment de la compilation JIT.
[^] # Re: mon avis
Posté par reno . Évalué à 4.
Le GC par défaut, la gestion des tableaux/hash dans le langage font que la programmation est par défaut d'un plus haut niveau que C/C++ mais tu as raison, c'est plus du niveau C# que Ruby/Python.
Pour ce qui est de la portabilité binaire, franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows, pour Java, la pub "Run everywhere" s'est rapidement transformé en "Test everywhere".
Pour ce qui est de la programmation bas niveau en D, je ne suis pas d'accord: tu peux certes le faire, mais ce n'est pas le comportement par défaut: par défaut, tu utilise le GC, les accès aux tableaux sont vérifié (désactivable par option de compilation pour améliorer les perfs), le write (équivalent a printf) vérifie le type des arguments, les paramètres des fonctions sont passé en mode in, out, inout pas par pointeur ce qui restreint l'utilisation des pointeurs, etc donc le niveau de programmation est similaire a celui de Java/C# mais avec des perf voisine de C/C++.
La ou je vois une niche possible pour D serait dans la programmation d'application clientes: en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code) ce qui les rend mal adaptés pour les applications clientes, maintenant il faudrait pouvoir utiliser Qt en D..
Pour ce qui est de la normalisation, je ne suis pas sur de ce que ça apporte, Ruby et Python vivent bien sans être normalisé..
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Java/C# te garantisse une certaine sécurité. C/C++/D non. Même si D te propose d'avoir une meilleure sécurité, il n'y a aucune garantie, tu peux toujours manipuler des pointeurs qui font n'importe quoi, et rien ne t'empêche de le faire. Y'a une énorme différence entre : "t'es pas obligé" et "tu peux pas". Genre en tant qu'utilisateur, je peux obtenir un certain nombre de garantie de la part d'un exécutable .NET, alors qu'un exécutable écrit en D, si le concepteur a voulu faire un truc malveillant...
Je ne parle même pas du framework de sécurité sous-jacent présent dans .NET par exemple, qui permet d'attribuer des droits différents à chaque composant de la plateforme pour toutes les applis.
en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code
Faux problème : .NET a été conçu dès la base pour être utilisé en mode AOT (Ahead of Time) : la compilation JIT est faite une fois pour toute, l'exécutable natif est conservé en cache jusqu'à mise à jour.
franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows,
Windows ca tourne sur x86 mais aussi x64 et pleins de plateformes embarquées où est présent le framework .NET sous différentes formes.
De plus dans des scénario de remoting (Java RMI, .NET remoting), une compatibilité binaire reste indispensable.
[^] # Re: mon avis
Posté par left . Évalué à 3.
Mouais, une certaine seulement. Je ne parle pas de C# car je ne connais pas du tout, mais pour ce qui est de java:
- c'est effarant le nombre de programme qui terminent avec une stack-trace dy type 'Null Pointer Exception' et consorts
- les cast sauvages d'un type vers un autre existent plus en java qu'en C++: ils sont imposés par les API de certaines classes basiques (voir la doc de la class Array par exemple). Les templates, ça n'existe que depuis très peu de temps.
Donc la sécurité en java, c'est quand même pas terrible ....
[^] # Re: mon avis
Posté par ndesmoul . Évalué à 3.
Je te signale qu'il vaut mieux que ton programme te retourne un null pointer exception plutôt qu'il fasse n'importe quoi et qu'il accède à un espace mémoire où il n'est pas sensé aller. En C si tu as de la chance tu as un coredump. Mais parfois ça passe avec des conséquences difficilement prévisibles.
Si tu as une telle exception c'est que le programme est buggé mais il va pas foutre le bordel ailleurs.
De même que dès qu'il y a un dépassement de tableau un programme Java va te sortir une exception (ou te donnant même la ligne de code incriminée ce qui est bien pratique...). En C parfois ça passe et d'autres fois non. Quel est le plus sûr ici à ton avis?
Enfin quel est le problème avec les cast? En C il n'y a pas de vérification. En Java si et tu ne peux pas faire n'importe quoi. Encore une fois Java qui est un langage à typage fort est bien plus sûr à ce niveau.
[^] # Re: mon avis
Posté par パパフラクス . Évalué à 2.
Mais en même temps je ne vois pas trop une autre façon de faire, sans impliquer les generics, ou l'inférence de types.
[^] # Re: mon avis
Posté par lasher . Évalué à 2.
[^] # Re: mon avis
Posté par パパフラクス . Évalué à 2.
Les templates, ça n'existe que depuis très peu de temps.
Je me suis mis dans le contexte java < 1.5 car il me semble que c'est ce à quoi le monsieur faisait référence.
Il est vrai que ce problème est aujourd'hui grandement résolu.
[^] # Re: mon avis
Posté par Goth . Évalué à 3.
Il existe également les : static_cast, reinterpret_cast et le const_cast.
[^] # Re: mon avis
Posté par パパフラクス . Évalué à 2.
Pour le cast, c'était une manière de gérer le polymorphisme sns les generics.
Maintenant les generics permettent de faire propre pour les collection, mais apportent d'autres soucis (lisibilité, complexité, etc.)
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Ben la sécurité justement, c'est que le framework Java ne va pas planter lamentablement et compromettre le système :) De plus cette exception est un cas "normal" qui peut être traiter sans problème. Bref c'est pas un segfault ;)
Tu confonds fiabilité et sécurité.
Les templates, ça n'existe que depuis très peu de temps.
Les templates en Java n'existe pas. Les templates en C/C++ sont une vraie daube au niveau sécurité comparé à la généricité de .NET : les templates n'ont aucune "vie" à l'exécution, c'est du sucre syntaxique proposé par le compilateur. Et ca ne t'empêche pas de faire n'importe quoi.
[^] # Re: mon avis
Posté par alice . Évalué à 2.
Si.
Quel est le rapport entre les templates et la sécurité?
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Non. Y'a les types génériques, mais pour moi ca n'a pas grand chose à voir d'un point de vue technique, même s'il y a des points communs au niveau utilisation/syntaxe.
C'est pas pour rien que ca s'appelle pas template dans le monde Java/.NET.
Quel est le rapport entre les templates et la sécurité?
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 0.
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
En fait je me corrige, ca a quand même un rapport avec la secu : comme beaucoup de problèmes de fiabilité dans un programme écrit en C/C++, cela engendre un problème de sécurité potentielle dont il est difficile d'évaluer les conséquences. Exemple typique de problème de sécu lié à un problème de fiabilité du code écrit : un débordement de tampon.
Les plateformes modernes de type Java/.NET propose des barrières pour éviter qu'un problème de fiabilité (nullpointerexception, indexoutofrange) ne devienne un problème de sécu.
Evidemment, quand je dis problème de sécu, c'est qui pourrait compromettre une autre partie du système que ce que le programme est autorisé à faire lui même. Ca n'enlève pas les problèmes de sécu interne au programme :) (bien que Java/.NET propose d'autres mécanisme pour se prémunir contre ce genre de chose, genre les chaînes de caractères immutables, pas de débordement de tampon, etc.) sans qu'il y est bien sûr une quelconque garantie.
[^] # Re: mon avis
Posté par alice . Évalué à 5.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Je prenais juste un exemple plus parlant et très répandu de faille de sécu.
Tu peux très bien imaginer un template qui prend un type en paramètre. A l'exécution, tu passe autre chose avec un bon gros cast bourrin. Hop le code généré par le template travaille avec une donnée non prévu dans le code source. On peut imaginer tout et n'importe quoi comme problème : débordement de tampon, accès à une adresse illégale, etc. Et certaines erreurs de ce type sont réputés pour conduire potentiellement à des failles de sécu.
[^] # Re: mon avis
Posté par alice . Évalué à 4.
Les types passés aux templates sont résolus à la compilation, donc ton cast bourrin tu peux le faire aussi bien sur du code avec ou sans template. Donc ça n'a rien avoir. Je pense que tu n'as pas compris ce qu'est un template.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Si ca a à voir. Parcque tel qu'est implémenté les types génériques par exemple en C# (désolé, je parle de ce que je connais), tu pourras pas faire ce genre de connerie : le runtime a connaissance du type générique et des types en paramètres.
Voilà le rapport. Les templates C++, une fois l'étape de compilation passée, plus aucun contrôle possible.
[^] # Re: mon avis
Posté par alice . Évalué à 2.
[^] # Re: mon avis
Posté par lasher . Évalué à 5.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Comme précisé plus bas, il y a une vérification de type possible avec les trucmachin_cast. (le runtime RTII de C++ s'occupe de ca). Ben avec les templates c'est pas possible. le design des templates empêche donc bien toute vérification à l'exécution.
[^] # Re: mon avis
Posté par alice . Évalué à 2.
[^] # Re: mon avis
Posté par left . Évalué à 3.
RTII RTTI, ça veut dire RunTime Type Information. Mais le RTTI ne s'ocuppe de rien du tout: ce n'est pas un processus, tout au plus un mécanisme qui permet une vérification dynamique de type (et qui ne sert qu'au dynamic_cast, les autres static_cast et const_cast n'en n'ont pas besoin).
Ben avec les templates c'est pas possible.
J'ai rien compris (et je crois que t'es pas loin derrière moi ;). Qu'est-ce qui n'est pas possible avec les templates en C++ ?
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben je partais du principe que qu'un type template avait une signature "générique", et donc que les infos RTTI à l'exécution auraient autoriser un dynamic_cast. En fait non c'est l'inverse, y'a bien une signature de type différente pour 2 instanciations d'un même template avec 2 types différents, et le dynamic_cast foire.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc effectivement, les templates ne sont pas un problème particulier pour la sécu, c'est bien le cast qui est effectivement dangereux.
[^] # Re: mon avis
Posté par Jerome Alet (site web personnel) . Évalué à 2.
[^] # Re: mon avis
Posté par alice . Évalué à 1.
[^] # Re: mon avis
Posté par Jerome Alet (site web personnel) . Évalué à 0.
[^] # Re: mon avis
Posté par atlexx . Évalué à 1.
[^] # Re: mon avis
Posté par alice . Évalué à 4.
[^] # Re: mon avis
Posté par atlexx . Évalué à 1.
[^] # Re: mon avis
Posté par Troy McClure (site web personnel) . Évalué à 2.
A l'origine quand les templates on été introduits dans c++ c'était bien le but recherché: permettre au compilateur de faire un maximum de boulot des la compilation pour gratter sur le temps d'exécution (en vertu de la croyance très répandue selon laquelle le compilateur tout-puissant prend toujours la bonne décision d'inlining, d'élimination de variables intermédiaires etc..). Maintenant appeler ça du sucre syntaxique je trouve que tu pousses le bouchon un peu trop loin, les templates du c++ sont quand même turing-compliant et dans la mise en oeuvre ça ressemble plus à de la mélasse syntaxique qu'à du sucre
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Parcque tu prends ca au sens négatif :) Ca a certains avantages, c'est très puissant (turing compliant toussa), mais concrêtement ca reste du sucre syntaxique : dans le code exécutable produit, ca n'a aucun d'impact.
La preuve la plus flagrante, c'est que ca s'exporte pas. Tu peux pas faire une lib binaire qui "exporte" une classe template. Tout se passe comme tu le précise à la compilation.
[^] # Re: mon avis
Posté par Littleboy . Évalué à 1.
[^] # Re: mon avis
Posté par Pierre Tramonson . Évalué à 2.
[^] # Re: mon avis
Posté par left . Évalué à 2.
[^] # Re: mon avis
Posté par パパフラクス . Évalué à 3.
En tout cas pour moi, le "run everywhere " de Java s'est toujours vérifié, et je n'ai jamais été embêté par des problèmes de portabilité. C'est un des atouts majeurs de Java. J'ai ouï dire qu'il n'en était pas de même dans l'embarqué, mais je ne l'ai pas expérimenté moi-même.
Pour ce qui est de la normalisation, je ne suis pas sur de ce que ça apporte, Ruby et Python vivent bien sans être normalisé..
Je ne sais pas si la normalisation peu y faire quelque chose,
mais pour Ruby, le fait qu'on ai pas de vrai visibilité sur l'avenir du langage me parait un gros point faible. je trouve la doc assez faible aussi, mais je pense que c'est l'esprit de la communauté.
Pour Python, Guido gère très bien l'évolution de son langage, la normalisation n'apporterait sûrement pas grand chose. La doc est excellente.
Donc oui, il y a moyen de faire correctement les choses, sans normaliser.
[^] # et le mien
Posté par Matthieu Lemerre . Évalué à 4.
Ce dont 99% du code ecris se moque royalement. Et pour le reste, ca concerne
la programmation systeme, justement impossible en C#/Java.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Si tu penses a typeof/instanceof, il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux. Donc la machine virtuelle ne sert toujours a rien
Les slims binaries sont une solution bien plus interessante que la compilation
dans une machine virtuelle pour ca.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
du genre "pouvoir s'attacher a un programme en cours d'execution", tu peux faire ca sans machine virtuelle, c.f. Common Lisp, ou meme GDB.
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Si on regarde un language comme Common Lisp, qui compile en code natif et a toutes les features dont tu parles, on s'apercoit vraiment de l'inutilite de la machine virtuelle.
Enfin c'est mon avis.
[^] # Re: et le mien
Posté par GuieA_7 (site web personnel) . Évalué à 3.
La portabilité (binaire avec bytecode - ou directement avec le source) + le sandboxing, ça peut être très utile, même en utilisant que des Logiciel Libre, même sur un desktop. Par exemple, dans ton browser, y a éventuellement du Java, du javascript, et tu es bien content que ça soit portable et sanbboxé(tu comprend bien que "chrooter" ton browser, c'est pas la panacée). Non je milite pas pour plus de java/javascript sur le web, c'est un exemple. Mais on pourrait en trouver d'autres. Par exemple un genre de BOINC, qui téléchargerait des calculs à faire, mais sans avoir besoin de devoir faire confiance à un binaire qu'on ne télécharge pas grâce à sa distribution. Ou un serveur de jeu, qui enverrait des règles spécifiques à une map. etc...
Donc même dans un environnement libre, avoir du code mobile peut avoir du sens (il suffit de savoir qu'on peut le faire, et les idées viennent !!). Et utiliser l'os pour chrooter toutes ces applis n'est pas une solution viable. Mais bon je t'accorde que toutes les applis n'en ont pas besoin. Et que si besoin est, le coeur de l'appli peut être codé en C par exemple, mais charger à côté une VM pour exécuter uniquement le code mobile.
(ah oui et le remoting c'est pour faire de l'appel de fonctions/méthodes à distance ; ça peut être confortable pour le programmeur ; mais pour l'utilisateur là ça ne change rien).
[^] # Re: et le mien
Posté par Matthieu Lemerre . Évalué à 2.
d'arbres de syntaxes abstraites compresses, qui portent plus d'information, et
sont plus denses que du code binaire compile pour une machine virtuelle.
Ils sont donc plus petits et permettent une compilation plus optimisee; par contre le temps de compilation est plus long, donc ca ne convient pas bien pour l'embarque.
Et utiliser l'OS pour chrooter toutes les applis, si c'est une solution viable. Enfin pas dit comme ca. Sous Linux/BSD ce genre de concept n'est pas vraiment bien integre (enfin avec SELinux ca s'arrange un peu), mais ca n'a rien de complique,
c'est fait depuis les annees 70 dans les capability machines, ou plus modernement dans OS.
L'idee c'est que plutot que de donner aux applications le droit de tout faire par defaut (open environnement), on leur donne le droit de ne rien faire, et on leur ajoute des droits au coup par coup. Du coup si on raisonne comme ca, faire du sandboxing c'est trivial: il suffit de donner peu d'acces aux services de l'OS, plutot que d'interdire plus.
Merci pour le remoting; je vois pas trop l'interet par rapport a CORBA. En C++ on peut tout aussi bien cacher le fait qu'un appel de methode se fasse a distance qu'en C# a mon avis.
Donc je me maintiens: les virtual machines, ca sert a rien (sauf dans qq cas, comme l'embarque). D'ailleurs si Microsoft ne faisait pas windowsCE /windowsphone/ou autre vision sur l'embarque, ils n'auraient surement pas fait .NET comme ca je pense.
[^] # Re: et le mien
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Pourtant, tu te contredis légèrement, puisque tu dis 'ca sert à rien' puis 'sauf dans qq cas'. Je pense qu'on va aller dans un monde avec plein de machines très différentes interconnectées (station, pda, téléphone) donc ces quelques cas font que si ça ne marche pas partout, c'est génant (c'est comme dire que si ça marche pour win ça marche presque partout...). Mais bon dans l'ensemble on est assez d'accord au final : on peut se passer de VM la plupart du temps (beaucoup de programmes ne perdraient pas de feature, et gagneraient en perf, à être réécrits dans un langage sans VM par exemple).
Pareil pour le sandboxing : le faire de manière identique sur tous les OS, pour une portion de code (et pas un processus en entier) et à l'heure actuelle, sans java/.NET(/autre?), et bien c'est pas possible. Et que dans l'absolu, ça soit possible, ça ne change au final pas grand chose. Donc je maintiens que si on a besoin de sandboxing (c'est à dire pas souvent, je te l'accorde), pour l'instant la VM est le seul salut.
Quant au remoting, oui j'ai précisé que cétait juste un confort pour le programmeur (la comparaison avec Corba est bonne).
[^] # Re: et le mien
Posté par Matthieu Lemerre . Évalué à 1.
Et moi que non;) : il "suffit" de verifier que le code respecte certaines proprietes avant de le compiler. Ce n'est pas possible pour un language comme C, mais par exemple c'est assez simple de verifier un language comme Haskell comme etant sur avant de le compiler et de l'executer; donc pas de VM dans ces cas la.
Dans des cas extremes, tu as par exemple des OS extensibles qui verifient du code, le compilent eux meme avant de l'installer directement dans le noyau. SPIN fait ca par exemple.
Quant aux langages a la C ... Defi releve pour mon langage, L! (petit coup de pub: http://www.nongnu.org/l-lang )
[^] # Re: et le mien
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Je vais mater ton langage avec attention.
Sinon tu as fini par dire que sans vm le langage devait être sandbox-ready (dans la pratique), donc ce n'est pas l'OS qui assure tout seul le sandboxing (auquel cas le langage n'importerait pas).
(merci encore pour cette discussion fort intéressante)
[^] # Re: et le mien
Posté par Matthieu Lemerre . Évalué à 1.
Merci, merci :)
Je dirais plutot : dans les OS "courants" que dans la pratique. Et ca permet d'avoir une solution generique, multi plateforme. Maintenant, la place logique de ce genre de mecanismee est l'OS, et le fait qu'il faille l'implementer dans le language est dommage, et moins sure.
Merci a toi, c'est toujours interessant de se repreciser.
[^] # Re: et le mien
Posté par Guinns . Évalué à 1.
"le temps de compilation est plus long, donc ca ne convient pas bien pour l'embarque."
A quoi ca sert d'avoir un temps de compilation rapide quand on fait de l'embarqué ?
Pour moi c'est surtout le temps d'éxécution qui est important, car même si ca prend une semaine à compiler, peut importe, il suffit que le résultat de la compilation soit prêt le jour de la livraison ...
[^] # Re: et le mien
Posté par Matthieu Lemerre . Évalué à 1.
La quand je parle d'embarque c'est du gros "embarque" genre telephone portable java, pas du controle commande d'un four micro onde. Deja pour que ca aie un interet il faut telecharger du code dynamiquement sur la plateforme embarquee, c'est donc utile uniquement pour les "jouets" modernes.
[^] # Re: et le mien
Posté par taratatatata . Évalué à 2.
C'est plus ou moins ce qu'a fait Microsoft dans Vista, the user friendly way. Pas la panacée dis-tu ?
[^] # Re: et le mien
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Sinon as tu des infos supplémentaires ?? Peut-on dans Vista 'chrooter' une simple classe par exemple, et pas un thread en entier (il me semble avoir lu que sous win on a des droits avec une granularité au thread près) ??
[^] # Re: et le mien
Posté par TImaniac (site web personnel) . Évalué à 1.
Y'a pas que pour le programmeur qu'il y a un intérêt, mais aussi pour l'utilisateur : la couche d'abstraction vis à vis de matos est le meilleur moyen d'avoir une compatibilité binaire. On le voit facilement par exemple avec le passage au 64bits : le matos et l'OS est obligé de se coltiner un mode "legacy" 32 bits juste pour faire marcher de vieilles applis. Les appli .NET/Java tournent out of the box sur une machine 64 bits.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Et ben c'est pareil que pour le problème de matos : les instructions machines du proc sont limitées et le code associé y est fortement lié : le modèle de sécu de .NET par exemple est bien plus avancé en terme de gestion de droits que ce que propose l'OS. Les 2 sont complémentaires, l'OS gère tout ce qui concerne les droits au niveau processus, le framework .NET travaille plutôt au niveau des assemblies.
Et puis y'a des choses que l'OS ne peut pas faire : un débordement de tampon qui se fini par une appli avec du code injecté, ben l'OS aura beau limiter ses droits, si l'appli avait ne serais-ce que les droits utilisateurs, paf, accès à des données sensibles, toussa. Et ca l'OS ne peut pas le faire car un débordement de tampon, ce n'est que finalement une fonctionnalité offerte par le langage C qui t'autorise à taper n'importe où dans l'espace mémoire du processus.
De plus la granularité est beaucoup plus fine : je peux faire du sandboxing interne : pleins d'applis sont développées avec un mécanisme de plugin, tu trouverais ca normal qu'un plugin "tiers" fasse planter une appli critique ? Non, ben tu l'isoles, dans le doute, c'est pas ton code, il peut être une sour ce de bug supplémentaire, je sandbox, et l'OS ne peut rien y faire.
il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux.
Sauf que là c'est proposé out of the box, ca marche avec tous les types, c'est un modèle complètement objet this.GetType().GetBaseClass().FindMethod("trucmuch"), tu vas t'arracher en C.
Aller petit exercice : je te files une classe C++, et tu me génères dynamiquement un proxy sur une instance de cet objet, et bien sûr tu rajoutes au milieu une connection TCP.
Donc la machine virtuelle ne sert toujours a rien
T'as pas bien compris ce qu'est une machine virtuelle. La machine est "virtuelle". Dans le cas de .NET/Java, une partie de la vue virtuelle c'est la représentation de ces données, et en l'occurence des objets.
Poussons le raisonnement que tu proposes, à savoir :
1 - je rajoutes systématiquement une info de type à la structure pour pouvoir l'identifier.
2 - je veux maintenant que ca soit fait automatiquement sur mes objets, je fais donc en sorte que ca soit fait par le compilo et qu'un support à l'exécution soit présent : c'est le runtime RTTI que propose C++. Déjà, le langage C++ propose dans ce contexte un semblant de vue qui n'est pas uniquement des "bits" en mémoire comme en C, on a un début de machine virtuelle.
3 - je veux des infos sur tous les membres objet par introspection
4 - allez je veux même le code de tous les membres objet par introspection
5 - j'ajoutes donc un tas d'infos sur le code lui même : au final j'ai construit une couche d'abstration complète de mon code, j'ai créé un nouveau modèle de machine virtuelle.
Tiens d'ailleur au passage je me dis que le code natif ne sert plus à rien dans l'histoire, on peut le regénérer à partir du code virtuel puisqu'il contient toutes les infos. hop je le vire, il sera traduit en code natif au dernier moment : JIT.
Ah oui, et le C dans l'histoire, ne fera que rendre ta solution bancale, non standard : rien n'empêche un couillon (ou bêtement un bug si fréquent) d'aller écraser l'info de type dans ta structure. Pouf, tout ton code après s'écroule comme un con. D'où l'intérêt d'avoir un modèle beaucoup plus contrôlé.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
Des trucs du genre : j'instancie à distance un objet dans un autre processus sur une autre machine par exemple, et je la manipule comme si elle était en local (bref cas typique d'une application répartie avec des composants objets).
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Alors pourquoi D ne propose pas les mêmes fonctionnalités en terme de sécu, d'introspection et tout le tralala ?
Pourquoi personne n'a encore fait de super langage sans machine virtuelle et qui concurrence Java & Co ?
Pourquoi on doit encore se taper ce con de C dans l'embarqué (malgré ce que tu dis, car souvent dans l'embarqué, les perfs sont primordiales)
Si on regarde un language comme Common Lisp, qui compile en code natif
Gni ? Et ? .NET compile en natif. Java compile en natif. Tu crois que Common Lisp ne propose pas par hasard un modèle de représentation des données virtuelles qui lui est propre ? Tu crois qu'il n'y a aucun service dynamique à l'exécution pour pallier les impossibilités d'introspection du langage natif ? Tu crois que common lisp te permet de faire de memcpy et autre bidouille en partant du principe que tu attaques physiquement une zone mémoire ou bien Common Lisp te propose une abstraction totale de la machine physique ? Tu crois que tout ca c'est pas caché dans ce qu'on appel généralement une machine virtuelle ?
# Et voilà
Posté par riri le breton (site web personnel) . Évalué à 4.
Blague mise à part, c'est très bien que ce langage ait un numéro de version de la famille du stable (1.x) ; je pense que cela va permettre une meilleure promotion du langage (et des outils), et donc de faire accroître le nombre de libs.
Je suis utilisateur C++ principalement, et si pour l'instant, on ne va pas me faire changer facilement, je dois avouer que lorsque D a commencé à montrer le bout de son museau, ça m'a pas mal attiré - mon bloquage à l'époque était le manque de stabilité des spécifications et un manque cruel de compilateur sous GNU/Linux.
J'essayerai sûrement un jour ou l'autre. Bonne dépêche simple et précise qui me fait penser à tester ça.
# Un peu de sérieux que diable
Posté par phentex . Évalué à 0.
[^] # Re: Un peu de sérieux que diable
Posté par dco . Évalué à 2.
[^] # Re: Un peu de sérieux que diable
Posté par Aurélien Jarno (site web personnel) . Évalué à 2.
[^] # Re: Un peu de sérieux que diable
Posté par phentex . Évalué à -1.
[^] # Re: Un peu de sérieux que diable
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
# lim_t→∞lang(t) = Common Lisp
Posté par edeion . Évalué à 7.
« As computers have grown more powerful, the new languages being developed have been moving steadily toward the Lisp model. » (Paul Graham, mai 2001, http://paulgraham.com/rootsoflisp.html)
[^] # Re: lim_t→∞lang(t) = Common Lisp
Posté par judicael . Évalué à 10.
Exemple ici :
* templates : un mécanisme à pleurer quand on a un minimum joué avec des systèmes de modules paramétrés comme ceux de SML ou d'Objective Caml ou même tout simplement quand on a utilisé un langage avec des fonctions polymorphes (ML et l'essentiel des langages typés dynamiquement).
* tableaux dynamiques : devraient faire partie de la bibliothèque du langage, pas du langage lui-même (pour la syntaxe, les macros de LISP permettent de faire ça très bien, on peut s'en sortir également très facilement en Caml)
* "scope guards" : typiquement un truc qui se fait en 3 lignes de code de bibliothèque. En O'Caml le code pour l'équivalent du try finally présenté donne la chose suivante :
let abc() =
let m = Mutex.create() in (* un peu bizarre de faire un mutex localement, a priori, il devrait plutôt être une variable globale, mais bon *)
Mutex.lock(m);
try foo() with e -> (Mutex.unlock(m); raise e)
Mutex.unlock(m)
Maintenant je m'aperçois que ce motif revient un peu trop souvent. Comment faire mieux ? C'est tout simple, il suffit d'écrire le motif en paramétrant par foo :
let with_lock f =
let m = Mutex.create() in
Mutex.lock(m);
try f() with e -> (Mutex.unlock(m); raise e)
Mutex.unlock(m)
Et je peux maintenant écrire abc en une ligne :
let abc() = with_lock foo
Si "foo" est un block de code et non une fonction prenant () en argument, on utilise une simple fonction anonyme :
let abc() = with_lock (fun () -> begin
Printf.printf "Hello world\n";
Printf.printf "Hello DLFP\n";
end)
À côté de cela, on retrouve en D les unions du C (je n'ai pas testé, mais ça a bien l'air d'être ça) alors que clairement, les types sommes qu'on trouve en ML (depuis plus de 20 ans) sont extrêmement utiles. Les types sommes, c'est tout simplement des types unions dans lesquels on peut savoir quelle variante de l'union on a prise.
Ex en Caml :
type figure = Roi | Dame | Valet (* là, c'est juste un type énuméré *)
type carte = Valeur of int | Figure of figure (* une union de figure et int, avec une étiquette (Valeur ou Figure) pour dire dans quel cas on est *)
Mettons qu'on donne au roi la valeur 4, aux autres figures la valeur 0 et aux cartes numérotées le nombre qui y est inscrit. On peut calculer ça comme suit :
let valeur carte = match carte with
| Valeur n ->
| Figure Roi -> 4
| Figure _ -> 0
Cet exemple est évidemment inintéressant mais dès qu'on fait un peu d'algorithmique, il est très pratique de manipuler des structures de données ou une valeur peut être une feuille ou un noeud...
Un des problèmes avec LISP (ou ses variantes comme Scheme), et ML (et ses variantes SML, Objective Caml, ...) est qu'il faut accepter de rentrer dans un modèle qui a été pensé au départ par des théoriciens, universitaires de surcroît (quelle tare !). Pour ma part, je suis tombé dans la marmite dans mon jeune âge mais, bien qu'étant curieux, je n'ai encore pas trouvé de langage équivalent à ceux de cette famille... (pour être précis, les langages plus connus ont des avantages en termes de bibliothèques, d'environnement de développement, mais les langages en eux-mêmes sont nettement, nettement moins fun...)
[^] # ANSI Common Lisp
Posté par edeion . Évalué à 4.
[^] # Re: lim_t→∞lang(t) = Common Lisp
Posté par Sufflope (site web personnel) . Évalué à 2.
| Valeur n -> n
bien sûr. Ah OCaml en prépa c'était bien marrant mais plus qu'extrèmement succint :)
[^] # Re: lim_t→∞lang(t) = Common Lisp
Posté par judicael . Évalué à 3.
Effectivement, un des problèmes de l'enseignement de Caml, c'est qu'on l'utilise en prépa, sous une forme ancienne (caml-light au lieu d'Objective Caml), et pour rarement pour des exemples comme ceux des langages de script. Pourtant PCRE existe en Caml, on peut accéder à un certain nombre d'appels systèmes Unix, de façon portable entre les différents Unix, et pour la plupart des appels, aussi sur MS-chose. Et quand on n'a pas ce qu'il faut, on peut interfacer avec du C, du Java, ou même du Perl...
Et avec tout ça, on a un interpréteur (toujours très pratique, ceux qui utilisent des langages de scripts savent de quoi je parle), un compilo vers du byte-code portable et porté à peu près sur tous les Unix, et un compilo natif. Il y a aussi un debugger, pas forcément facile d'accès au départ (interface graphique : emacs) mais qui autorise le voyage dans le temps : le programme lève une exception après 123456 étapes élémentaires d'exécution ? Ok, je vais voir ce qui se passe 20000 étapes avant... Je ne connais pas beaucoup de debuggers qui font ça.
# Kenta Cho
Posté par Rémi Pannequin . Évalué à 3.
Ses jeux sont libres (ils utilisent openGl, SDL, Vorbis, BulletML, etc...). Ils sont très originaux ; ça vaut le détour.
Le problème c'est que le compilo D de digital Mars pour linux n'étant pas open-source, ces logiciel ne peuvent être facilement inclus dans les distributions (par exemple dans debian [2]).
Alors je me demande, puisque le langage se stabilise, et que l'on nous parle d'une intégration à gcc, est ce qu'on va avoir des paquets de ces tout-supers jeux ? Plus généralement, les applis développées en D vont elles devenir plus accessibles ?
[1] http://fr.wikipedia.org/wiki/ABA_Game
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259063
# Torus Trooper
Posté par Gniarf . Évalué à 4.
http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html
(port Linux) http://www.emhsoft.com/ttrooper/
il y en a quelques autres mais moins remarquables
# GDC 0.21
Posté par niclone (site web personnel) . Évalué à 3.
http://dgcc.sourceforge.net/
Cette version est basé sur DMD 1.0
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.