>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 why would, say, undesirable array semantics result in framework churn on top? Because people are trying to 'fix'/'mitigate' the behaviour but can't settle on a single solution?

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.

If you don’t keep in mind all the quirks you create bugs and waste manhours. If you keep in mind all the quirks you reduce your cognitive capacity and waste manhours. Languages with quirks are categorically worse than languages without quirks.

Large areas of ridiculous behaviour are, if easily characterised, maybe easier to avoid than more finely-graned edge-case zones that you'd get in more elegantly top-down designed languages, and result in less mental overhead. "just stay clear of doing anything remotely weird with arrays" might result in better, more readable code than a langauge with more easily-understandable array behaviour, and have lower mental overhead than what you might get in a better designed language where it might feel more feasible to keep in mind the edge-cases.

I've made a scripting language for videos games that some people use, and kept the semantics super informal, growing it quite organically, and it's worked out pretty well. Every time I try to nail down the edge cases I think "ah no, I'd prefer to have this all be undefined/erratic that to have people rule-lawyering their way into technically-correct but inelegant code". The main loss I've had from this is the inability to write a fuzzer, and in annoying some people (who use it or, for instance, wanted to write compatible compilers/interpreting). I do rely a lot on test suites for it (which also helps other when they want to do reimplementations), which provides a good amount of stability in spite of the fact that I never tell anyone what exactly counts as a valid variable name and amn't exactly sure what that is off the top of my head.

That said, nicely-specified programming languages that one can accurately comprehend + model with a human brain are super nice, allow for great tooling + better portability, and eliminate a large class of bugs that can be very troublesome. I'm a big fan of Go/C#, but they're not everything, and not from my point of view at all categorically better than other options.

> 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.

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.

I think that doesn't reduce complexity it just pushes it to the users and the software they create. So now you potentially have orders of magnitude more complexity than if you had dealt with it in the appropriate place.

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.

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.