Map is solving the real problem of code duplication for the scenario "create a new list whose elements are the elements of the original list to which f was applied". Not only does it reduce boilerplate but when you read map(f, list) you know that the result is gonna be a new list of the same size, that if f = id you're gonna get the same list, etc. In other words, map has invariants. It captures a tiny subset of all the for loops you can write.
Saying "we don't need map, we have for", is akin to saying "we don't need toUpper, we have for loops" or "we don't need functions, we have goto".
I attempted not to. What pulls me back is the fact that I am trying to force go to help me reuse data structures I already have (without turning to reflection everytime or manually typecasting).
Google engineer here too. I completely agree with the fast edit/refresh cycle being a huge plus but that's precisely what Dartium (the build of Chromium that includes the Dart VM and ships with the Dart editor) is for.
Yes, developer workflow is one of the key points I think anyone who has looked at the Dart documentation would get. Or, better yet, even try using the language for five minutes.
As a Dart learner, thank you. Dart IDE is great. It has some rough edges, it is new, but I like that the IDE is developed along the language and the VM. It make a difference.
You don't need a VM to compile something into Javascript but the VM buys you a fast edit/reload cycle and some tooling like a debugger. Also Dart can be used as server-side language and there the VM makes sense. It can also be used as an interpreted language just like Python and here it doesn't hurt if it's fast.
Even if _you_ don't put type annotations in your code, the IDE infers types (locally) and gives you useful warnings and code completion.
- Every Javascript program is a valid typescript program so typescript doesn't fix JS semantics (like variable hoisting and the only numeric type being floats). I think typescript is a good fit when you already have some big JS project and you want to get some type errors by loading a predefined signature for jquery or whatever library you're using. You basically get a linter + code completion for free on a pre-existing project. But if I have the choice between Javascript and any other language with saner semantics to start a new project, then I will for sure not chose Javascript.
- I don't think that Dart aims to "replace the entire JacaScript runtime in all browsers", even though the Ars Technica article says so. It's an alternative to Javascript, exactly like Ruby is an alternative to Python. Of course there's a difference between Js vs Dart and Python vs Ruby: every browser runs Js and only Js. That's why the story with Dart is: develop with the VM and Dartium, so that you can reload you application with F5, use the debugger, etc. and then deploy by compiling to Javascript.
Sorry, what do you mean by function hoisting? The fact that you can write mutually recursive functions at toplevel? Anyway, I was referring to variable hoisting.
The point is right now JS developers of big apps write this kind of comments because they are understood by tools like https://developers.google.com/closure/.
Saying "we don't need map, we have for", is akin to saying "we don't need toUpper, we have for loops" or "we don't need functions, we have goto".