Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Birth and Death of JavaScript [video]

destroyallsoftware.com

Post reply on HN
Print view View original

141–150 of 236 posts

Re: The Birth and Death of JavaScript [video]

#141

Post by ajanuary »

Iftheshoefits wrote: post #102
djur wrote: post #90

Earlier quoted context omitted.

"int" doesn't imply anything about the base.

It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human cons…

> It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default

It does.

> and entirely unreasonable to expect to be required to provide a base as anything except an optional argument

It is optional.

> and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation

I don't understand what you're saying here. It's never treated as required, it's just map supplies a parameter in that position, so it get's used. That's how optional parameters work.

The wat (if there is one) is that map provides extra arguments.

Re: The Birth and Death of JavaScript [video]

#142

Post by thousande »

kevinwang wrote: post #123
jliechti1 wrote: post #17

For those unfamiliar, Gary Bernhardt is the same guy who did the famous "Wat" talk on JavaScript: https://www.destroyallsoftware.com/talks/wat

The video seems to be down now? Anyone have a mirror? edit: nevermind, I clicked the download link. But I'm still wondering why the video's unplayable on the site.

Works with Chrome not Firefox. Yay! 2014 ;)

Re: The Birth and Death of JavaScript [video]

#143

Post by ajanuary »

bsder wrote: post #57
nathansobo wrote: post #47

Earlier quoted context omitted.

I just wrote this line about two hours ago and my tests weren't thorough enough to catch the bug it introduced. Just when I thought I knew JavaScript. Thanks for saving me some time.

Always give the base to parseInt in Javascript. Always. The moment you don't, all kinds of bugs follow. I have to go cry now at the number of times this has bitten me.

Not just javascript, a whole bunch of language's parseInt implementation will interpret the base from a leading zero etc.

Re: The Birth and Death of JavaScript [video]

#144

Post by rplnt »

briantakita wrote: post #132
hcarvalhoalves wrote: post #83

Earlier quoted context omitted.

I don't think `parseInt` accepting an optional second argument is the surprising behavior there. The real WTF is `map` passing more than one argument, and the loose behavior of JS regarding argument passing overall.

It's only WTF because it's not the same as other implementations of map. Once you can internalize the map implementation, it's no longer WTF & actually makes sense.

That's the weird part. Why does array provide three arguments? But I agree, that's something you can learn. I guess.

But it's WTF anyway. I have a function that takes either one or two arguments, I provide three, and everyone seems to be OK with that.

Re: The Birth and Death of JavaScript [video]

#145

Post by cornholio »

nly wrote: post #104
gary_bernhardt wrote: post #88

Earlier quoted context omitted.

I didn't know that! It certainly makes sense. Context switches still thrash the TLB, though. The performance cost of that has gotten better as time has gone on, but I wonder how many transistors (and how much power) CPUs are burning for that mitigation. The "how computers actually work" digression originally had a section on context switches, but I removed it early on because I felt like that section was dragging. To…

What you seem to be missing with re: asm.js is that, while the JIT to native code gets you your super-fast integer operations, it's still critically incomplete with regard to memory access. Every single individual memory access has to be bounds checked or pushed through some other indirection inside the runtime. Google demonstrated similar ideas with NaCl, which achieved safety with a similarly restricted native code…

I agree, and I think the whole premise of the performance gain is based on a "have the cake and eat it too" fallacy. Sure, the virtualized syscall to the virtualized OS will be free, but the painting of the font on the screen or the reading of the socket data will be done by the actual bare metal OS which the VM will invoke to get the actual job done.

So as long as we are talking about interprocess communication there will be a gain, but not for the actual hardware facing operation.

Then again, you are trading a hardware enforced isolation which is simple and proven for a isolation enforced by a complex and fragile VM.

Re: The Birth and Death of JavaScript [video]

#146

Post by ajanuary »

granttimmerman wrote: post #25

> xs = ['10', '10', '10'] > xs.map(parseInt) [10, NaN, 2] Javascript is beautiful.

A useful function

    function overValues(f) { return function(x) { return f(x); } }
Then you can do

    ['10', '10', '10'].map(overValues(parseInt));
However, usually you're going to want to do the equivalent of this

    ['0101', '032'].map(function(s) { return parseInt(s, 10); })
Because Javascript interprets a leading zero as an indicator of base.

Re: The Birth and Death of JavaScript [video]

#147

Post by [deleted] »

ajanuary wrote: post #141
Iftheshoefits wrote: post #102

Earlier quoted context omitted.

It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human cons…

> It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default It does. > and entirely unreasonable to expect to be required to provide a base as anything except an optional argument It is optional. > and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation I don't understand what you're saying here…

[deleted]

Re: The Birth and Death of JavaScript [video]

#150

Post by espadrine »

hetid wrote: post #107
gary_bernhardt wrote: post #93

Earlier quoted context omitted.

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…

It's only 15 commas man, 15 commas. That extra comma could kill someone. Speaking of which, why does WAT do different things on node.js?

> why does WAT do different things on node.js?

Wrapping the same input in parenthesis (eg, '({} + [])') yields different results.

Post reply on HN