Oui bien sûr, je suis d'accord... le sens de ma remarque était plutôt qu'un simple Hello World qui ressemble à celui de n'importe quel autre langage ne révèle pas grand chose sur le langage.Envoyé par Fanvan
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Oui bien sûr, je suis d'accord... le sens de ma remarque était plutôt qu'un simple Hello World qui ressemble à celui de n'importe quel autre langage ne révèle pas grand chose sur le langage.
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Avec des exemple directement sur la première page. Que demander de plus?
A part ajouter à la confusion, qu'apporte ce langage ? Est-ce qu'il était impossible d'adapter lua, ou ruby ou python (ou cython pour du python+declaration de type) ?
Après avoir créé Go et unladen-swallow, il y a maintenant dart. Je me demande si il y a une vraie politique derrière ou si ils changent de direction en fonction du sens du vent ?
C'est vrai, mais concrètement, si l'idée derrière dart est d'envoyer JavaScript aux oubliettes, je les vois mal annoncer : "Tous les développeurs web du monde ont des problèmes de JavaScript. OK, nous chez Google, pour remédier à cela, on a une solution à laquelle personne n'avait pensé et qui va changer la vie de millions de gens : on va passer tous nos scripts en Python. Nous avons d'ailleurs mis au point un interpréteur Python pour Chrome. Le reste de l'univers va nous suivre et bientôt, on fera de belles funérailles à JavaScript", ça ferait bien rire tout le monde.
La seule façon de tuer JavaScript, c'est avec quelque chose de nouveau, qui suscitera la curiosité et peut-être l'engouement, et pas avec un langage plus vieux que JS lui-même. En cela, il y a dans dans dart une manœuvre aussi marketing que technologique.
Le soucis : la compatibilité.
Un énième activex, xul, ou encore Flash qui n'est pas portable parce que nécessite une installation. Ceux qui auront Chrome, cool pour eux, mais foutu pour les autres.
Désolé, je n'adhère pas.
Je préfère prêcher pour une évolution de JS et pour former correctement les développeurs qui l'utilisent souvent n'importe comment sans avoir pris la peine d'essayer d'en comprendre les subtilités.
Le soucis : la compatibilité.
Un énième activex, xul, ou encore Flash qui n'est pas portable parce que nécessite une installation. Ceux qui auront Chrome, cool pour eux, mais foutu pour les autres.
Désolé, je n'adhère pas.
Je préfère prêcher pour une évolution de JS et pour former correctement les développeurs qui l'utilisent souvent n'importe comment sans avoir pris la peine d'essayer d'en comprendre les subtilités.Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+ (d'autres navigateurs suivront).- Pour notre projet Web, il faut utiliser Dart pour le côté client, c'est super !
- Et c'est compatible avec IE ? Tu sais, le navigateur utilisé par 40% des internautes dans le monde.
- Non.
- Bon ben c'est non alors. Retourne à ton JavaScript !
Donc pas de problème de compatibilité
Je ne suis pas sûr que le but soit de "tuer javascript", ce qui me semblerait un poil trop ambitieux, vu la quantité de code existant dans ce langage. C'est plus d'apporter une alternative crédible et mieux pensé à ce langage, mais aussi je pense de fournir un laboratoire d'idées qui pourront, si elles s'avèrent bonnes à l'usage, éventuellement être intégrées dans les futures évolution de js.
La question qui se pose maintenant est de savoir si Dart offre suffisamment d'avantage comparé à js pour ne serait-ce qu'intéresser les programmeurs (avoir le tampon Google ne suffit pas forcément à rendre un langage intéressant, voir Go).
Le peu que j'ai vu ne m'a pas vraiment fait l'effet d'un truc révolutionnaire. Effectivement, le scoping est lexicale et non dynamique, mais la nouvelle version de javascript en mode strict le permet déjà.
Peut être que le modèle objet aura l'air plus familier aux habitués de Java et confrères. En revanche je n'ai pas eu l'impression que le langage vienne directement avec des capacités d'exploration du DOM supérieur à celles de JS, qui auraient pu rendre des bibliothèque tels que jquery plus ou moins inutiles, et entrainer de gros gains de performances. Bien sûr, il y a des sucres syntaxiques "amusant" comme les seteurs et geteurs.
Enfin, le système de type optionnel me parait assez peu intéressant. Dans l'idée, ça me semble bien de laisser les gens qui le veulent hacker en dynamique (même si je reste personnellement convaincu qu'un langage fortement typé n'est pas un problème pour le prototypage, ce n'est pas l'avis de la majorité, et la majorité a, dans une certaine mesure, forcément raison). Mais je n'arrive pour l'instant pas à percevoir l'intérêt d'ajouter des types. De ce que j'ai lu, ça rajoute l'emmerdement du typage explicite, à savoir la verbosité (qui, faut-il le rappeler, n'est pas un mal obligatoire des systèmes de types, l'inférence, ça existe), sans apporter masse des avantages, à savoir une capture statiques d'un certaine classe d'erreurs, des gains de performances et la "documentation" nécessairement à jour. Ici, les types ne sont "vérifiés" qu'à run time, et rien n'empêche moralement d'écrire n'importe quoi (donc exit la "doc à jour"). En plus ils expliquent que les vérifications de type en question sont trop lourdes pour être effectuées à runtime, donc il faut le faire uniquement en mode développement, et les désactiver en prod.
En gros, leur système de type optionnel me semble être tout au plus un forme très pauvre de contrat dynamique (je rappelle que les contrats permettent d'exprimer des propriétés nettement plus intéressantes, telle que "un entier pair" ou "une fonction qui attend un flottant x et retourne un flottant y telle que y * y ~ x"). Peut être que de "vrais" typeurs feront leur apparition, mais j'ai la triste impression qu'ils ont fait le design du "système de type optionnel" sans vraiment regardé ce qui se faisait ailleurs (les travaux sur le typage de scheme, les liketypes, etc etc). Tout cela m'a l'air très très "naïf".
Toujours dans le domaine du système de type, je n'ai (pour l'instant) rien vu sur les "types natifs", un peu comme ce qui apparait en javascript, qui permet d'allouer des tableaux de données consécutives. Il semblerait donc que Dart se retrouve être encore moins adapté que js comme cible pour un backend de compilateur.
Mais bon, je n'ai pas encore eu le temps de lire toute la spec du langage, donc tout ce que je dis là est sur mes premières impressions, pas sur une étude profonde de la bête !
J'ajouterai que je viens de voir
dans la doc, ce qui est plutôt bon signe !Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called isolates.
An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates. Isolates are created by spawning (10.11).
On peut tout à fait faire coexister 2 langages au sein d'une page ( IE avec VB et Jscript par exemple ) , dont ce n'est absolument pas un problème.Je ne suis pas sûr que le but soit de "tuer javascript", ce qui me semblerait un poil trop ambitieux, vu la quantité de code existant dans ce langage.
Le problème de javascript est que c'est un standard que la plupart des développeurs détestent ,car il n'est pas multiparadigme et n'a absolument pas été pensé pour ce qu'on lui fait faire aujourd'hui.
DART peut fonctionner si les applications DART sont plus faciles à développer que des applications javascripts. Les solutions les plus simples pour le développeur sont toujours les meilleurs. Javascript est complexe car c'est un langage dont le CORE ne répond pas aux soucis du développement moderne.
Oui. Le langage n'a rien de révolutionnaire. C'est toujours risqué de faire un langage innovant ; Google n'a pas voulu prendre de risque supplémentaire : réussir à populariser une alternative à Javascript est déjà un grand défi. Le langage me semble facile à prendre un main, je n'ai pas vu de grande surprise dans les specs. Ce sera plus facile pour les développeurs de l'utiliser que si c'était un langage type Haskell, Lisp ou autre.
Si on reprend les objectifs de Dart, on y trouve :Enfin, le système de type optionnel me parait assez peu intéressant. Dans l'idée, ça me semble bien de laisser les gens qui le veulent hacker en dynamique (même si je reste personnellement convaincu qu'un langage fortement typé n'est pas un problème pour le prototypage, ce n'est pas l'avis de la majorité, et la majorité a, dans une certaine mesure, forcément raison). Mais je n'arrive pour l'instant pas à percevoir l'intérêt d'ajouter des types. De ce que j'ai lu, ça rajoute l'emmerdement du typage explicite, à savoir la verbosité (qui, faut-il le rappeler, n'est pas un mal obligatoire des systèmes de types, l'inférence, ça existe
1) Offrir de meilleures performances
2) Faciliter l'utilisation d'outils (IDE, refactoring...)
Pour ces deux points, le typage explicite apporte énormément.
Dans la course aux performances, les navigateurs sont passés de l'interprétation pure au bytecode puis au JIT. Récemment, ils ont essayé de faire de l'inférence de type pour générer du code meilleur, mais ca reste limité. Avoir de l'information de type statique aide à la génération de code.
Je trouve que le typage optionnel est un très bon compromis. D'un côté, les utilisateurs de Dart (venant donc de Javascript) pourront continuer à avoir du typage dynamique s'ils le souhaitent. Leur imposer du typage statique serait vu comme une régression (tout n'est pas typage statiquement). De l'autre, cela permet d'ajouter l'information de type par endroits, de facon très simple.
Le 2e point est tout aussi important : difficile de faire du refactoring, de fournir de la complétion de code sur quelque chose qui est entièrement dynamique comme Javascript. Google prépare un IDE, qui en tirera forcément partie. De cette facon, les développeurs seront incités à typer leur code, lorsque c'est possible.
Enfin, cela apporte de la sûreté : le code est vérifié à la compilation. Comme exécution et compilation sont mélangées, la différence ne sera pas aussi nette qu'en C, mais les erreurs seront signalées plus tôt qu'avec Javascript. Je suppose qu'il y aura un moyen de vérifier le code aussi (en dehors du navigateur).
Ce qui me gêne pour ma part, c'est la présence de null (qui est une valeur possible pour tous les types). La Billion Dollar Mistake a déjà fait suffisamment de mal...
Si tu penses que j'ai suggéré qu'ils auraient du produire un langage à la Haskell, c'est que je me suis très mal exprimé. Il est clair que je suis un aficionados du typage, et que je pense qu'un typage fort et statique est une excellente chose, et que le typage est une aide bien plus qu'un poids ou une contrainte.
Ceci étant dit, je suis aussi un brin réaliste et pragmatique, et je me rends bien compte que beaucoup de programmeurs ne partagent pas mon point de vue, et aiment les langages dynamiques. Ils offrent une flexibilités et une concision que les langages typés "main stream" n'ont pas, et une facilité de premier accès qu'aucun langage typé n'a. Il me semble donc que l'approche du typage optionnelle est excellente. C'est, si l'on veut, un moyen de montrer la lumière aux utilisateurs de langages dynamiques :p Ca permet d'apporter progressivement et sans douleur la puissance du typage (que ce soit pour les IDE, la vitesse d'exécution, la "programmation guidée par le typage", la détection d'erreur, le refactoring, que sais-je encore) au monde du dynamique.
Ma critique n'était donc pas sur l'idée de faire du typage optionnel, mais bien sur la réalisation de cette idée dans le cas de Dart.
[WARNING]C'est mon coté "académique frustré" qui va s'exprimer à partir de maintenant[/WARNING]
Le typage optionnel n'est pas une idée nouvelle, et de très nombreux travaux ont été fait sur le sujet. Par exemple ceux de Matthias Felleisen et son équipe sur Typed Scheme, qui permet de faire cohabiter du Scheme typé et non typé (et de typer des idioms de scheme à première vu extremement "dynamiques), mais aussi par exemple un papier à POPL l'an dernier sur les like types. Mais il y en a plein d'autres, sur les plugable types, etc etc etc.
Et là pour Dart, qu'est ce qu'on a comme design ? En gros, quelqu'un s'est dit "ce serait bien d'avoir des types optionnels". Donc ils ont mis des types, et ils sont optionnels. Et la solution trouvée pour faire coexister le monde typé et le monde non typé ? C'est facile, en fait les types ne servent à rien \o/ Ils sont tout simplement effacé dans la sémantique du langage. Tu peux mettre n'importe quoi, ça ne change rien. Moralité, un design simpliste à mourir, qui ne poussera pas grand monde à utiliser des types ! On a l'impression d'avoir juste un java où on aurait viré les types, et où on aurait le droit de les remettre, mais où ça ne servirait à rien.
Je sais que le monde de la recherche académique a du mal à produire des solutions viables, des produits finis, etc. Mais quand même, quand on se lance dans le design d'un nouveau langage, regarder un minimum ce qui s'est fait dans le monde de la recherche dans les 20 dernières années, ce serait pas mal
Le compilateur en question est-il déjà présent sur les navigateurs cibles ? Si oui, alors mea culpa (même si pas d'IE pour l'instant est rédhibitoire). Si non, on peut reprendre mon petit dialogue en y ajoutant d'autres navigateurs, et le résultat sera le même.Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+ (d'autres navigateurs suivront).
Donc pas de problème de compatibilité
Présent *sur* les navigateurs ?? Mais rien à voir.. On écrit du code en Dart, on le compile vers javascript, et c'est ce code javascript qui est envoyé au client. Qui ne voit (pour l'instant) jamais le code Dart.
Sympa ce truc, ça a l'air de contenir pas mal de bonnes choses... Mais Traceur et Dart ne sont pas le même langage ; si j'ai bien compris Traceur se veut la prochaine génération de Javascript (plus précisément c'est un compilateur de ce "futur javascript" vers l'actuel)
Dartium : Google publie une préversion de Chrome avec la machine virtuelle Dart
son langage structuré pour le Web
Mise à jour du 17/02/2012, par Hinault Romaric
Google vient de publier une préversion ( technical preview) pour les développeurs de Dartium, un navigateur à base de Chrome qui introduit la machine virtuelle Dart.
Dart est présenté par Google comme un langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé.
L’objectif inavoué de Google est de mettre JavaScript à la retraite en proposant un langage qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel.
Dart s'exécute soit sur une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+, etc.
Cette préversion permettra d’exécuter des programmes Dart directement sur la machine virtuelle Dart incluse dans le navigateur Chrome, en évitant une étape de compilation séparée pour convertir le code.
Google à l’intention après plusieurs tests de la VM Dart, de l’inclure dans les futures versions de son navigateur Chrome.
Pour l’instant, le langage bénéficie uniquement du support de Google, et aucun constructeur de navigateur n’a encore indiqué son intention de supporter Dark. La firme espère néanmoins atteindre un certain stade de maturité avec Dart avant de le soumettre à un processus de normalisation.
Dartium est disponible pour les ordinateurs Mac et Linux. Une version pour Windows sera disponible dans les jours à venir.
Télécharger Dartium
Source : Google
Vous souhaitez participer aux rubriques .NET ? Contactez-moi
Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
Mon blog, Mes articles, Me suivre sur Twitter
En posant correctement votre problème, on trouve la moitié de la solution
Après avoir longtemps testé Dart , même si c'est une solution intéressante , i l il existe plusieurs problèmes ( tel que la nom compatibilité avec les librairies javascript existantes ).J'ai joué un peu pour ma part avec le mini-compilateur-interpréteur sur la page d'accueil. Franchement je trouve cela très prometteur, on voit clairement que ça force un certain respect des types et que la "compilation" détecte un grand nombre de mauvaises utilisations ce qui est d'ores et déjà bon signe pour la productivité et la maintenance. A terme, Dart aura aussi sans doute la possibilité d'encapsuler un bon nombre de petites différences d'implémentation JS entre les navigateurs ce qui augmente encore son intérêt.
Ceux qui comme moi trouvent que javascript est un langage chiant et inmaintenable plus adapté pour faire du bricolage que de réelles applications pourront peut être sérieusement considérer Dart dans quelques temps.
Perso je suis ceci de près.
Etant forcé de faire du javascript , j'ai plutôt choisit d'utiliser Coffeescript , qui lui permet d'utiliser jQuery , etc ... sans problèmes.
Coffeescript est à mon avis un meilleurs compromis entre la necessité d'utiliser javascript et le besoin du dev javascript de fonctions plus avancées , comme la simplification de définition des classes , la correction de certaines erreurs de jeunesse de javascript , etc ...
Enfin , coffeescript fonctionne partout.
Coffeescript est un compromis entre...
Pas un "meilleur compromis", vu que Dart n'est pas du tout un compromis avec la nécessité de faire du javascript...
La nécessité à laquelle Dart s'efforce de répondre c'est celle d'avoir un langage de script pour des interfaces web dynamique.
La non-compatibilité avec les librairies javascript existante - le fait de ne pas faire de compromis avec javascript - lui permet de réellement s'affranchir des lourdeurs de javascript, pas seulement du point de vue du développeur, mais aussi du point de vue du moteur...
Sauf que pour faire du Dart , il faut de toute façon comprendre comment fonctionne javascript, puisque Dart ne sera jamais intégré en natif autre part que dans Chrome.
Utiliser un compilateur n’empêche pas d'avoir des bugs à l’exécution,et même si du débugging pourra être fait dans Chrome en natif, il n'est pas 100% certain qu'un script Dart compilé vers javascript qui fonctionne dans Chrome fonctionnera correctement dans tout les autres navigateurs.
Donc utiliser Dart est un compromis , comme toute solution qui compile vers javascript.
Personnellement , je trouve que la solution Coffeescript a un meilleurs ratio avantages / inconvénients que Dart, puisque Coffeescript n'est qu'une nouvelle syntaxe et n'introduit pas de nouvelles fonctionnalitées, tout en corrigeant certain problèmes grossiers de javascript , et en simplifiant la création de classes et de sous classes. Mais coffeescript ne crée pas 2 mondes incompatibles l'un avec l'autre comme le fait Dart.
De plus , avec la multiplication de l'utilisation de javascript comme moteur de scripts dans des applications ( NodeJs , tout les produits adobe , plusieurs bases nosql , etc ... ) , ne pas pouvoir interroger une API javascript directement avec Dart est un sérieux problème. Ni Coffeescript ni Haxe n'ont cette lacune.
Si tu as raison sur ce point, alors tu as assez raison sur le restepuisque Dart ne sera jamais intégré en natif autre part que dans Chrome
Mais si les développeurs de Dart, et les personnes qui s'y intéressent de près, croyaient que tu avais raison sur ce point, je ne suis pas sur qu'il dépenserait du temps, de l'argent, et de l'énergie sur ce projet...
Je ne crois pas qu'il y ait de sérieux débats sur la question "est ce que javascript est un problème ?", à peu près tout le monde s'entend là dessus...
si une vraie bonne solution était proposée, pourquoi est ce que ça ne serait pas adopté en natif par tous les autres navigateurs ?
Répondre avec citation
Partager