tanguy_k a écrit 766 commentaires

Non, asm.js est un langage. Il est quasiment impossible de l'écrire à la main certes, mais il s'agit ni plus ni moins que d'un subset de javascript

C'est pas ce que j'ai ecrit dans le journal ? "asm.js est un sous-ensemble de JavaScript, une sorte de bytecode ou langage assembleur"
Pourquoi alors ecrire "Les incompréhensions sur asm.js ont la vie dure" dans ton premier post ?

C'est l'emploi du mot "bytecode" qui te choque ?

pour un gain de perf d'un facteur de l'ordre de 10 je n'ai rien contre lancer une compilation pour tester.

Et si on te propose les 2 : les perfs ET sans compilation ?

mais qu'ils repartent d'un existant

Donc pour Google c'est nul qu'ils n'aient pas repris l'existant malgre les explications donnees.
Par contre pour Microsoft et C#/.NET, aucun probleme c'etait parfaitement justifie.
2 poids, 2 mesures ? un jugement sans connaitre ? de la mauvaise foi ?

Pourquoi ne pas avoir ameliore Java et la JVM, en quoi c'etait impossible ?
=> Parceque MS voulait apporter des nouveautés impossibles avec la JVM

"en quoi c'etait impossible ?", reponse : "apporter des nouveautes impossibles" => Wow ! c'est convaincant comme argumentation !

Tellement impossible que d'apres toi-meme "C# […] fourni la roadmap du langage Java avec 2 ou 3 ans de retard"

Ils sont peut être plus utilisés mais pas meilleurs que les IronRuby, IronPython, Boo, etc.

Personne n'utilise IronRuby alors que JRuby est tres utilise et toutes les grosses gems (sauf rares exceptions) sont testees sous JRuby.
IronRuby n'est plus maintenu depuis plus d'un an cf https://github.com/IronLanguages/main/tree/master/Languages/Ruby et http://ironruby.codeplex.com/releases

Si les langages CLR étaient meilleurs, ils seraient plus utilisés que leurs equivalents JVM, non ?

Quant au terme employé : "Ils sont peut être plus utilisés"…

Ah aussi, pourquoi Google a cree NaCl alors qu'il y a deja asm.js ?

D'apres GitHub, asm.js date de octobre 2012 - premier commit alors que NaCl date de bien avant (activé dans Chrome depuis au moins la version 11 cf http://doom.pdox.net/).
La techno NaCl provient certainement de Chrome OS (2009).

http://www.google.com/trends/explore#q=NaCl%20Google%2C%20asm.js

Le principe de asm.js est particulierement malin, a la facon de RISC vs CISC.

Dans ce sens il est complètement sur le même segment que Dart : un nouveau langage web

Il y a autant de similitudes entre asm.js et Dart qu'entre le bytecode de la JVM et le langage Java.

La reponse a deja ete donnee ici :

(Pour info Native Client (NaCl) de Google a le meme objectif que asm.js cf http://asmjs.org/faq.html)

we don’t really see Dart and Native Client as competing technologies; they are very, very different and Dart is a scripting programming language that is very immediate; you can write your code and you reload your page and its right there, and Native Client is a different kind of technology and it’s great for translating C code to something that runs in your browser. It’s very different, at the core of it.

Cf http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/

---

La question qui vient ensuite a l'esprit est pourquoi ne pas utiliser asm.js en tant que bytecode pour Dart ?
La reponse ici :

Well the problem is it doesn’t work. […] several companies have tried to do multi language VMs and the problem is that […] there’s always compromise you have to make. […] if you are implementing C# or Java, you will have basic types, right? You will have ints and doubles and longs […] in JavaScript you have all updates objects everywhere and it’s very hard to reconcile these two worlds. So if you do a VM based on basic types it’s pretty much impossible to make it run fast if you want to implement JavaScript — and the other way around basically.
[…] if you try to make an implementation of JavaScript, it will be falling into the category we talked about before – dog slow — it’s just not fast.

Plus d'infos dans la FAQ de Dart :

Why didn’t Google build a bytecode VM targetable by multiple languages including Dart?
- Google already works on a multi-language bytecode: LLVM bitcode in PNaCl.
- Even if a bytecode VM is specialized for Dart, a language VM will be simpler and faster because it can work under stronger assumptions—for instance, a structured control flow. These assumptions make the implementation cleaner and optimizations easier.
- A general-purpose bytecode VM would be even larger and slower, as it generalizes assumptions and adds functionality that for Dart is dead code: for example, multithreading with a shared heap.
- No bytecode VM is truly general-purpose; they all make assumptions that privilege some class of languages. A language VM leaves more room to improve the VM and make deep changes to optimization of the language. Some Dart engineers wrote an article talking about the VM question in more detail.

Why not compile Dart to ASM.js instead of building a specialized VM?
The subset of JavaScript that ASM.js targets does not match what dart2js needs. For example:
- dart2js needs to verify the number of arguments match (calling convention).
- dart2js needs to do bounds checks.
- dart2js forbids unsafe accesses to non-existing fields.

(Pour info le co-createur de Stack Overflow est Joel Spolsky qui etait deja connu pour le blog Joel on Software et qui est un ancien de Microsoft.)

HTML5 […] réunissait dans son groupe de travail des acteurs du Web multiples et pas uniquement un acteur unique comme le fait Google avec Dart

Tu te trompes lourdement.
Ca fonctionne toujours ainsi : une personne ou une entreprise a un besoin, elle le code dans son coin. Une fois que le resultat est jugé acceptable, l'entreprise ou l'individu rend publique cette techno puis ensuite vient l'etape de la normalisation/travail avec des acteurs externes pour ameliorer la techno.

Tim Berners-Lee a invente HTML debut des annees 90. Le W3C n'a ete cree qu'en 1994.
Plus précisément HTML vient de SGML qui a la base provient de chez… IBM… avant d'etre normalise par l'ISO.
Pareil pour JavaScript : c'est Netscape qui a cree dans son coin le langage en 95, puis soumission a l'Ecma en 96.
Ruby (norme ISO en 2012) : Matz (95) ; Python : van Rossum (91) ; Perl : Larry Wall (87)
Pareil pour C# (2001 - Ecma en 2002) ect…

Donc ta proposition c'est quoi ? Que a la place de Dart, Google reprenne C#, un langage controlle a 95% par Microsoft, qui a une culture ferme et mono-plateforme, qui n'est plus normalise depuis 7 ans, qui n'est pas un langage interprete a la base et de le soumettre au W3C qui n'a jamais normalise un langage de programmation ?

Et franchement je la ramerais pas sachant l'apport de C# en 2001 par rapport a Java/C++.
- des améliorations clair dans le langage par rapport à Java (event, metadatas, P/Invoke, (un)Boxing)
- Un modèle de compilation en code natif sans aucune interprétation (contrairement à la VM Java).

Heureusement que C#/.NET apportait des ameliorations par rapport a Java : 6 ans d'ecart entre ces technos. Mais au final il y avait moins de differences qu'entre Python 2 et 3.
Pourquoi ne pas avoir ameliore Java et la JVM, en quoi c'etait impossible ?

Le choix de Microsoft avec .NET et C# etait clairement politique et pas technique, le detournement de Java avec J++ le prouve bien.
A l'epoque ils etaient les rois du petrole et pouvaient imposer leurs technos mono-plateforme et leur modele ferme et ils l'ont fait.

• Un modèle de VM multi-language by design

C'est vraiment pas un argument a avancer. Tous les meilleurs bindings/langages utilisent la JVM : JRuby, Scala, Jython…

Le fleuron de ms pour faire des api rest, c'est un truc nomme MVC, ce qui est assez rigolo sachant qu'une API rest est 100% modele. Forcemment, si t'as pas de vue, ton controlleur il sert pas a grand chose.

Y'a rien de "rigolo". ASP.NET MVC (a ne pas confondre avec ASP.NET qui est une bouse - oui le nom a ete mal choisi), est l'equivalent Microsoft de Ruby on Rails (une copie conforme pour C#).
Pour faire une API REST, tu n'as plus la vue cote serveur, mais tu as toujours des controlleurs cote serveur ; que ca soit en Rails ou en ASP.NET MVC.

C# est spécifié, normalisé

Precision : jusqu'a C# 2.0 il y a 7 ans - une eternite (2006). Depuis il y a eu C# 3, 4 et 5 qui eux n'ont pas ete norme.
De plus l'implementation C#/.NET de Microsoft n'est pas multi-plateforme, n'est pas libre tout comme ses librairies.

Ce n'est que recemment que ca a change pour quelques librairies C#. Le framework web ASP.NET MVC a ete mis sous license Apache par Microsoft.
Pas vraiment le choix pour Microsoft quand on voit que tous les frameworks web modernes sont des projets libres : Rails, Django, Scala, PHP, Symfony, Drupal, Spring, Play!, J2EE, GWT…
Et tous les outils autour restent proprietaires : IIS, SQL Server, Visual Studio…
La communaute elle aussi reste neanmoins tres loin de l'ouverture d'autres communautes.

(PS : j'ai fait beaucoup de ASP.NET MVC en plus de Rails et c'est un tres bon framework)

que va apporter Dart par rapport à d'autres langages ? Au pif C# ?

1. L'ouverture de Dart par rapport a C# (licence BSD, projet ouvert, multi-plateforme, librairies open source…)
2. C# n'est pas un langage de script ! Python, Ruby, Perl, PHP, JavaScript et Dart oui

Et franchement je la ramerais pas sachant l'apport de C# en 2001 par rapport a Java/C++.

pour moi c'est pas l'ECMA qu'il faut prendre en compte, c'est le W3C

Evidemment, c'est d'ailleurs le W3C qui normalise JavaScript…

Dart est 5x plus lent que les .NET/JVM

La JVM existe depuis 18 ans (1995), .NET VM depuis 12 ans (2001) et Dart VM depuis 2 ans (2011).

Les developpeurs de Dart pendant ces 2 ans ont cree un IDE base sur eclipse, une VM, l'integration dans Chromium, dart2js, toutes les libs autour, les specs maintenant la normalisation…
Ils ont deja montre que Dart pouvait etre 2x plus rapide que JavaScript et dans certains cas depasser la JVM.

Laissons leur un minimum de temps pour prouver leurs dires.

De plus .NET et Java demandent une etape supplementaire de "compilation", Dart au contraire est un langage de script comme Python, Ruby ou JavaScript et ne demande pas d'etape supplementaire.

Le langage n'a à peut prêt rien d'original ou d'excitant comparé aux dernières moutures de C# ou Java

C'est voulu pour séduire le plus de personnes possibles. Si ils avaient fait dans l'originalité, ca leur aurait ete reproche aussi.

Bien entendu en priorité dans Chrome

Tout comme JavaScript est apparu d'abord dans Netscape.
Tout comme asm.js et Firefox.
Il faut bien commencer par quelques chose, tu serais a leur place, ca serait quoi ta solution ?

une façon de s'accaparer le futur du Web

C'est possible, on peut voir le mal partout. La mise a disposition des specs, la licence BSD, l'ouverture du projet, la normalisation en cours tend a montrer le contraire.
Que peuvent-ils faire de plus ?

"Google has gone about the introduction of Dart in a scrupulously open way. They publicized the language early on it's design and implementation, they open sourced their implementation immediately on announcement and continued development in the open with input and contributions from all comers. […] Now they've begun a standardization process.
[…] Mozilla couldn't ask for a more open […] Regardless of Google's overall impact on the world, the Dart project is very much in line with Mozilla's mission. […] I expect Mozilla will oppose Dart, but they'll have to twist themselves into rhetorical contortions in the process. NIH is alive and well." https://news.ycombinator.com/item?id=6903420

Je ne vois pas pourquoi il faut les 2

C'est pourtant clair, d'apres Lars Bak :
- "L'utilisation de asm.js implique une etape supplementaire : la compilation" cf le post auquel tu reponds
- une VM generique n'est pas aussi performante qu'une VM specifique

NaCl/ASM.js posent un gros problème de debugging

Non c'est faux, il n'y a aucun probleme de debugging. C'est le meme principe que debugguer du C/C++ compilé en binaire. Pareil pour CoffeeScript, TypeScript, dart2js : il y a les source maps pour ca.

Je ne suis pas certain de voir l'intérêt de porter du code existant du C/C++ vers le web.

idem, ca sera surement un usage bien specifique et non majoritaire.

asm.js […] pourra devenir le bytecode du web et contenter les déçus de javascript

L'utilisation de asm.js implique une etape supplementaire : la compilation.

Avec le langage Dart et la Dart VM, il n'y a pas cette etape (au moins durant l'etape de developpement).
C'est aussi l'un des avantages de Dart par rapport a CoffeeScript et TypeScript grace a Dartium.

Cf http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/

we don’t really see Dart and Native Client as competing technologies; they are very, very different and Dart is a scripting programming language that is very immediate; you can write your code and you reload your page and its right there, and Native Client is a different kind of technology and it’s great for translating C code to something that runs in your browser. It’s very different, at the core of it.

Native Client (NaCl) de Google a le meme objectif que asm.js

Conclusion : il faut les deux, un langage fait pour le developpement web "natif" et un systeme qui permet de compiler n'importe quoi vers le web.

Dans cette interview Lars Bak donne 2 raisons : la maintenabilite et la recherche de la performance.

[…] it was also very clear that web applications were getting bigger and bigger. Inside Google, we have Gmail and other big apps and it’s basically many, many lines of JavaScript and it’s very hard to maintain big applications in JavaScript.

So big companies like Google, they put some structure on top of JavaScript just to be able to maintain the many lines of code and we have the JS closure compiler at Google, so you can actually annotate JavaScript with pseudo types. You can check that and stuff like that. So it’s clear that JavaScript was reaching the limit of how big applications can write – at least that’s how we saw it.

And so, we were looking at coming up with a better language that’s more declarative and would be easier to maintain if you have big applications. And at the same time, we want to make sure we could solve two problems with JavaScript; one is the startup time which is pretty pathetic right now. And then the peak performance — of course we want to make it faster too.

You know the way that JavaScript started up in the browser you reading source code and you have to read another source code before you really can get started and then that also means that if you start up a big web application, it can take half a second or more to load the application.

[…] So we envision that when it comes to start up performance, we have a factor of 10 compared to JavaScript and peak performance should be at least twice as fast.

Il repond aussi a la question pourquoi pas une VM a multi-langage ? (avec bytecode donc comme la JVM ou la VM .NET)

Well the problem is it doesn’t work. […] several companies have tried to do multi language VMs and the problem is that […] there’s always compromise you have to make. […] if you are implementing C# or Java, you will have basic types, right? You will have ints and doubles and longs […] in JavaScript you have all updates [ndlr : objects] everywhere and it’s very hard to reconcile these two worlds. So if you do a VM based on basic types it’s pretty much impossible to make it run fast if you want to implement JavaScript — and the other way around basically.

[…] if you try to make an implementation of JavaScript, it will be falling into the category we talked about before – dog slow — it’s just not fast.

Et la suite de l'interview ici : http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-lars-bak-and-kasper-lund-bonus-content/

du RAII

Le RAII c'est pour le C++ et les exceptions, dans Dart il y a le garbage collector.

la possibilité de gérer la mémoire "à la main".

Peut-être dans le futur ? : https://code.google.com/p/dart/issues/detail?id=3691

des opérations SIMD

Ceci n'est pas suffisant ?

CoffeeScript c'est quasi juste du sucre de syntaxique

Non, c'est un langage a part entiere qui compile vers JavaScript.
A la difference de TypeScript [1], du code JavaScript n'est pas du code conforme CoffeeScript.

Il y a bien sur la possibilite d'embarquer du code JavaScript dans du CoffeeScript : le code sera simplement ignore par le compilateur CoffeeScript et rendu tel quel.

[1] ce qui AMHA en fait une bien meilleur approche, d'autant plus que beaucoup de fonctionnalites de TypeScript sont identiques a celle du futur EcmaScript 6.

Le fait qu'il y ait un paquet de modules illustre seulement que le langage est utilisé intensivement

Ou que l'on a actuellement pas le choix tout simplement !

Rien qui ne puisse être changé dans une évolution progressive du langage

C'est le point de vue de Eich et de Microsoft via TypeScript.
C'est une position qui se defend, qui vivra verra.

On ne sait toujours pas selon eux quels sont les « fundamental flaws that cannot be fixed merely by evolving the language »

Je n'ai egalement pas trouve de reponse claire a cette question pourtant fondamentale.
En vrac : le support dans les IDE, le scope des variables, this, l'API DOM, NaN, null, ===, Number…
Certains de ces problemes peuvent etre resolus partiellement ou totalement en faisant evoluer JavaScript.

Mais le point le plus important semble les performances.
D'apres Lars Bak, le createur de V8, la complexite et les performances de la VM JS ont atteint un sommet alors que Dart VM permet d'aller beaucoup plus loin.
C'est tres important notamment a cause des smartphones qui n'ont pas les memes resources qu'un PC - et meme si c'etait le cas, il y a le probleme de la batterie.

Il a fallu 5 ans (premiere version de Chrome : 2008) pour obtenir les performances actuelles de V8 et seulement 2 ans pour que la VM Dart soit 2x plus performante que V8.

Le créateur de la plus grosse bouse (marrant d'ailleurs qui soit devenu CTO)

Je suis d'accord sur tout le reste de ton post en revanche je ne pense pas que l'on puisse reprocher a Brendan Eich la creation de JavaScript : il faut se remettre dans le contexte de l'epoque. Le langage a ete cree en quelques jours seulement.
D'autres personnes supposément plus competentes n'auraient probablement pas fait mieux vue les contraintes et les connaissances de l'epoque. Personne n'aurait imagine en 1995 que JavaScript allait prendre une telle ampleur 10 ans plus tard.

Bref encore un peu plus de fragmentation :/

Et la video qui résume le mieux à mon sens les propos d'Etienne Chouard : http://www.dailymotion.com/video/xiyzhh_etienne-chouard-conference-le-tirage-au-sort-comme-bombe-politiquement-durable-contre-l-oligarchie_news
Ca dure 1h25 et c'est fort intéressant.

on reconnaît tout de suite sous Windows une application Qt

Et precisement tu le reconnais a quoi ?

lorsque je clique sur un bouton d'une barre de défilement en GTK, la barre se déplace à l'extrémité

C'est pas tout a fait ca : le "slider" se deplace a la meme position que la souris.

Sous Qt avec émulation GTK, ça ne le fait pas (essayé à l'instant)

Effectivement, Qt ne suit pas la position de la souris, ca meriterait un correctif.
A noter que la scrollbar de la liste des applications de GNOME 3 (Activities) ne suit pas la souris, pareil pour Firefox (tester sous Ubuntu 13.10 GNOME edition).
Pour info OS X et Windows ne suivent pas non plus le curseur de la souris.

Où est l'appel de la libgtk ?

Qt ne fait pas des appels pour tout et probablement pas pour la scrollbar quand il s'agit de GTK+ (alors qu'il le fait tres probablement sous Windows et OS X).

GNOME represente ~0.5% du marche, je veux bien croire que les developpeurs s'y attardent moins que Windows ou OS X.

Vala est là je pense, pour offrir un langage plus moderne, et j'espère qu'il percera

Le sujet Vala a deja ete aborde et apparemment c'est pas l'ideal : http://linuxfr.org/nodes/96897/comments/1419673
Resume rapide : "Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients".

On pourrait imaginer que Vala soit recent et donc que c'est juste une question de temps, en fait Vala existe depuis 2006 (7 ans).

Il y a donc un bus factor > 1.

C'est pas l'avis de Benjamin Otte : "This gives the GNOME project essentially a bus factor of 1" (encore plus vrai pour GTK+ et GLib puisqu'il y a encore moins de developpeurs).

Ah ben merci, ça fait toujours plaisir à entendre…

Y'a rien de personnel. Je fais actuellement du AngularJS, et je trouverais ca normal que les ecrits de Igor Minar aient plus de poids que les miens sur ce sujet.

Il y a peut-être certains développeurs qui quittent le navire, mais d'autres rejoignent le projet aussi

Benjamin Otte n'est pas con a ce point et il semble evident que lorsqu'il ecrit "core developers are leaving GNOME development" cela signifie qu'il y a moins de core developpeurs meme en incluant les nouveaux (au moment ou il l'ecrit bien sur - 2012).

Dire "GTK+ c'est de la merde, Qt est beaucoup mieux à tout point de vue"

Encore une fois, "GTK+ n'est pas mauvais" et aucun commentaire sur Hacker News ou le blog de Wireshark affirme que GTK+ est de la merde.

J'ai fait du GTK+ et j'en garde un bon souvenir. Il n'empeche que Qt est meilleur, en tout cas c'est l'avis de beaucoup de monde cf la liste. Le seul qui refuse cette idee est Icaza mais dixit la news "ça n'a pas l'air de prendre".

GTK+ et GLib ont beaucoup de potentiel

Mon avis est tout autre.
Le scenario le plus probable : le developpement de GTK+ et GLib va continuer a decroitre gentiment. Le support OS X et Windows va petit a petit disparaitre pour se concentrer sur Linux.
Il n'y aura pas d'innovation marquante et le support du mobile (iOS, Android) n'arrivera jamais.
En sachant que Linux ne represente que 1% du desktop et que le desktop se fait gentiment bouffer par le mobile pour le commun des mortels, je suis sceptique sur le "potentiel" de tout ca.
On en reparle dans 5 ans.

n'encourage pas les nouveaux venus à choisir GTK+

Il est evident que mes propos n'encouragent pas les gens a choisir GTK+, c'est meme le but hein.

Et y'a t'il quelque chose de concret ?
Genre un debut de prototype pour iOS, Android ou Windows Phone ?
Ou alors juste une annonce qui dit "on va mettre x developpeurs pour travailler la dessus" ou "dans x mois on a un proto sous iOS/Android" ?

Les premieres versions publiques de Qt sur Android datent de debut 2011 (bientot 3 ans) : http://blog.qt.digia.com/blog/2011/02/28/necessitas/

Au passage, pour avoir un ordre de grandeur :

• Chromium : ~54 000 commits sur les 12 derniers mois et ~1100 contributeurs
• Firefox : ~41 000 commits, ~1000 contributeurs
• LibreOffice : ~22 000 commits, ~330 contributeurs
• Wireshark : ~6300 commits, ~30 contributeurs