FAQ DartConsultez toutes les FAQ

[Traduction de la FAQ officielle]

Chez Google, nous avons écrit notre part d'applications Web, et nous avons essayé de nombreuses façons d'apporter des améliorations à ce processus de développement, à l'exception d'introduire un nouveau langage. Nous pensons désormais qu'il est temps de franchir le pas. Nous avons conçu Dart afin qu'il soit facile d'écrire des outils de développement adaptés au développement d'applications modernes, et capables d'implémentations de haute performance.

[Traduction de la FAQ officielle]

Nous voulons corriger toutes ces choses. Il y a le langage « Dart » et l'ensemble du projet « Dart ». Ce dernier fait le pari que le langage requiert des changements et nous voulons également améliorer le DOM et autres bibliothèques logicielles, tout en optimisant les outils que nous exploitons.

En même temps, Google parie sur le fait que JavaScript peut évoluer selon les besoins et veut contribuer à cet effort. Google souhaite de grandes choses pour le développement Web, et si cela arrive avec JavaScript alors nous serons heureux.

[Traduction de la FAQ officielle]

Si les gens aiment Dart et l'utilisent, alors oui, dans une certaine mesure, à l'image de toute amélioration significative en développement Web. Rien n'est inné ou 100 % rétrocompatible avec les navigateurs standard, donc les gens utilisent simultanément du nouveau et de l'ancien. Il faut le voir sous cet angle : Google consacre beaucoup d'énergie au développement de Dart tout en supportant intensément JavaScript (outils, implémentation et spécifications). On a choisi de faire ainsi parce que nous pensons que Dart est très prometteur.

Le développement Web côté serveur laisse la place pour beaucoup de langages : est-ce que Python empiète sur Perl, est-ce que Java court-circuite C++ ? Dans une certaine mesure, oui, mais les gens considèrent ceci comme préférable, en tout cas bien mieux que si nous devions tous ne coder qu'en un seul et unique langage. La multiplicité des langages nous a permis une évolution bien plus rapide comparée au processus standard d'évolution d'un seul langage. En outre, les langages coexistent dans différentes niches : est-ce que Groovy concurrence directement C++ ? Confrontés à des problèmes techniques, les développeurs optent pour le langage le plus approprié. En fin de compte, nous pensons que le développement côté client devrait bénéficier de la même flexibilité.

[Traduction de la FAQ officielle]

En décembre 2013, ECMA a créé le comité TC52 afin de publier une spécification standardisée pour le langage Dart.

[Traduction de la FAQ officielle]

Nous les traitons comme le projet V8. Nous suivons les retours et signalements et nous revoyons le code des patchs des contributeurs externes. Un contributeur de qualité peut avoir directement accès aux dépôts du projet. Les ingénieurs de Google travaillent sur le même dépôt et partagent les modifications en mode public. Le projet a généreusement bénéficié de nombreux patchs externes et a accueilli en conséquence de nouveaux développeurs.

[Traduction de la FAQ officielle]

Parlons de la procédure habituelle pour avoir un langage ouvert et normalisé : quelqu'un crée une première version cohérente, les gens la pratiquent et on ne normalise qu'ensuite. Le processus de « normalisation Web » est coutumier de ce procédé permettant l'ajout de nouveautés et dans lequel la standardisation n'intervient qu'après l’expérimentation pratique comme pour la balise <canvas> par exemple. Nous sommes conscients que cette voie soulève des inquiétudes, mais nous pensons qu'elle est utile surtout dans le développement des langages de programmation où le pilotage par comité est risqué.

Le plus récent langage réussi et créé par un comité ouvert a été Haskell, au début des années 1990. Le plus largement utilisé : COBOL, suivi par Ada. Ce n'est pas une voie habituelle pour la création d'un langage de programmation. Parmi les douzaines et douzaines de langages majeurs, plus ou moins six ont été conçus ainsi. (Et l'un d'entre eux était ALGOL-68.)

[Traduction de la FAQ officielle]

Chaque approche a des avantages et des inconvénients, mais nous pensons que dans le contexte de Dart, il a été préférable d'opter pour une machine virtuelle dédiée pour ces raisons :

• Google avait déjà travaillé sur un langage intermédiaire machine : « LLVM bitcode » dans PNaCl ;
• même si la machine virtuelle est spécifique à Dart, un langage intermédiaire machine sera plus simple et rapide à exécuter parce qu'il supporte mieux certaines contraintes, par exemple un contrôle structuré d'exécution. Cette approche facilite l'implémentation générale et améliore les possibilités d'optimisation ;
• un langage intermédiaire machine générique serait plus compliqué et lent dans la mesure où ayant plus de cas de figure à supporter, il rajouterait des fonctionnalités sans intérêt pour Dart comme le multithreading avec une pile partagée ;
• l'absence de machine virtuelle, pour une utilisation réellement polyvalente, oblige à privilégier certaines classes au détriment des autres. Un langage intermédiaire machine laisse la possibilité à la machine virtuelle d'avoir recours à une optimisation en profondeur du langage interprété. Quelques ingénieurs de l'équipe Dart ont écrit un article détaillé sur le concept de machine virtuelle.

[Traduction de la FAQ officielle]

Nous pensons que les développeurs Web devraient avoir le choix. Proposer une nouvelle option, comme Dart, n'implique pas forcément le remplacement d'une option existante.