| > "let's create new and weird syntaxes for TMTOWTDI" Nothing in Perl 6 is there just for the sake of having it. Usually the options give you trade-offs between generality and concision/clarity. Like `[+]` vs. `sum`; sum is clearer (to someone who speaks English, at least), but it's only that: sum. You can stick any old operator in `[]`, and that happens to include `+`. Also, "weird" is entirely subjective. > There are 40-year old COBOL codebases that are still doing their job... Absolutely agree here. There's no need to update well-written code just to keep with the fads. However, when the code is less-than-well-written, or the newer alternatives really do offer something better, you have a different story... > So, don't rely on stdlib in these cases So we're introducing a new dependency for a common task, adding extra work to maintenance and setup, because our language's standard library isn't worth a crap. And what about the people who either don't want to bring in that dependency or are blissfully unaware that their stdlib's sort is suboptimal? There's no excuse for having an objectively inferior default. Third-party libraries should only have to implement use-case-specific algorithms. > Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc. As for onboarding, I think that has more to do with the "boring" languages being popular (so it's easy to find experts) than with those languages being inherently more readable. I don't know if you've ever tried to get yourself "on board" with a Java codebase of any significant complexity, but I can tell you from experience that it's hell. I'm aware Java is an easy target, but it's what I imagine you mean when you say "boring." Sure, it only takes a competent programmer about a week to learn fully, but that doesn't make real-world Java code easy to read. Simplicity and readability aren't the same thing, and in fact too much of the former hinders the latter. The human brain has a limited amount of short-term memory and some pretty awesome long-term memory, but committing to it takes time. When you go about understanding a Java codebase, you're trying to commit an awful lot to short-term memory, including all the boilerplate and plumbing needed to build a workable platform up from the feature-bare language itself. And you repeat this for every new codebase. And people will make different architecture choices, even if the body of the code ends up looking similar. However, what if the creator didn't need to write all that boilerplate? What if the language provided all the common tools? Now, a maintainer can take their time once committing the language's standard set of tools to long-term memory and recall that knowledge for every codebase they encounter. When there's less for creators to re-invent, there's less for maintainers to commit to short-term memory when they're trying to get in quickly to make a change. Thus, I think your point about trying to dissect two codebases which serve the same purpose is moot for Perl 6--it's either provided by the language or it's something unique enough that you'll only ever need to read one implementation. Not to mention holding a load of Big Java Nouns© in short-term memory is exhausting. Ditto on C#, though it's admittedly a bit better. Same for C++ with its type parameterization insanity, or C and its macro insanity... the common thread here is Larry Wall's old Waterbed Complexity Theory being proven correct. Give people a limited set of tools with one knife and they'll always reach for the knife, eventually hurting themselves or someone else. Perl 6 provides ways to very naturally express concepts, which in fact makes reading it easier. Plus, the excellent docs and helpful communities on IRC & StackOverflow make it very easy to learn as you go. I'm not going to sit here lying to you though--it does take time to get in the right mindset and fully grasp the language. |