Microsoft shoots down Google's Dart
news.cnet.com
news.cnet.com
This is only from my own experience but I'm consistently blown away by how little people actually know of JavaScript. Between interviews and looking at samples attached to jQuery Mobile issues all day I get the impression that most people don't know how to use the prototype system at all and generally organize their code as a series of jQuery event bindings.
While this isn't necessarily and endorsement of Dart, I welcome anything that can provide/encourage well-known and sane code reuse patterns.
edit: I have the rhino book. I meant, learning alternatives to organizing my code as a series of jQuery event bindings.
http://yehudakatz.com/2011/08/12/understanding-prototypes-in...
And the JavaScript Patterns book is a good read to get an overview of what can be done with just JavaScript. If your application is even remotely complex you'll probably end up using something like backbone or sproutcore which provide constructs for organizing your code anyway.
This video series is excellent (and provides a bit of CS history) http://yuiblog.com/crockford/
Also his book, Javascript: The Good Parts
> The Office Web Applications, which consist of hundreds of thousands of lines of JavaScript, are written primarily in a variant of Script# that is then compiled into JavaScript that can be executed on today’s browsers. http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...
Apparently Script# is quite mature now, and is being used to compile very large apps to JavaScript. This is a big vote of confidence from Microsoft regarding JavaScript as a compilation target.
I'd say the same thing about Google's own Closure, which they oddly enough don't mention alongside CoffeeScript et al.
I see Dart as a rethinking of much of Closure so I don't quite get what Microsoft thinks the difference between their Script# and Dart/Closure is.
GWT and Script# are both quite mature at this point, it looks like. Very interesting stuff. (However, GWT is probably losing focus inside Google to Dart, so I am not sure of its long-term prospects. It's open source though so anyone can continue it if they want.)
Programming in Closure-style JS feels like you're using an optionally-typed class-based language, just one with really terrible syntax.
Why don't browsers support a sand-boxed python (or insert favorite language x) with some sort of standard dependency management? It already has JIT compilation, is cross-platform, bytecode, a wealth of libraries, etc. Why are we reinventing this wheel?
Does it mean lambdas or other anonymous functions? Python lets you close over names at any scope and define functions anywhere; you don't need the "lambda" keyword. Even if you want to only use lambdas, it's been shown that Python does not need statements, only expressions, to express everything, although you quickly turn your code into Scheme-soup. JS doesn't somehow improve on this.
Is it first-class functions? Python has those, just like JavaScript, although Python goes further, enabling you to have real bound methods, descriptors, properties, class methods, and all other kinds of fun.
Is it map, filter, and fold? Python's still got map, filter, and fold (foldl, called "reduce" in Python.) Python also has list comprehensions, borrowed from Haskell, as well as generator expressions, providing that valuable laziness that some functional languages value so much. And, in Python 3, there are set and dictionary comprehensions as well. JavaScript doesn't have comprehensions at all.
Is it referential transparency or immutability? Unlike JavaScript, Python refuses to allow you to edit the values of certain builtin types, like str and unicode.
So, uh, what did you mean, exactly?
Even if you were right, you could still make code that doesn't use these features fast, and slow back to interpreted if any of these features is used -- that's what JS JITs do when they see "with".
And finally, Lua is as dynamic as Python (both of which are, in my opinion, less dynamic than JS thanks to lexical binding). And Lua has been made significantly faster than any Python or JS implementation (Mike Pall's LuaJIT2)
The fact that Python has "a wealth of libraries" isn't particularly pertinent--web apps mostly need web-specific libraries, which Python doesn't have (because it isn't in the browser). Most people using JavaScript get by with jQuery, maybe some web ui framework and perhaps something like Raphael. And, with the advent of node and server-side JavaScript, JavaScript is getting more and more libraries outside of the browser as well.
Of course, the browsers could support a bunch of different languages, but I think the complexity outweighs the (limited) benefits. Google, obviously, disagrees and thinks that Dart should also be an option, but I really think it isn't worth the effort.
Ultimately, JavaScript is more than good enough as a browser language; while it does have some annoying quirks, upcoming versions (and things like "use strict") are getting rid of most of them. There really is no overwhelming reason to switch away from JavaScript, and even just adding another language is probably not worth it.
I'm not claiming that python wouldn't need a new standard library to manipulate a browser's dom tree or whatever. That's about all it would need though, so it seems like it would have been far less work to embrace and extend than to completely start over.
You seem to be arguing from the perspective (and please correct me if I'm wrong) that javascript is a good solution and a fine programming language, and I am not claiming otherwise. I just don't understand why so much effort has been spent creating and polishing Javascript instead of making slight improvements to a previously established quality language.
I suspect the answer is that your browser has an advantage if your javascript engine is faster, but there can be no advantage if everyone uses the standard python interpreter.
Also, unless I'm unaware of something, wasn't Perl the most popular scripting language back then? So if they had included an already existing language, Perl would probably have been the best bet.
Embedding Perl was (and is) painful. Tcl would have been easier.
Sandboxing would have been more difficult. Auditing all of Perl 5's operations for the possibility of escaping that sandbox is a huge task.
Since native environments often give the developer a greater degree of language-choice freedom as well as greater degree of access to complex APIs, I fail to see how offering the same freedoms in the comparatively miniscule browser API would cause the complexity to outweigh the benefits.
If browser makers just standardized on a language-neutral runtime like the JVM or the CLR then no central committee would have to be responsible for maintaining support for specific languages.
1. Python is not sandboxed. Security is necessary in a web browser. 2. Python has some JIT work, mainly PyPy, but even so is much slower than JavaScript. 3. You can compile Python into JavaScript (see demo at repl.it), where it will be sandboxed.
Similar reasons apply to other proposed languages, for a web language we need security, speed, standardization, and portability (and often we can already compile them into JS, so the motivation is lessened anyhow). I am unaware of any option that has all of those to the extent that JavaScript does.
Disclaimer: I work at Microsoft.
Also, the VM wouldn't be required, it would just provide performance improvements.
This can be done for CoffeeScript et al too - efforts are already underway.
Also, the VM wouldn't be required, it would just provide performance improvements.
There's just too much embrace-extend-extinguish risk for anyone but Google in that. That's why Mozilla and Microsoft are burning it at the stake.
Readable, debuggable JS is a high priority for Dart's Dart->JS compiler.
I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so integer math could overflow into doubles for example, but the Dart VM did use native types (so ints would not overflow). So the semantics of the language differ in JS and in the native VM, which means the VM doesn't just provide speed, it provides different behavior.
Is this no longer the case - are the semantics of Dart-in-JS and in the VM exactly the same?
JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different.
I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong.
Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy.
Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases.
Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code?
Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Especially given some of the horrible characteristics of the language [JavaScript]
It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.
This is something we're aware of and we know we need to be extra clear and loud about it.
> Also, integer overflow is not the only case where this problem arises.
As far as I know, bigints are the only place where the VM and the generated JS intentionally differ in behavior. We are trying very hard to keep the two in sync.
> It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers?
Dart has two division operators (~/ and /) to handle this. The former rounds (truncates? I'm not sure) and the latter does floating point division. So it's always the operation that determines the type of the result, and not the type of the operands.
> Overall, it seems much simpler and safer to just correct overflows in the compiled code.
Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
Rolling your own numeric type in JS means slower behavior when you have overflowed and slow behavior even when you haven't. If you're generating code for "a + b", you can't compile that to "a + b" in JS because you need to check for overflow and handle the fact that a or b could be bignums.
We really want the compiled JS to behave the same as native code, but if it's significantly slower, people just won't use it at all. It's an unfortunate trade-off.
> Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
In my experience with something similar - compiling LLVM to JavaScript in Emscripten, which also needs to properly implement integer math in JavaScript - it actually isn't a lot slower. On the Emscripten benchmark suite enabling overflow correction everywhere makes it only 5% slower. We might be running very different benchmarks I guess.
(However, overflow correction does increase code size a lot, which is why we have tools that let you get rid of it where it isn't needed.)
Disclaimer: I work for Microsoft.
I don't think this is entirely true. IE still has more than enough marketshare to matter. Microsoft embracing some approach, be it a new language, or be it evolving JavaScript, has influences in how likely the efforts of the other teams are to succeed in the marketplace.
;-)
In a sense, it did. There are tons of IE6 installations in companies that built "web-based" applications that run only on IE6 and they won't upgrade to newer Microsoft browsers soon. OTOH, IE6+7+8+9 still has a huge percentage of the market and some flavor of IE comes pre-installed on about every desktop computer sold and web developers still have to cope with partial or incorrect support for many newer standards.
Natively run Dart will (otherwise, what's the point) than the JS it can be compiled into. What I forsee is some kind of conditional that will allow Chrome to run the Dart code, and other browser get served the compiled-into-JS.
Demanding an extension installation is a no-go.
I'm not sure that is the case, because of the native Dart VM.
CoffeeScript compiles very straightforwardly into JS, with similar performance to normal JS. But Dart is significantly different, and the Dart VM could be faster than Dart-compiled-to-JS, both because (1) The Dart VM will be optimized for Dart in new ways, and (2) It isn't clear that Dart code will be extremely efficient when compiled to JS.
So CoffeeScript adoption needs no support from browser vendors, but Dart, if it is to fulfill its goal of being fast, might need the Dart VM. And that does need browser vendor support.
Also, it seems there are a lot of people who don't like Javascript and try to either replace it or compile down to it. I don't understand why. I love Javascript. I think it's terse and powerful. It's a perfect fit for web applications. Sure, there may be a few annoying flaws, but it works well for its intended purposes. Also, add a few libraries, or a real framework like Mootools, and most of the flaws vanish.
Also, if we're going to go around creating systems for creating web apps that compile to javascript, can we PLEASE use languages that allow macros (ie a lisp variant)? Does another C-like language really add anything? (I'm actually asking, not judging)
Now that they discontinued the plugin (was it a month ago?), they feel it's OK to criticize Google's approach.
> In addition, Microsoft's actions against Android, while despicable, are hardly different than what most other tech companies are doing,
Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
About C#: Microsoft has stated several times that open is not the same as patent-free. They did so in context of Linux/Android, but also in the context of .net. Also, anaylis exist where C# tech is tied to patents.
Cool story, bro. Most people these days either use the browser that comes with the OS, or install the one they want.
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
[Citation needed]
From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
You seem to have a hard time differentiating the language, C# from the library, .NET. It's similar to C++ and the STL.
This does not refute in an way that MS quit the EEE game. Merely, you seem to troll me ("Cool story, bro.").
> Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
> [Citation needed]
I am not aware of industrywide patentfights regarding software patents. Telecom companies do battle each other ferociously over patents, which are not necessarily for software (from what I read, not relatively many software patents are involved).
> From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
If MS decides to sue they decide to sue.
I'm trolling you because the claim that MS is trying to EEE HTML/JS/CSS by implementing hardware support for rendnering in IE is inane. Both Chrome and Firefox have the same capabilities, and I've seen more that one site (I actually use IE9 for specific reasons) that usually point me towards the usual bunch.
>Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
So what in your mind makes Apple and Oracle different from Microsoft? If not, just concede the point: hating the players is pointless, the game is broken.
> If MS decides to sue they decide to sue. Your point here is? Sure, if I implemented C# according to the standard and my own set of libraries, the company could try to sue me. I am positive they wouldn't get very far. But continue on with your Stallman like conspiracy theories.