[keymone]

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.

[jan_Inkepa]

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.