Earlier quoted context omitted.
You could say it's a snipe at the weak type system that Javascript has. I dunno, as someone without much experience with Javascript, it is a little odd that arrays return the index alongside the value by default.
It has little to do with the type system. Variadic arguments can be typed given a type system that supports it.
The Birth and Death of JavaScript [video]
91–100 of 236 posts
Re: The Birth and Death of JavaScript [video]
#92Earlier quoted context omitted.
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 wa…
The 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, a…
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.
Re: The Birth and Death of JavaScript [video]
#93Earlier quoted context omitted.
couldn't quite make it out, what did he correct?
The second JavaScript example, when he told someone in the audience, "No, that's just an object." It was a string.
I've probably seen twenty people call this "wrong", which frustrates me. It's not wrong. It was a stringified object! I didn't say "stringified" because it wasn't relevant to the question of whether the object was in an array!
There are other things in Wat that are genuinely wrong, though, like the fencepost error about "16 commas", which mistake will haunt me forever.
Re: The Birth and Death of JavaScript [video]
#94Earlier quoted context omitted.
The 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, a…
> 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.
Re: The Birth and Death of JavaScript [video]
#95The reason why metal doesn't exist now is because you can't turn the memory protection stuff off in modern CPU's. For some weird reason (I'm not an OS/CPU developer) switching to long mode on an x86 cpu also turns on the mmu stuff. You just can't have one without the other. There's a whole bunch of research done on VM software managed operating systems, back when the VM's started becoming really good. Microsoft's Sin…
I didn't want to go into this level of detail in the talk, but... I think you still want the MMU enabled, just not used for process isolation. With virtual memory totally disabled, a 1 GB malloc takes 1 GB physical memory even if it's not touched, you can't have swap at all, memory fragmentation kills you dead, etc. It still has a lot of utility outside of isolation. I don't have a good sense of how the performance c…
It has a single 64-bit address space and only protection contexts, and due to the general design of the system it doesn't require any register push(or registers at all, at least in the traditional sense). In addition, it has primitives which would allow programs to call directly into drivers and kernel services without a context switch.
Anyway, I don't mean to sound like an advertisement, and we've yet to see any silicon, so the jury's out.
Aside: Starting process address spaces at 0 is not really a convenience as far as I know(other than offering consistent addresses for jumping to static symbols), it's a way to enable PAE on 32-bit machines so that single contexts(typically processes) can use the whole address space.
Re: The Birth and Death of JavaScript [video]
#96Earlier quoted context omitted.
The 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, a…
> 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.
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.
Re: The Birth and Death of JavaScript [video]
#97Earlier quoted context omitted.
with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)" The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)
"int" doesn't imply anything about the base.
Re: The Birth and Death of JavaScript [video]
#98He says several times that JavaScript succeeded in spite of being a bad language because it was the only choice. How come we're not all writing Java applets or Flash apps?
Javascript, on the other hand, was omnipresent and comparatively accessible. It was the least bad option by a wide, wide margin. For a different comparison, I switched from Java applets to PHP in the early 2000s. I didn't really get into Javascript until many, many years later around 2009: before that, Javascript was mostly a way to make Flash work properly.
Re: The Birth and Death of JavaScript [video]
#99Very impressive to have been recorded "April 2014" and released "April 2013." Seriously, though, great presentation.
Agreed! I too was wondering isn't the discovery of time travel the bigger story here? /s
Re: The Birth and Death of JavaScript [video]
#100Earlier quoted context omitted.
The second JavaScript example, when he told someone in the audience, "No, that's just an object." It was a string.
I knew that it was a string. If you listen closely, you'll hear that he asked "is that an array of object?" He probably asked that because it's in square brackets. I said "No, it's just an object". I've probably seen twenty people call this "wrong", which frustrates me. It's not wrong. It was a stringified object! I didn't say "stringified" because it wasn't relevant to the question of whether the object was in an ar…