Live data from Hacker News

Wat (2012) [video]

destroyallsoftware.com

21–29 of 29 posts

Re: Wat (2012) [video]

#21

The WAT talk was rhetorically nice because it managed to joke about weird corners of the language without going into ranty programmer mode, but opted for a more gentle style of bemused boggling. It also kind of cemented for me that weird edge cases don't actually matter in practice (in my experience), and that a language can have lots to make fun of while still being lovely to use.

I had the opposite reaction. I thought the "wat" talk was entertaining of course, but I've found that it has generated a significant amount of hate towards JavaScript among laypeople who don't really understand that every language has weird caveats and edge cases like this.

Re: Wat (2012) [video]

#22

The WAT talk was rhetorically nice because it managed to joke about weird corners of the language without going into ranty programmer mode, but opted for a more gentle style of bemused boggling. It also kind of cemented for me that weird edge cases don't actually matter in practice (in my experience), and that a language can have lots to make fun of while still being lovely to use.

> It also kind of cemented for me that weird edge cases don't actually matter in practice

Just look at the linux kernel. The tremendous amount of complexity and code need to support all the weird edge cases of hardware that does pretty much the same thing is mind boggling.

If you can ignore the edge cases yeah they don't matter, but as a language implementer these things matter. For the user, they are always present, when by mistake or by choice they are used, then they will matter.

So yeah, weird edge cases matter a lot! In fact trying to minimize them is very important to keep the complexity of systems down.

Re: Wat (2012) [video]

#23

The WAT talk was rhetorically nice because it managed to joke about weird corners of the language without going into ranty programmer mode, but opted for a more gentle style of bemused boggling. It also kind of cemented for me that weird edge cases don't actually matter in practice (in my experience), and that a language can have lots to make fun of while still being lovely to use.

> It also kind of cemented for me that weird edge cases don't actually matter in practice Just look at the linux kernel. The tremendous amount of complexity and code need to support all the weird edge cases of hardware that does pretty much the same thing is mind boggling. If you can ignore the edge cases yeah they don't matter, but as a language implementer these things matter. For the user, they are always present,…

Trying to minimize edge cases can also increase complexity. As a specific example look at the behaviour highlighted in this talk where he shows the result of adding two nonsensical types. In most cases there is probably no sensible result except TypeError, but...

- Throwing a TypeError in those situations would itself require that particular edge cases are specifically defined in the spec to return TypeError, therefore actually making the spec more complex and creating more error situations for code to deal with.

- Some might get a benefit from the "implicit" behaviour even if it usually makes no sense at first glance (only in context with the other rules). Whereas TypeError is never useful in the happy path. An important idea in dynamic languages is to let the caller decide if a particular usage of a type makes sense, rather than the callee.

Re: Wat (2012) [video]

#24
post #11
post #7

WAT is classic and very funny, but I recommend all software engineers to watch all of Gary Bernhardt's talks on his website: https://www.destroyallsoftware.com/talks His talk about "Boundaries" taught me one of the most illuminating concepts I've learned in my career, about separation of concerns, functional core & imperative shell, unit testing, etc., and radically changed the way I write code - the talk uses Ruby a…

> I recommend all software engineers to watch all of Gary Bernhardt's talks They are all great talks, but please don't use "The Birth & Death of JavaScript" as an instruction manual! In addition to the talks on his website, I also recommend watching "The Unix Chainsaw"[1]. It's a great introduction into using the full power of the unix shell as an interactive programming language. [1] https://www.youtube.com/watch?v=…

> They are all great talks, but please don't use "The Birth & Death of JavaScript" as an instruction manual!

Heretic. "The Birth & Death of JavaScript" is the Holy Bible of JavaScript. It contains everything from Genesis to Apocalipse. It contains all the good parts of JavaScript which matter.

Re: Wat (2012) [video]

#25
post #10

Earlier quoted context omitted.

>It also kind of cemented for me that weird edge cases don't actually matter in practice I had the exact opposite impression. Indeed, this stuff is the cause of so much that gets attributed to something else (e.g. JavaScript framework churn being attributed to culture). The problems caused by these issues compound as you work your way up the stack.

I think I get where you're coming from, that weird low-level behaviour could result in the things you build on top being unstable (I have been able to avoid the employment of the big javascript frameworks/systems, so have not had to suffer a lot of technology churn), or harder to build on top of [see my reply to another comment], but OTOH abstracting away weirdness one of the fundamental functions of engineering? And…

Often times it's because there is no good solution. That is, you can't really fix the problem without being overly strict and making common use cases impossible or awkward to use. So you settle for something that usually works for most people. Bad designs have a tendency of creeping up.

The thing about things designed with bad edge cases is that they can have dire consequences for some people, but as long as it works for most people, they stick around. Forever causing pain.

Re: Wat (2012) [video]

#26

The WAT talk was rhetorically nice because it managed to joke about weird corners of the language without going into ranty programmer mode, but opted for a more gentle style of bemused boggling. It also kind of cemented for me that weird edge cases don't actually matter in practice (in my experience), and that a language can have lots to make fun of while still being lovely to use.

It's a lot like this Order Of Operations quizes that make it around social media, with people who don't quite understand Order of Operations getting the wrong answer.

The obvious answer every engineer understands, as soon as it gets complex to work out the Order Of Operations, you make it explicit by adding parenthesis everywhere. Same thing with JS, once you have a chance for some of this weird behavior to show up, you make sure the types make sense.

Re: Wat (2012) [video]

#27

it shows that at the fringes nobody in the audience correctly predicts what will happen... anyways, here's the abductee-programming-language-conundrum: consider Language X: there is a nuclear power plant, and you or loved ones live within 10 miles. it is your responsibility to select the language for implementing the emergency shutdown procedures. would you use language X?

I posit there is a difference between the safety of millions of people and the functionality of my stupid website.

Re: Wat (2012) [video]

#28

it shows that at the fringes nobody in the audience correctly predicts what will happen... anyways, here's the abductee-programming-language-conundrum: consider Language X: there is a nuclear power plant, and you or loved ones live within 10 miles. it is your responsibility to select the language for implementing the emergency shutdown procedures. would you use language X?

Sounds like a job for Ada

Re: Wat (2012) [video]

#29
post #18

it shows that at the fringes nobody in the audience correctly predicts what will happen... anyways, here's the abductee-programming-language-conundrum: consider Language X: there is a nuclear power plant, and you or loved ones live within 10 miles. it is your responsibility to select the language for implementing the emergency shutdown procedures. would you use language X?

I'd select a redundant mechanical device.

Or chemical. My first thought was: scram rods hanging off a "rope" made from an alloy specifically selected to melt at the right temperature. And/or a similar arrangement involving wax, as I think waxes have longer history of being used as thermal breakers.
Post reply on HN