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.
Wat (2012) [video]
21–29 of 29 posts
Re: Wat (2012) [video]
#22The 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.
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]
#23The 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,…
- 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]
#24WAT 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=…
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]
#25Earlier 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…
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]
#26The 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.
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]
#27it 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?
Re: Wat (2012) [video]
#28it 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?
Re: Wat (2012) [video]
#29it 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.