6 ms·

A Tour of the Dart Language

30 points by Mamady 15y ago

DanWaterworth 15y ago
When people say list, I think linked-list. When they say array, I think contiguous array. I wish we could standardize on that terminology, it makes sense and allows easy differentiation between the 2 concepts.
- JulianMorrison 15y ago
  Clojure implements them in trees of contiguous arrays :-P http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/ http://blog.higher-order.net/2009/02/01/understanding-clojur...
- radarsat1 15y ago
  I used to do that, but now I try to think in terms of the abstraction "list" and "array", and not worry about the underlying data structure unless I'm specifically thinking about efficiency. For example there are multiple ways of implementing lists and arrays that have similar interfaces but different efficiencies for insertion/sort/search, etc. So basically the dichotomy you propose is just "too simple," it doesn't cover all the options and combinations that a programmer may need to think about.
  - DanWaterworth 15y ago
    I didn't say that it was a dichotomy, actually I tend to think of the space as roughly split into three: lists, arrays and annotated/sorted trees. Lists and arrays are really common though, so I think it makes sense to make it easy to refer to them using short words.
- kibwen 15y ago
  Funny, I had the exact same thought but with regard to Dart's maps (a.k.a. associative arrays, hash[maps], [hash] tables, dictionaries, records, objects (Javascript), or even just arrays (Tcl)).
kibwen 15y ago
From the (incomplete) overview here (and ignoring the type system for the moment), Dart appears to be reasonably competent and technically sound, given that this is a language intended to compile to Javascript. That said, it doesn't terribly excite me. It should be interesting to see whether the safety guarantees of optional typing and the few other restrictions it provides (such as more rigid function signatures) will really entice developers who are planning large web applications. I'm working on a modest-sized (~3kloc) Javascript codebase at the moment and it's somewhat of a mess, but that's really more due to the combined influence of legacy code, time constraints, technical debt, rapidly shifting requirements, and a lack of testing. Other than that last point, it's not immediately obvious how using Dart rather than Javascript would have benefited me. Perhaps someone who's worked with a more substantial Javascript application could provide a better answer.
- mmurph211 15y ago
  I think it's good to have a choice of language for front end web development and I think primarily this is what Dart is providing. That said unless Dart proves to be considerably faster than Javascript I don't think I'll be converting any old Javascript code bases. I agree they're certainly going to have to provide a convincing case for me to switch to Dart in the future but like I said right now it's at least nice to see a second choice being developed.
- beza1e1 15y ago
  Dart is not "intended to compile to Javascript". Dart is intended to compete with Javascript. Compiling to Javascript is just intended as a fallback.
  - firefoxman1 15y ago
    This has probably been asked before, but why haven't any browsers worked on natively implementing CoffeeScript (not compiling to Javascript first)?
    - gcp 15y ago
      Because there is no advantage to that at all? Dart has more type information, so a Dart compiler has some hints to generate faster code. (And this is why fast JavaScript engines do type inference)
dgregd 15y ago
What are pros and cons of Dart support for Mozilla/Firefox?
- scriptproof 15y ago
  Cons: Not needed because all the stuff will be included in a next iteration of JavaScript. This does not leave room for any "pro".
  - Me1000 15y ago
    Two points: 1. We've been saying "the next version of javascript will result in world peace" for years now... 2. Dart does more than Harmony. A simple example is integers of arbitrary size.
- kibwen 15y ago
  Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2]. For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read). [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... [2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas... [3] https://news.ycombinator.com/item?id=2982497 https://news.ycombinator.com/item?id=2982497
islon 15y ago
The similarity with java give me the creeps... And I'm a java programmer.
pjmlp 15y ago
Dart will most likely join Wave, followed by Go.
jhrobert 15y ago
I'm getting bored with Javascript. I had a look at Julia and as a result I think that there is some solid value in designing a language whose performance can match C if needed yet use dynamic typing when convenient. I just don't know what to do next: CoffeeScript or Dart? Both improve on Javascript. CoffeeScript with a cool syntax. Dart with performance. How can I have both?
- nxn 15y ago
  Since dart will have to compile down to javascript for any browser that isn't chrome* , there probably wont be much, if any, performance improvement that you can depend on. Your only way to be able to use the speed up would be to restrict your client base to chrome only users. With that said, regular old javascript is really a much more interesting language by itself than dart. Perhaps I'm opinionated, but I just don't see anything exciting about Dart. * This is based on most browser vendors not being supportive of it.
  - jhrobert 15y ago
    I just spent a couple of hours reading the Dart site. Dart is a web friendly optimized SmallTalk with a Javascript like syntax. It looks like Javascript but feels like SmallTalk. If that marketing trick works, it will be ironic because Scheme inspired Javascript looked like Java for the same marketing reason... CoffeeScript might be Javascript's swan song.
quatrevingts 15y ago
Dart just seems phenomenally boring. Now, I'm not necessarily against boring. A great synthesis of what we've learned thus far in PL design, breaking no new ground, but packaging it together into a nice cohesive whole would be very welcome. But Dart seems like just a minor rearrangement of Java which does little to make Java faster, safer, or more expressive. Why invest in Dart as opposed to Java 8 + GWT, or CoffeeScript for that matter?
- spankalee 15y ago
  GWT is pretty painful to use compared to Dart in my experience. Where in GWT you have long compiles or a very slow Dev Mode, in Dart you have extremely fast compiles and Dartium which is even faster. GWT's great when you like static typing, Java development tools, and Java libraries (which I do, so I use GWT), but Dart give you static typing if you want, especially with checked mode, and should support similarly awesome tools because of the typing. Libraries will hopefully come along, and quickly I predict because there won't need to be the equivalent of jQuery and all the classical inheritance implementations. If you're coming from GWT, just think of Dart as GWT but fast, designed to compile to JS with a native option, and much lighter-weight syntax and language features than Java.
  - quatrevingts 15y ago
    I don't see anything about the language though that would make it significantly faster to compile than Java... it seems to be a matter of development priorities for the implementation teams. (Dev mode can be pretty fast in my experience though, depending on the browser. For some reason there seems to be major performance issues with Chrome but not Firefox.) If the effort that went into building Dartium had simply gone into building a custom VM for GWT, couldn't we have achieved the same thing, but without the fragmentation? Perhaps Oracle's lawsuits are playing a role here.

30 points by Mamady 15y ago

When people say list, I think linked-list. When they say array, I think contiguous array. I wish we could standardize on that terminology, it makes sense and allows easy differentiation between the 2 concepts.

JulianMorrison 15y ago
Clojure implements them in trees of contiguous arrays :-P http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/ http://blog.higher-order.net/2009/02/01/understanding-clojur...
radarsat1 15y ago
I used to do that, but now I try to think in terms of the abstraction "list" and "array", and not worry about the underlying data structure unless I'm specifically thinking about efficiency. For example there are multiple ways of implementing lists and arrays that have similar interfaces but different efficiencies for insertion/sort/search, etc. So basically the dichotomy you propose is just "too simple," it doesn't cover all the options and combinations that a programmer may need to think about.
- DanWaterworth 15y ago
  I didn't say that it was a dichotomy, actually I tend to think of the space as roughly split into three: lists, arrays and annotated/sorted trees. Lists and arrays are really common though, so I think it makes sense to make it easy to refer to them using short words.
kibwen 15y ago
Funny, I had the exact same thought but with regard to Dart's maps (a.k.a. associative arrays, hash[maps], [hash] tables, dictionaries, records, objects (Javascript), or even just arrays (Tcl)).

kibwen 15y ago

From the (incomplete) overview here (and ignoring the type system for the moment), Dart appears to be reasonably competent and technically sound, given that this is a language intended to compile to Javascript. That said, it doesn't terribly excite me. It should be interesting to see whether the safety guarantees of optional typing and the few other restrictions it provides (such as more rigid function signatures) will really entice developers who are planning large web applications. I'm working on a modest-sized (~3kloc) Javascript codebase at the moment and it's somewhat of a mess, but that's really more due to the combined influence of legacy code, time constraints, technical debt, rapidly shifting requirements, and a lack of testing. Other than that last point, it's not immediately obvious how using Dart rather than Javascript would have benefited me. Perhaps someone who's worked with a more substantial Javascript application could provide a better answer.

mmurph211 15y ago
I think it's good to have a choice of language for front end web development and I think primarily this is what Dart is providing. That said unless Dart proves to be considerably faster than Javascript I don't think I'll be converting any old Javascript code bases. I agree they're certainly going to have to provide a convincing case for me to switch to Dart in the future but like I said right now it's at least nice to see a second choice being developed.
beza1e1 15y ago
Dart is not "intended to compile to Javascript". Dart is intended to compete with Javascript. Compiling to Javascript is just intended as a fallback.
- firefoxman1 15y ago
  This has probably been asked before, but why haven't any browsers worked on natively implementing CoffeeScript (not compiling to Javascript first)?
  - gcp 15y ago
    Because there is no advantage to that at all? Dart has more type information, so a Dart compiler has some hints to generate faster code. (And this is why fast JavaScript engines do type inference)

dgregd 15y ago

What are pros and cons of Dart support for Mozilla/Firefox?

scriptproof 15y ago
Cons: Not needed because all the stuff will be included in a next iteration of JavaScript. This does not leave room for any "pro".
- Me1000 15y ago
  Two points: 1. We've been saying "the next version of javascript will result in world peace" for years now... 2. Dart does more than Harmony. A simple example is integers of arbitrary size.
kibwen 15y ago
Dart can optionally compile to Javascript, so a program written in Dart will run in all browsers, albeit with a fair bit of overhead from the translation (exactly how much overhead remains to be seen, but Dart code compiled to Javascript will certainly be suboptimal, or else Google wouldn't bother implementing a virtual machine solely for Dart). As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2]. For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read). [1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018822.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... [2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas... [3] https://news.ycombinator.com/item?id=2982497 https://news.ycombinator.com/item?id=2982497

islon 15y ago

The similarity with java give me the creeps... And I'm a java programmer.

pjmlp 15y ago

Dart will most likely join Wave, followed by Go.

jhrobert 15y ago

I'm getting bored with Javascript. I had a look at Julia and as a result I think that there is some solid value in designing a language whose performance can match C if needed yet use dynamic typing when convenient. I just don't know what to do next: CoffeeScript or Dart? Both improve on Javascript. CoffeeScript with a cool syntax. Dart with performance. How can I have both?

nxn 15y ago
Since dart will have to compile down to javascript for any browser that isn't chrome* , there probably wont be much, if any, performance improvement that you can depend on. Your only way to be able to use the speed up would be to restrict your client base to chrome only users. With that said, regular old javascript is really a much more interesting language by itself than dart. Perhaps I'm opinionated, but I just don't see anything exciting about Dart. * This is based on most browser vendors not being supportive of it.
- jhrobert 15y ago
  I just spent a couple of hours reading the Dart site. Dart is a web friendly optimized SmallTalk with a Javascript like syntax. It looks like Javascript but feels like SmallTalk. If that marketing trick works, it will be ironic because Scheme inspired Javascript looked like Java for the same marketing reason... CoffeeScript might be Javascript's swan song.

quatrevingts 15y ago

Dart just seems phenomenally boring. Now, I'm not necessarily against boring. A great synthesis of what we've learned thus far in PL design, breaking no new ground, but packaging it together into a nice cohesive whole would be very welcome. But Dart seems like just a minor rearrangement of Java which does little to make Java faster, safer, or more expressive. Why invest in Dart as opposed to Java 8 + GWT, or CoffeeScript for that matter?

spankalee 15y ago
GWT is pretty painful to use compared to Dart in my experience. Where in GWT you have long compiles or a very slow Dev Mode, in Dart you have extremely fast compiles and Dartium which is even faster. GWT's great when you like static typing, Java development tools, and Java libraries (which I do, so I use GWT), but Dart give you static typing if you want, especially with checked mode, and should support similarly awesome tools because of the typing. Libraries will hopefully come along, and quickly I predict because there won't need to be the equivalent of jQuery and all the classical inheritance implementations. If you're coming from GWT, just think of Dart as GWT but fast, designed to compile to JS with a native option, and much lighter-weight syntax and language features than Java.
- quatrevingts 15y ago
  I don't see anything about the language though that would make it significantly faster to compile than Java... it seems to be a matter of development priorities for the implementation teams. (Dev mode can be pretty fast in my experience though, depending on the browser. For some reason there seems to be major performance issues with Chrome but not Firefox.) If the effort that went into building Dartium had simply gone into building a custom VM for GWT, couldn't we have achieved the same thing, but without the fragmentation? Perhaps Oracle's lawsuits are playing a role here.