4 ms·
Just like with any language, as long as you read the docs of the stuff you use, you don't get this problem (you might get others with automatic type conversion
by conradk 13y ago
Just like with any language, as long as you read the docs of the stuff you use, you don't get this problem (you might get others with automatic type conversion and missing arguments like the speaker says, but not this)... this is just stupid.
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.
- coldtea 13y agoThe thing is, good language design means you don't have to read the docs. 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).
- nathansobo 13y agoBoth behaviors make sense in isolation. It's not always so easy.
- gary_bernhardt 13y agoJuggling these interactions is exactly what makes good language design so difficult and time consuming. In the talk, I mention JS' ten-day design time several times for exactly this reason. Language design is hard and ten days just isn't enough time to carefully consider how everything will fit together. Try to imagine a programmer, even a brilliant one, noticing the map/parseInt interaction ten days after starting to learn JS, especially in 1995 when these high level languages were far less common. Seems unlikely!
- tolmasky 13y agoArguably the issue is not with the behavior but rather a deeper design problem within the language itself. Notice that in Obj-C no one would ever get confused regarding the second parameter of parseInt:withRadix:.
- elwell 13y ago> good language design means you don't have to read the docs 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.
- 1stop 13y agoBut the user of javascript will have more bugs.
- coldtea 13y agoThat's because: 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.
- DonHopkins 13y agoBy "this problem" do you mean "the this problem"? And by "this is just stupid" do you mean "this === just stupid"? If you think that's bad, you should see this!