There is a native VM for it that is fast and it has the highest chance of getting implemented in a browser (let's say higher than Typescript).
There is good tooling behind it (IDE, package system).
Google supports it. Whether we like it or not that makes a huge difference.
Native VM has good IO characteristics and can be used on the server side as well. (So can start using that on the server side without having to wait for browsers to embed it).
Does away with Javascript warts better than CoffeeScript.
That little side note there makes no sense at all. The runtime semantics of TypeScript are exactly the same as JavaScript. TypeScript is little more than some ES6 notation (class, =>, etc) plus compile-time type checking.
You could remove all types from a TypeScript file and it'll probably run fine on any existing JS VM that supports ES6.
Dart is faster because it lacks features that JavaScript has, such as dynamic loading or eval or adding fields to objects/classes, and has some special case hacks for SIMD.
One could easily tweak JavaScript to have the same lack of features and same performance gains (many could be done in asm.js style) so I do not see how Dart is relevant except as a way to not participate in the evolution of JavaScript.
Personally I feel that getting even a 50% boost on a scripting language that's never going to be as fast as C# or Java anyway, by making an additional incompatible VM, is totally foolish. Both VMs will be needed for many years, and this collateral bloat is just not worth the benefit. When you look at performance over JavaScript + asm.js the gains are seen largely where performance does not matter much anyway.
Exactly so unless it goes the asm.js route there is probably not much chance it will improve a lot over regular JS. Dart VM is already faster than JS VMs and it will probably get even better and faster in the future.
Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane. Taking a puritanical approach to programming and weeding out the imperfections leads to a very boring language. I understand the business argument, but creativity requires a certain amount of chaos, no? Or it depends on your theory of creativity I guess. Fair enough.
JS is not an artistic statement, it's a programming language foisted on us by corporate politics and Industry.
Also, mental chaos begets creativity. Chaos emerging from tools only serves to impede the expression of those using the tool. I'm not sure how you can argue how a tool that works against the user in a non-performance art is a good thing.
>Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane
Programming is not like "art" in that anything goes as long as it's an artistic statement. Programming is pragmatic and goal oriented, and the goals are not the expression of the inner self.
Sure, you can do some programming with an artistic intent (e.g code obfuscation stuff), but that's the exception rather than the rule. "Code as poetry" and "Hackers and Painters" are tired metaphors.
As for "glitch", those imperfections are not actual imperfections, but desirable and genre-defining elements. Glitchs exists because it HAS those. Programming doesn't exist to have imperfactions -- it exists to execute some kind of task.
That's about as valid as "Street cleaning is an art form, if for you street cleaning is art".
To quote an old essay:
= = =
"Let me say it simply - hackers are nothing like painters.
It's surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. (...) The closest he comes to a clear thesis statement is at the beginning "Hackers and Painters":
"Of all the different types of people I've known, hackers and painters are among the most alike. What hackers and painters have in common is that they're both makers."
To which I'd add, what hackers and painters don't have in common is everything else. The fatuousness of the parallel becomes obvious if you think for five seconds about what computer programmers and painters actually do:
Computer programmers cause a machine to perform a sequence of transformations on electronically stored data.
Painters apply colored goo to cloth using animal hairs tied to a stick.
It is true that both painters and programmers make things, just like a pastry chef makes a wedding cake, or a chicken makes an egg. But nothing about what they make, the purposes it serves, or how they go about doing it is in any way similar.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task. Even the most elegant of computer programs, in order to be considered a program, has to compile and run [1]. So just like mechanical engineers and architects, computer programmers create artifacts that have to stand up to an objective reality. No one cares how pretty the code is if the program won't work.
The only objective constraint a painter has is making sure the paint physically stays on the canvas (something that has proven surprisingly challenging). Everything beyond that is aesthetics - arranging colored blobs in a way that best tickles the mind of the viewer.
This difference is what makes programming so similar to engineering, which also tries to create beautiful things in the face of objective constraints, but it's a parallel that really rankles Graham.
Design choices, in terms of the code structure and what is maintainable to you vs another person, are subjective in that they are often driven by personal choice and a sense of what is elegant. Your thinking is too left brained.
Says who? someone who doesn't the discipline to stay polite online? You think all design choices are driven by objective thinking? Funny, but not a valid response IMO.
There is a native VM for it that is fast and it has the highest chance of getting implemented in a browser (let's say higher than Typescript).
There is good tooling behind it (IDE, package system).
Google supports it. Whether we like it or not that makes a huge difference.
Native VM has good IO characteristics and can be used on the server side as well. (So can start using that on the server side without having to wait for browsers to embed it).
Does away with Javascript warts better than CoffeeScript.