Google Dart native on WebKit?(grobmeier.de)
grobmeier.de
Google Dart native on WebKit?
http://www.grobmeier.de/google-dart-native-on-webkit-08122011.html
15 comments
From reading that email exchange I think the answer to your question is a definite "no" :-)
Aside from that, Google seems to be arguing that 1) there exist languages that compile to EcmaScript, so 2) single-vendor VMs in browsers is now OK. I'm being harsh here but that is the essence of it and it makes no sense at all.
Aside from that, Google seems to be arguing that 1) there exist languages that compile to EcmaScript, so 2) single-vendor VMs in browsers is now OK. I'm being harsh here but that is the essence of it and it makes no sense at all.
Flashback from 1996: Internet Explorer 3.0 with support of VBScript and JScript (reverse-engineered JavaScript) released.
Notabene it also featured CSS, ActiveX controls and Microsoft Java VM with Java Applets - http://en.wikipedia.org/wiki/Internet_Explorer_3.
Notabene it also featured CSS, ActiveX controls and Microsoft Java VM with Java Applets - http://en.wikipedia.org/wiki/Internet_Explorer_3.
There was even a PerlScript plugin that you could use.
http://en.wikipedia.org/wiki/PerlScript
http://en.wikipedia.org/wiki/PerlScript
And ActivePython via ActiveScripting. Python could even run in ASP
Dart may not be a standard yet, but both the Dart language and the Webkit source code are open.
Comparing this to Microsoft and ActiveX is an unfair comparison, imho.
2 things can happen: either Dart falls flat and this has no implications to anyone, or Dart becomes a major success and nothing is stopping IE, FF or Opera to writing their own implementation based on the open specification and code.
I fail to see the problem.
Comparing this to Microsoft and ActiveX is an unfair comparison, imho.
2 things can happen: either Dart falls flat and this has no implications to anyone, or Dart becomes a major success and nothing is stopping IE, FF or Opera to writing their own implementation based on the open specification and code.
I fail to see the problem.
HTML5 specifies "type" attribute for "script" tags http://www.whatwg.org/specs/web-apps/current-work/multipage/...
The type attribute gives the language of the script or format of the data.
From the perspective of the WebKit team, I think it would be about spending a lot of time and effort to support something that isn't part of their core mission, the standardised web.
It would also saddle them with an extra maintenance & support burden for the foreseeable future, to the strategic benefit of nobody but Google.
I think the original conversation was hampered by a miscommunication - it was never made clear whether it was just about hacking on a custom version of WebKit, or about adding Dart support to WebKit based browsers.
It would also saddle them with an extra maintenance & support burden for the foreseeable future, to the strategic benefit of nobody but Google.
I think the original conversation was hampered by a miscommunication - it was never made clear whether it was just about hacking on a custom version of WebKit, or about adding Dart support to WebKit based browsers.
Let me quote the relevant paragraph from their goals in full:
Why restrict innovation only to certain areas?
Standards Compliance
WebKit aims for compliance with relevant web standards,
and support for new standards In addition to improving
compliance, we participate in the web standards community
to bring new technologies into standards, and to make sure
new standards are practical to implement in our engine.
We use regression testing to maintain our standards compliance
gains.
Why restrict innovation only to certain areas?
I agree completely that innovation should not be restricted to certain areas :-) And although I think that Dart isn't good for the web, I would encourage anyone who wants to e.g. try plugging a different VM into a browser engine to see what happens.
Secondly I would agree that WebKit has its own OS X-related baggage, but that just goes to show that nobody's perfect. It's not an argument for adding more. I would also agree that in the hypothetical case of Dart support being added to WebKit that Google would be expected to maintain their code, just as Apple would be expected to maintain OS X stuff.
But again, I think the original conversation was had at cross-purposes. What started as a conversation about hosting a branch of WebKit to do some innovating turned into a conversation about standards and the broader web. In the former case it's a purely technical question of where the work is done, but in the latter, I think the "participate in the web standards community" bit comes in to play. Why did Google come directly to WebKit to ask about integrating Dart instead of talking to e.g. the W3C or WHATWG?
Secondly I would agree that WebKit has its own OS X-related baggage, but that just goes to show that nobody's perfect. It's not an argument for adding more. I would also agree that in the hypothetical case of Dart support being added to WebKit that Google would be expected to maintain their code, just as Apple would be expected to maintain OS X stuff.
But again, I think the original conversation was had at cross-purposes. What started as a conversation about hosting a branch of WebKit to do some innovating turned into a conversation about standards and the broader web. In the former case it's a purely technical question of where the work is done, but in the latter, I think the "participate in the web standards community" bit comes in to play. Why did Google come directly to WebKit to ask about integrating Dart instead of talking to e.g. the W3C or WHATWG?
Secondly I would agree that WebKit has it's own OS X-related baggage, but that just goes to show that nobody's perfect. It's not an argument for adding more.
We're in agreement then, because what (I think) these patches do is creating a better abstraction for scripting engines. I'm not very familiar with WebKit code base, but if there were similar abstractions for other things, they could get rid of various #ifdefs, for example, for drawing code (CG, Skia, etc.) http://trac.webkit.org/browser/trunk/Source/WebCore/html/can... or Dashboard http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...
We're in agreement then, because what (I think) these patches do is creating a better abstraction for scripting engines. I'm not very familiar with WebKit code base, but if there were similar abstractions for other things, they could get rid of various #ifdefs, for example, for drawing code (CG, Skia, etc.) http://trac.webkit.org/browser/trunk/Source/WebCore/html/can... or Dashboard http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...
Do you think WebKit should include VBScript bindings as well?
It's pretty transparent what Google wants here; anyone who forks WebKit (ie everyone not named Mozilla, Opera, Microsoft) to get Dart by default. Adding the VM is just a small additional step.
It's pretty transparent what Google wants here; anyone who forks WebKit (ie everyone not named Mozilla, Opera, Microsoft) to get Dart by default. Adding the VM is just a small additional step.
They are _not_ adding Dart into WebKit, they are adding the ability to add more languages.
As it has already been mentioned several times before, the lengthy process of adopting a new technology as a universal standard (via RFC, W3C, etc.) is a necessary evil which has greater advantages to developers/users than a single company going commando with their own great idea. Does Google think Dart deserves an exception to this? Most likely they are seeking a head start at the risk of others not following (as Brendan Eich has already stated Mozilla won't comply: https://news.ycombinator.com/item?id=2982949).
Edit: Added link.
Edit: Added link.
> developers don’t need to use toolchains
Sorry I don't get this. If Dart is delivered to the browser in source form, you'll still want script compressors and/or tools like Closure Compiler to eliminate unused code. Even if Dart is delivered to the browser in bytecode format you'll need a toolchain on the backend--and you'll still need symbol tables for client debugging.
If anything, the toolchain and project setup will be more complex for Dart developers if they want to support all browsers. They'll need to create one set of files for Chrome with native Dart and cross-compile to JavaScript for all other browsers. Then they'll need to conditionally include one set of script files or the other.
Sorry I don't get this. If Dart is delivered to the browser in source form, you'll still want script compressors and/or tools like Closure Compiler to eliminate unused code. Even if Dart is delivered to the browser in bytecode format you'll need a toolchain on the backend--and you'll still need symbol tables for client debugging.
If anything, the toolchain and project setup will be more complex for Dart developers if they want to support all browsers. They'll need to create one set of files for Chrome with native Dart and cross-compile to JavaScript for all other browsers. Then they'll need to conditionally include one set of script files or the other.
So. Adding stuff like the canvas tag (added to webkit to display dashboard widgets) and CSS transforms (ditto) is ok because they were going to submit them as standards anyways.
But adding another language besides JS is not ok because that would be bad for the web.
Now, personally I don't care about dart, but I know that I had the same bad feeling back in the day when Safari learned the then nonstandard canvas tag than I have now when it should learn the nonstandard scripting language.
I do find it hypocritical though to allow one and disallow the other.
But adding another language besides JS is not ok because that would be bad for the web.
Now, personally I don't care about dart, but I know that I had the same bad feeling back in the day when Safari learned the then nonstandard canvas tag than I have now when it should learn the nonstandard scripting language.
I do find it hypocritical though to allow one and disallow the other.
Was there any standardized feature out there that canvas displaced? Heck, given that Flash didn't do generated bitmaps and Java applets were largely dead by the time canvas hit, was there anything that it displaced? Or even a similar competing feature in another browser?
By contrast, Dart is squarely aimed at competing with a feature that's both a defacto and a formalized standard for web browsers. Not an abandoned and aging feature, either: JavaScript's proven far more capable than most of the industry gave it credit for, it's been growing and changing over time, and there's currently very active development, discussion, and collaboration underway to improve the language and its performance -- and expand the features exposed to it by various APIs.
There's a world of difference between those two situations. In the former, you're introducing a new feature a platform doesn't have yet. In the later, you're splitting the industry on an existing feature.
By contrast, Dart is squarely aimed at competing with a feature that's both a defacto and a formalized standard for web browsers. Not an abandoned and aging feature, either: JavaScript's proven far more capable than most of the industry gave it credit for, it's been growing and changing over time, and there's currently very active development, discussion, and collaboration underway to improve the language and its performance -- and expand the features exposed to it by various APIs.
There's a world of difference between those two situations. In the former, you're introducing a new feature a platform doesn't have yet. In the later, you're splitting the industry on an existing feature.
It should be pretty clear that Dart and Canvas are entirely different matters. There is very little about the two that's similar, beyond trivial things like how they both began nonstandard.
Every browser vendor at times adds new tags or attributes if they think they can improve the web as a whole. When possible things are vendor prefixed, but still, it's something all the vendors do. It's the only way to get that technology into customers' hands.
Even though the canvas API is arguably a bad design, it certainly gets the job done - and nobody else stepped up to solve the problem before Apple did. It also made it into standards relatively quickly, and was implemented by other browser vendors pretty easily.
Every browser vendor at times adds new tags or attributes if they think they can improve the web as a whole. When possible things are vendor prefixed, but still, it's something all the vendors do. It's the only way to get that technology into customers' hands.
Even though the canvas API is arguably a bad design, it certainly gets the job done - and nobody else stepped up to solve the problem before Apple did. It also made it into standards relatively quickly, and was implemented by other browser vendors pretty easily.
Please give us a proper VM like .NET(Mono is a good candidate), Java, Parrot or whatever instead of yet another crap language(both Dart and JS are shit). Provide a VM level binding layer to the DOM, and everyone will be happy. Really, I didn't expect that a company like Google will be so stupid to do so.
Mozilla did donate $10k to The Perl Foundation back in 2007. I think it was mainly a philanthropic action to help Perl6/Parrot. However they may also be eyeing a future possibility for hosting their Firefox languages on top of the ParrotVM.
ref: http://www.mozilla.org/grants/perl-foundation.html & http://www.parrotblog.org/2008/09/final-report-for-mozilla-f...
ref: http://www.mozilla.org/grants/perl-foundation.html & http://www.parrotblog.org/2008/09/final-report-for-mozilla-f...
It was already tried, through Java and LiveConnect. It was criticized as bloated and slow, and was eventually removed.
> It looks like Dart is going to become native on the WebKit Browser.
No, the actual WebKit mailing list shows the exact opposite. Opposition (mainly from Apple) was quite strong, and it looks like Google will not be able to do this as a WebKit branch.
Instead, it will be a branch somewhere outside WebKit apparently. In that respect it will be like several other Google-specific technologies that are in Chrome but not WebKit, like NaCl and Pepper.
No, the actual WebKit mailing list shows the exact opposite. Opposition (mainly from Apple) was quite strong, and it looks like Google will not be able to do this as a WebKit branch.
Instead, it will be a branch somewhere outside WebKit apparently. In that respect it will be like several other Google-specific technologies that are in Chrome but not WebKit, like NaCl and Pepper.
They are NOT asking the Webkit project to add Dart. They want to get a pluggable VM system into Webkit. Then once that is in place, Google would not need to fork Webkit to get Dart into Chrome. And any other vendor that wants to be able to extend Webkit with another VM would not need to fork it either.
It is clear that Google wants to get a Dart VM into Chrome, and I would rather that happen via a pluggable VM system than via a fork of WebKit.
What happened to Google's motto "Don't be evil?". Obviously they are trying to balkanize the web with non-standard technologies again.
Why would this be evil as long as Dart remains an open standard? Making it run better on their platform would incentivize the adoption of Chrome and Dart.
Getting near native performance in the browser would help take web apps to another level. Photoshop in a browser, for example.
Getting near native performance in the browser would help take web apps to another level. Photoshop in a browser, for example.
Open standard? Dart is neither a standard nor designed in an open process.
Just like canvas tag, right?
I remember canvas in 2004, I demo'ed it in a Firefox prototype at Web 2.0 that fall. The development of the API took place on the very early whatwg.org, mailing list and even in a few face-to-face meetings (recorded to the list). It was IIRC based on PostScript level 2, or really an Objective-C API based on the PostScript-2 model, from Apple.
But a bunch of others had early say in the wide-open (to members, and in terms of mailing list access) WHAT-WG on the exact API form and substance, and canvas evolved under this feedback years before it became a de-facto standard. It is still not a de-jure standard, as HTML5 isn't done yet.
Perhaps Dart will evolve similarly, but I doubt it. Canvas was "easy" in that 2D graphics APIs (built into OSes, or portable ones such as Cairo) already existed and were a close-enough fit to the affine-transform-only 2D canvas API. Thus for most browsers, hooking up canvas was quick work, weeks if not days, modulo spec corner case fussing that dragged out for a while.
In contrast, Dart requires either digesting the native VM source and learning to embed it (if not support it -- will other browsers just file bugs and wait for patches? doubtful), or else reverse-engineering it (some browser vendors have their own legal reasons not to use open source).
And only then, once a VM of some kind has been minimally ported into a browser, would the work to integrate it with the DOM, JS, and any other languages which might have commerce among garbage collected heaps possibly begin.
The last point means adding a cycle collector, which as Filip Pizlo of Apple points out here:
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
is likely to cost noticeable performance.
This is a far cry from canvas, both in terms of standardization politics and intrinsic complexity (which mainly determines odds of cross-browser support).
Hope I wasn't feeding a troll! This may be educational to some, anyway.
But a bunch of others had early say in the wide-open (to members, and in terms of mailing list access) WHAT-WG on the exact API form and substance, and canvas evolved under this feedback years before it became a de-facto standard. It is still not a de-jure standard, as HTML5 isn't done yet.
Perhaps Dart will evolve similarly, but I doubt it. Canvas was "easy" in that 2D graphics APIs (built into OSes, or portable ones such as Cairo) already existed and were a close-enough fit to the affine-transform-only 2D canvas API. Thus for most browsers, hooking up canvas was quick work, weeks if not days, modulo spec corner case fussing that dragged out for a while.
In contrast, Dart requires either digesting the native VM source and learning to embed it (if not support it -- will other browsers just file bugs and wait for patches? doubtful), or else reverse-engineering it (some browser vendors have their own legal reasons not to use open source).
And only then, once a VM of some kind has been minimally ported into a browser, would the work to integrate it with the DOM, JS, and any other languages which might have commerce among garbage collected heaps possibly begin.
The last point means adding a cycle collector, which as Filip Pizlo of Apple points out here:
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
is likely to cost noticeable performance.
This is a far cry from canvas, both in terms of standardization politics and intrinsic complexity (which mainly determines odds of cross-browser support).
Hope I wasn't feeding a troll! This may be educational to some, anyway.
Hello, thanks for the reply.
Yes, I was a bit snarky in mine, but didn't intend to troll.
I was just an user, when the canvas tag appeared. I remember, that it was available for Safari and Dashboard on OSX, and then later in other browsers. I also remember, that at the time, Apple started to assert patents on it.
Dart's imlementation is harder, I also agree. However, what I see from Google at this stage is call for cooperation to shape the language, not something that is done and the others have to accept as-is. The call may be considered even more public than whatwg mailing list. And yes, I agree that the complexity of integrating another VM into existing engines may kill it in the end.
I actually do not like some design goals of Dart, but I understand, that there is demand for Java-like language in browser and that there is impedance mismatch between Java/GWT on one hand and JS in browsers on the other, that Dart intends to solve.
Yes, I was a bit snarky in mine, but didn't intend to troll.
I was just an user, when the canvas tag appeared. I remember, that it was available for Safari and Dashboard on OSX, and then later in other browsers. I also remember, that at the time, Apple started to assert patents on it.
Dart's imlementation is harder, I also agree. However, what I see from Google at this stage is call for cooperation to shape the language, not something that is done and the others have to accept as-is. The call may be considered even more public than whatwg mailing list. And yes, I agree that the complexity of integrating another VM into existing engines may kill it in the end.
I actually do not like some design goals of Dart, but I understand, that there is demand for Java-like language in browser and that there is impedance mismatch between Java/GWT on one hand and JS in browsers on the other, that Dart intends to solve.
Dart is not just "harder" (a difference in degree), it is different in kind: a new programming language with a garbage collector, not a 2D graphics API that's close to one already available if not already in all browsers.
Apple's origination doesn't alter this distinction between the nature of the two things, and Apple played fair once they contributed the work.
Witholding patents when there was no WHATWG patent process or even a legal entity or membership structure was totally expected. The W3C has a patent protocol that Apple has used many times, and the w3c is where canvas has indeed landed as a Royalty-Free standard.
Apple's origination doesn't alter this distinction between the nature of the two things, and Apple played fair once they contributed the work.
Witholding patents when there was no WHATWG patent process or even a legal entity or membership structure was totally expected. The W3C has a patent protocol that Apple has used many times, and the w3c is where canvas has indeed landed as a Royalty-Free standard.
Hum, I think the problem is that Dart may be technically open source, but it's not a standard. In addition to that you can publish the source but being truly open involves more than that: see the open governance index for an example:
http://www.readwriteweb.com/mobile/2011/08/android-is-the-le...
It involves things like multi-vendor support, open project management & roadmapping, standards bodies where applicable, etc. These are all things Dart doesn't have.
http://www.readwriteweb.com/mobile/2011/08/android-is-the-le...
It involves things like multi-vendor support, open project management & roadmapping, standards bodies where applicable, etc. These are all things Dart doesn't have.
You've forgotten your history.
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
And don't think it's not possible, a number of MSFT folks who employed this strategy are now in leadership roles at GOOG.
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
And don't think it's not possible, a number of MSFT folks who employed this strategy are now in leadership roles at GOOG.
What open standard do you mean?
Clue: open source != open standard. Code overspecifies badly. Any implementor who cannot or will not use the (evolving) Google code would have to reverse-engineer the "interop spec", which is less specific than the C++.
Clue: open source != open standard. Code overspecifies badly. Any implementor who cannot or will not use the (evolving) Google code would have to reverse-engineer the "interop spec", which is less specific than the C++.
Please forgive me if I am wrong but JavaScript was not an "open standard" either in the beginning. It took you 1 year to submit it to the ECMA body for consideration. And, oh boy, you are still fixing JS design mistakes with a group of quite smart engineers and computer scientists.
Now lets step back and look into the past: was JavaScript implementation or specification as open to comments and feedback as Dart is now? There are public mailing lists, issue tracker and open repositories that accept patches and suggestions. Did you have that for JavaScript?
I might be utterly wrong but I bet you did not. Yet instead of participating in the language effort or at least stepping back and patiently watching it's birth and growth into something standardizable you criticize and bash it.
May I humbly ask you why?
Now lets step back and look into the past: was JavaScript implementation or specification as open to comments and feedback as Dart is now? There are public mailing lists, issue tracker and open repositories that accept patches and suggestions. Did you have that for JavaScript?
I might be utterly wrong but I bet you did not. Yet instead of participating in the language effort or at least stepping back and patiently watching it's birth and growth into something standardizable you criticize and bash it.
May I humbly ask you why?
You're new here, another 3-hour-old HN account. Do you by any chance work on Dart for Google?
In any event, why don't you catch up and familiarize yourself with my arguments by reading my comments here:
https://news.ycombinator.com/item?id=2998374
and in the whole thread:
https://news.ycombinator.com/item?id=2982256
--- begin quote ---
``Accusing me of hypocrisy shows ignorance of that word's definition in light of the history of my career.
``I'm not practicing one thing and preaching another. I worked on JS standardization less than a year after shipping it in Netscape 2 beta. After that I co-founded mozilla.org. I'm not currently doing A and preaching not-A, nor have I been doing "proprietary" work for a long time. I've paid my dues.''
--- end quote ---
As for "criticize", my comment here asks what open standard someone else (not you) meant. I'd like to know. Let's hear the other person's answer, before criticizing anyone. I did not criticize a soul in my comment.
As for "bash": stop lying. I did not bash a thing and you know it. The lamest form of non-argument is to whine about "bashing" and utterly fail to engage the substance of the other person's argument.
You, however, are making an anonymous ad-hominem attack on me for not doing something Netscape simply would not support 16 years ago. I could have quit and let VBScript win. I'm not bragging about JS but (smart people on TC39 notwithstanding -- you needn't put me down by implying they're doing all the good-parts work :-/) JS has succeeded beyond many expectations. Good luck to Dart getting the same adoption.
And JS won't go away quickly, so my position, independent of my past, is that we ought to improve it rather than starve it by trying to do a new language. Same as for HTML -- I co-founded the WHAT-WG to do HTML5 when the W3C abandoned HTML in 2004.
Make no mistake: (1) Google is pulling people off of JS to do Dart; (2) Dart will not get foreseeable adoption in any browser of significant market share but Chrome.
If Chrome had Netscape's market share, then Dart could probably become de-facto standard, as JS did back in 1996. Perhaps Chrome will get there, but it'll take a while, and in the mean time, Dart both costs JS (because Google has pulled people off of JS) and threatens to fragment the web (and WebKit first, the topic of this thread).
In any event, why don't you catch up and familiarize yourself with my arguments by reading my comments here:
https://news.ycombinator.com/item?id=2998374
and in the whole thread:
https://news.ycombinator.com/item?id=2982256
--- begin quote ---
``Accusing me of hypocrisy shows ignorance of that word's definition in light of the history of my career.
``I'm not practicing one thing and preaching another. I worked on JS standardization less than a year after shipping it in Netscape 2 beta. After that I co-founded mozilla.org. I'm not currently doing A and preaching not-A, nor have I been doing "proprietary" work for a long time. I've paid my dues.''
--- end quote ---
As for "criticize", my comment here asks what open standard someone else (not you) meant. I'd like to know. Let's hear the other person's answer, before criticizing anyone. I did not criticize a soul in my comment.
As for "bash": stop lying. I did not bash a thing and you know it. The lamest form of non-argument is to whine about "bashing" and utterly fail to engage the substance of the other person's argument.
You, however, are making an anonymous ad-hominem attack on me for not doing something Netscape simply would not support 16 years ago. I could have quit and let VBScript win. I'm not bragging about JS but (smart people on TC39 notwithstanding -- you needn't put me down by implying they're doing all the good-parts work :-/) JS has succeeded beyond many expectations. Good luck to Dart getting the same adoption.
And JS won't go away quickly, so my position, independent of my past, is that we ought to improve it rather than starve it by trying to do a new language. Same as for HTML -- I co-founded the WHAT-WG to do HTML5 when the W3C abandoned HTML in 2004.
Make no mistake: (1) Google is pulling people off of JS to do Dart; (2) Dart will not get foreseeable adoption in any browser of significant market share but Chrome.
If Chrome had Netscape's market share, then Dart could probably become de-facto standard, as JS did back in 1996. Perhaps Chrome will get there, but it'll take a while, and in the mean time, Dart both costs JS (because Google has pulled people off of JS) and threatens to fragment the web (and WebKit first, the topic of this thread).
I propose googles new motto - "Quasi open"
If this qualifies as "evil" to you, you have a much broader definition of evil than I do.
Google is just going to do this whether the open web wants it or not. It seems like just giving them the cold shoulder excludes you from the conversation and when Google flies past and you're scrambling to catch up, no amount of bitching about lack-of-openness will help you.
Would Dart require its own interpreter/compiler? I thought Google was just going to expand V8 to support it. Then again I know very little about compilers.
Would have been interesting if Dart wouldn't have been such an atrocious, bad joke of a language.
Without explaining how Dart is,"such an atrocious, bad joke of a language" this comment simply adds nothing to the discussion. I would, however, be interested to read your critique.
They combined the worst parts of Java with the worst parts of JavaScript.
- Verboseness
- Patterns
- No type safety (combined with that dishonest “optional typing” non-sense)
- No traits (didn't they get the memo that single implementation inheritance didn't work out?)
- Map being no Iterable
- No HOFs in the collection library
- nulls even for primitive types, ...
I don't like superlatives, but I'm pretty confident calling Dart the worst language I have seen.
The only mistake they missed are probably Checked Exceptions.
- Verboseness
- Patterns
- No type safety (combined with that dishonest “optional typing” non-sense)
- No traits (didn't they get the memo that single implementation inheritance didn't work out?)
- Map being no Iterable
- No HOFs in the collection library
- nulls even for primitive types, ...
I don't like superlatives, but I'm pretty confident calling Dart the worst language I have seen.
The only mistake they missed are probably Checked Exceptions.
I'd say Dart doesn't even have to be atrocious -- it's just simply not that much better.
You can add yours if these patches will be accepted into WebKit.
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
"WebKit branch to support multiple VMs (e.g., Dart)", halfway down the page.
In particular, some of Oliver Hunt's responses:
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...