Code is read more than it's written, so clarity is important. The fewer ways there are to do things, the closer everyone is to a common understanding of a given

Code is read more than it's written, so clarity is important. The fewer ways there are to do things, the closer everyone is to a common understanding of a given block of code, which makes understanding another programmer's intent easier. In turn, this makes onboarding to a project much more effective, and lets devs reach a minimum level of competency more quickly. Note that small doesn't imply lacking features. For example, something like a std::transform is often "smaller" than iterating through an array with a for-loop, but it's also clearer and less error prone. It's a result of the language itself providing more powerful data structures, and interfaces that make manipulation of those structures easier, which is what I'd argue "small" is actually shorthand for. I don't want to be using a language that only has if-statements and goto, which would be "small" in one sense of the word; I want to use a language that has the minimum necessary number of keywords, decorators, or meta-languages, and instead provides clear, ergonomic ways to express my intent to the machine.