Try this:
int subtract(int b, int a) { return a - b; }
int test = subtract(5, 3); // != 2, just read the damn docs
Oh, C sucks now !
The talk is quite fun and interesting to watch though.
And the end is pretty cool.
Try this:
int subtract(int b, int a) { return a - b; }
int test = subtract(5, 3); // != 2, just read the damn docs
Oh, C sucks now !
The talk is quite fun and interesting to watch though.
And the end is pretty cool.
The number one thing taught at user interaction / usabillity courses is that users don't read the documentation. Or skim it and go directly to one or two parts they want to check (Sure, some bizarro outliers do read it all).
Besides, a golden rule from the UNIX era is the "principle of least surprise". Don't define stupid behavior as default, as in this case (both for parseInt and Map).
Let's assume JavaScript is a poorly-designed language, and Clojure is a well-designed language. In the first month of language use, the user of Clojure will have looked at the docs many more times.
1) Clojure has a larger API -- Javascript doesn't have 1/10 that.
2) Javascript has a familiar (to many) Algol-derrived braced syntax and lots of common C/C++/Java/etc keywords. Clojure is only familiar to Lisp/Scheme users.
If those things were equal, Clojure would win the "don't have to look caveats up" contest, because its design is more coherent, and doesn't give you unexpected results and undefined behavior like Javascript does.
Obviously, you somehow you need to first know that "parseInt" is called "parseInt()" and not "atoi()" for example. But I wasn't implying never reading anything, including function reference. Just being able to code without needing to study and/or memorize lots of arcane edge cases.
And by "this is just stupid" do you mean "this === just stupid"?
If you think that's bad, you should see this!