I think that people in academic PL often speak (derisively) of mainstream languages as being "designed by amateurs". It could be useful to dial down the tone, and be more specific about what we mean when we say things like that.
One example was TypeScript's designers' total confusion concerning the variance of function spaces. But I've said enough about this one, and maybe it is not easy to create a sound type system that makes sense of unsound practices without changing those practices.
Another example that I've seen more recently is the way that the Swift typechecker blows up when you nest things too much, and asks you to replace it with some let bindings to avoid choking.
I am not sure exactly what is causing this kind of blow-up, but Swift includes a lot of implicit inference of things about which, if asked, an expert would have said: "Of all things, do not try to infer that; it might look cool in code examples, but this will definitely blow up in practice." Even if it doesn't blow up, it will lead to extremely inconsistent programmer-expectations.
There's a lot of things like that in Swift, and one thing to remember is that it is easier to add than to remove. Once you commit to supporting some PL feature that is basically algorithmically infeasible, it is not easy to remove it. If you try to remove it, users will revolt by saying "But it already works!" ignoring how it only works sometimes. Some kind of expert judgement was needed here, adults in the room.
Jon Sterling
@jonmsterling@mathstodon.xyz
