Lawrence Kesteloot writes:
A more useful distinction, when considering new Java features, is a
"production language" (used for large programs maintained over a period
of years) and a "toy language" (used for quick scripts, experiments,
tools, personal stuff). A production language should favor reading the
code over writing it, and a toy language should do the opposite.
Now, the idea that certain languages are better suited to long-lived purposes while others are better for quick development is fine, and in fact, a good thing, even if his choice of names are poor. (I think the terms "application" and "utility" would be more accurate.) Looking at his choices of "production" languages, however, I can't help but think this exercise is more about rationalizing Mr. Kesteloot's own personal biases than a serious attempt at defining another dimension of language taxonomy:
Examples of production languages are C, C++, C#, and Java. Most other languages are toy languages.
Supposedly readability is the overriding attribute of a "production" language, yet this grouping somehow includes C. Don't get me wrong, C is absolutely the best choice for a number of highly complicated programming domains, but it's anything but easily grokable. What he really seems to be arguing (without saying as much) is the only languages suitable for long-term codebases are statically-typed, imperative, and inexpressive. Dynamic languages (regardless of paradigm) and functional languages (regardless of type system) are only suitable for throw-away purposes.
This is beyond ridiculous. There are perfectly good reasons for choosing Java over say, Python, for a given project (tool support, ability to reuse existing code, ease of finding programmers, whatever), but readability isn't one of them. Readability is much more a function of the programmers that wrote the code than the language they used, and there are plenty of ways to write spaghetti code in the dumbest of languages.
Speaking of readability, check out his defense of why Java is supposedly a very readable language:
It's verbose, but that verbosity is part of what makes it readable
What? Contrary to what the Ruby people say, brevity isn't a virtue in and of itself, either, but verbosity is never a good thing. Never. Code should be long enough to be comprehensible by someone reasonably knowledgeable in the language, and not one character longer.
