> Patterns are signs of weakness in programming languages.
> When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary.
I'm not sure I agree with this thesis. The idea that you should make common patterns part of the base language is how you end up with bloated languages with a huge number of constructs that make code hard to read. There is a virtue in keeping things simple, even if it means more boilerplate in the code. Obviously this requires balance, you can go too far in either direction, but languages that try to include the kitchen sink do seem to have more trouble gaining popularity.
> The idea that you should make common patterns part of the base language is how you end up with bloated languages with a huge number of constructs that make code hard to read.
The semantics of the pattern/idiom will be there anyway, whether there's a language-implemented feature or a "userland" repeated code-pattern.
And the latter are often more sprawling, which has its own readability issues.
This is http://paulgraham.com/vanlfsp.html in a nutshell. Every language has to decide how much it expects people to learn, because that’s how it empowers experts. Knowing an easy language is like carrying an empty toolbox.
If a language is missing Bloom filters or epoll_wait(2), anyone can offer that in a fairly self-contained library. But if a language is missing something like lambdas, pattern matching, exception handling, move semantics, or coroutines, that’s a lot harder to add in a usable and efficient way without actually extending the grammar and the code generator. Those are the things that make a language harder to learn at first but then replace a lot of boilerplate that should (usually) be beneath our notice.
Talking about vintage code.. I heard that Sutherland graphical programs (first or near first in history) was done in a full streaming fashion due to the fact that they didn't have memory or near none. I'm sure there was laziness baked everywhere in their assembly long before anybody even cared about naming this way. If anybody knows better, I'd love to hear about more.
> When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary.
I'm not sure I agree with this thesis. The idea that you should make common patterns part of the base language is how you end up with bloated languages with a huge number of constructs that make code hard to read. There is a virtue in keeping things simple, even if it means more boilerplate in the code. Obviously this requires balance, you can go too far in either direction, but languages that try to include the kitchen sink do seem to have more trouble gaining popularity.