I'm disappointed. Where is the innovation? We'll be stuck with JS forever.
Dart still has a long way to go towards being mainstream, but I think this will help reduce some of the controversy surrounding it and people can focus on what it brings to developer productivity and app quality.
I hope this happens. Javascript seems like a depressing future to me - even if it's only a compilation target for major shops.
IMO it is much better to focus on improving compile-to-web support with things like bytecode, better debugging, threading, custom value types, hooks into the garbage collector, etc., etc. - making it feel more like "compilation", less like "transpilation" (to the extent the term implies that you have to look at the output) - than to change the number of blessed languages from one to two. The result, if used to compile Dart (or any other language), might sacrifice a bit of performance compared to the maximum achievable by a dedicated Dart VM, but not that much, and there are myriad advantages.
But in the meantime I'd prefer Dart to JS.
Of all the developers I know that I went to university with a few years ago all with just a few exceptions have moved on from vanilla-js to compile-to-JS languages by now (Dart, Clojure, CoffeeScript, TypeScript, …) and the others are on the fence.
What we need is for JavaScript to become a better compilation target and for even more language innovation. Dart is the most ambitious compile-to-JS option. Take a look at Dart's stdlib, packages and support in IntelliJ.
The better dart2js gets (it is really good by now but I can't wait to see how more focus on it will take it further) the more scenarios where Dart can be used in. Just think about all the places that come with a JavaScript runtime nowadays.
Just think of how the JVM allows people to write Lisp/Clojure in enterprise settings. Having a better and better dart2js story allows people to use the tools they prefer without hitting a bureaucratic wall ("compiles to js? fine.").
> Dart is the most ambitious compile-to-JS option.
Wait WHAT?
Not sure if this is supposed to be irony, but if not I'd like to understand your opinion on this.
I'd recommend instead a comment like: "Consider $otheroption, it has $feature1, $feature2, and $feature3. Furthermore, it is entirely committed to $designprincipal, which provides complete safety against $classofmistake when used correctly, without any $kindofdownside."
This way your reader has something to engage with other than your emotional reaction, and they may have learned something along the way.
I gave a talk about it recently if you want to see.
Why you have such intense and strong feeling toward a programming language?
It's just a programming language after all, nothing more nothing less
You're very much the one with the "strong feelings" there, accusing "intellectual laziness" for not putting real efforts in a language which is simply not worth anyone's time - not to mention assuming that people who think the language is inferior actually use it.
As I said, it's a productivity decision. The opposite of laziness.
If you wanna do any consumer facing web stuff, you gotta code in js in one way or another. So, if you don't do any web stuff that's fine but other people doing any serious front or back end web stuff have to master the language to get the maximum out of their work.
Anyway, good luck with your darling langs
You're 0 for 3, yet you're still acting smug. I'd take a look into that if I were you. Take this as general advice.
Edit: I saw your comment below - I'm done replying to you directly, you're probably not a troll, but it's sad that you behave like one.
You seem very agitated and disturbed for no apparent reason. We're discussing prog langs after all. Maybe you need to explore sports or politics to vent your anger as it's building up and you might explode anytime :L:
I believe 'gcc -S' would demonstrate not. If my understanding is correct, it produces essentially asm internally regardless of that flag, but subsequently assembles and links it without presenting it externally, -S just makes it stop and dump the asm.
No idea about other C compilers, but it wouldn't surprise me if they have some similar feature.
So common that it is unclear to me which of producing textual asm output or machine code is most common. Certainly there's been periods were the attitude was that producing machine code directly was unnecessarily complex and didn't belong in the compiler.
In addition to being wrong, the parent's point is also incredibly nitpicky.
With ES8 or ES9, maybe.
By the way, optional named arguments with default values look atrocious in ES6.
ES6: function foo({a = 1, b = 2} = {}) {…}
Dart: foo({a: 1, b: 2}) {…}
Dart also supports things like factory constructors, named constructors, method cascades, operator overloading, SIMD, arbitrary large integers, mixins, implicit getters/setters, implicit interfaces, enums, 'a' - 2 is a type error, [0][-1] is a range error, metadata annotations, and of course also optional types.
ES7 might include SIMD and operator overloading.
Another key point is that Dart's doc comment syntax is standardized. It also has an official style guide, a formatter, and a package manager.
To me, these things are also very important features.
new Date(2015, 1, 1)
http://stackoverflow.com/questions/1969442/whats-wrong-with-...
Actually I think it's pretty terrible how few languages have literal expressions for dates. Once you have to type "new Date(", it's not much more annoying to have to remember that January is zero.
class Month {
static const List<String> names = const <String>[
"JAN", "FEB", "MAR", "APR", "MAY", "JUN",
"JUL", "AUG", "SEP", "OCT", "NOV", "DEC"
];
final int month;
const Month(this.month);
MonthDay operator -(int day) => new MonthDay(month, day);
String toString() => names[month - 1];
}
class MonthDay {
final int month;
final int day;
MonthDay(this.month, this.day);
DateTime operator -(int year) => new DateTime(year, month, day);
String toString() => "${Month.names[month - 1]}-${"$day".padLeft(2, "0")}";
}
const Month JAN = const Month(1);
const Month FEB = const Month(2);
const Month MAR = const Month(3);
const Month APR = const Month(4);
const Month MAY = const Month(5);
const Month JUN = const Month(6);
const Month JUL = const Month(7);
const Month AUG = const Month(8);
const Month SEP = const Month(9);
const Month OCT = const Month(10);
const Month NOV = const Month(11);
const Month DEC = const Month(12);
main() {
print(MAR-25-2015);
}http://www.cplusplus.com/reference/ctime/tm/
tm_mday = day of month (1-31) tm_mon = months since January (0-11)
Which AFIAK goes all the way back to POSIX standard.
The real problem is that JavaScript as higher level language decided to inherit this awkward convention instead of making their own, consistent rules.
Given the time it took to create the first JS implementation, it is no wonder that some shortcuts were taken.
new Date(Heisei, 27, 1, 1)The problem is not with parameter ordering. Year and day are literal, month is zero indexed. So you wind up with (month -1) representing the actual month.
It seems to me that you are not doing your homework and studying hard to get things done professionally.
AtScript is dead now. The Angular folks are switching to TypeScript.
And innovation is right here: http://babeljs.io