TMTOWTDI is anarchy. It scares people who want to keep order by force.
Allowing people the freedom to choose from many different ways of doing things is a recipe for disaster, we’re told.
… in my experience, it’s been the Perl code I’ve had that is readable, well-designed, and maintainable. It’s been the Java code I’ve seen that is ugly, poorly-designed, and unmaintainable. There are certainly exceptions to both sides of this.
Yet it’s not about Java versus Perl (and certainly not Perl versus Python).
One of my favorite Larry Wall quotes goes something like “Any language that doesn’t occasionally surprise the novice will pay for it by continually surprising the expert.” I’m not sure that it’s possible to write a language in which it’s impossible to solve useful problems with code that’s immediately at least somewhat transparent to someone who doesn’t know the language or the problem domain. (I’ve also never received a serious and concrete answer when I’ve asked someone for a qualitative enumeration of the design features that make one particular language so much more maintainable than another. Enforced brace placement–or brace invisibility–does not count.)
I suppose that if you’re designing a language for the specific problem of “Most working programs should be readable by programming novices” then you can avoid the problem of not knowing what people will use your language to do. Hands up everyone who’s seen a practical, non-didactic Scheme built entirely out of the six or seven core primitives, though.
Don’t get me wrong; there’s room for a strict hand. There’s room for didacticism and narrow garden paths for novices as they learn — but language designers need the freedom to surprise the novices so as to give them more freedom as they need to solve larger, more real, messier problems. As Reg Braithwaite said, A programming language cannot be better without being unintuitive (and see The word “intuitive” isn’t).
We already shape the language of our software to meet our problems when we choose meaningful identifiers. Why not shape the idioms of our programming language to do the same? Maybe it’s time to admit that a distributed team of Perl fans writing a compiler for the world’s most dynamic language has different needs than a close-knit group of four people who’ve worked together for ten years in the bowels of an insurance company schlepping data onto and off of mainframes have very different needs, even if they use the same language and that, even if they use the same language, you can’t just swap two of them without a major productivity hit, even if there’s only one obvious way to do anything in that language.
Maybe we could have that discussion if programmers could discuss how language syntax affects language features and get beyond “I like enforced whitespace” / “I like sigils”. Maybe next year.