Minimal design aesthetic, ORM-is-Vietnam, worse is better... and XP's don't write it, you won't need it. And of course, Keep It Simple, Stupid.
"Take the best of everything" is a great philosophy. There's almost nothing that doesn't fit within that. I'm okay with Inline::COBOL, if it exists (I'm afraid to look). Likewise, if the best of Java, C++, etc is adapted, awesome. But I want this to happen concurrently with the old minimal design aesthetic, not in place of it.
Never try to solve 100% of a problem. It's impossible, and you'll only wind up writing code and making structural changes that prove to work against you in the long run. Every program is built on assumptions. Always build on good assumptions. If you're trying to predict the future and then using that prediction as assumptions, you're working against what your users really need. There is always a future. It has never happened and it never will happen that someone, no matter how brilliant and insightful, will write a program that will obsolete all other programs of that type.
The "minimal design aesthetic" is something Ruby is often praised for. It has some small but powerful modules whose power stems from their simplicity -- Scrapi and Camping come to mind. If you consider the cost of the mental energies of the person reading the documentation, learning how to use the thing, the advantage of small-but-powerful becomes clear.
Java is the opposite here -- the APIs are designed to be comprehensive and general, attempting to anticipate every possible use, and the reference volumes are voluminous. They remind me of the old AS/400 documentation sets, where your vendor would sell you not only 200 matching bound volumes, but an IBM branded bookshelf to put them on, exactly the right size to hold all of them and in the same machine grey as the machine itself (but much larger than the machine).
Looking at that bookshelf, you might get the impression that the AS/400 is a very powerful computer indeed, but the vast majority of the stuff in there is over-designed, under used historic cruft written in anticipation of scenarios that seldom if ever came up. Scenarios that seem laughable after the passage of just a little bit of time.
Any system, given enough time, seems to outgrow its breeches.
Larry Wall has commented that Perl "hasn't turned into APL... yet". I often write with praise of the perl 5 porters and how they effectively push complexity down into user-space and most of the time do so while still enabling magic modules to do their magic. XS was probably the earliest example of perl 5 kicking complexity out of core while still enabling it on a grand scale. Perl used to be well known for this sort of minimalism -- one liners were just one part of it. In general, modules were designed with simple APIs.
ORM-is-Vietnam comes from an essay someone wrote about object-relational-mappers, and how it seems easy at first, but the goal slowly proves elusive as resources are soaked up. It may be possible to seamlessly map objects to the database without losing relational modeling and without insane amounts of configuration, but the evidence is to the contrary. Ignoring history here results in huge piles of code that still don't work right. People keep trying to win; the best successes aren't the ones that try to completely conquer the problem, but instead do things of limited scope that are useful on their own.
Worse is better comes from an article where someone working on Unix was having lunch with (I believe) someone from the Multics team. The Multics guy asked the Unix guy how they dealt with interrupted system calls. The Unix guy said, oh, that's easy... we just return null and they try again. The Multics guy was horrified. Multics had a fix for this problem. But the "worse" design won out in the long run. As it happens, interrupted system calls in Unix give programmers more flexibility. It's generally not a problem to write a loop that keeps calling read until there's a real error, and in practice, people use an abstraction over top of kernel level IO anyway -- specifically, libc. Fixing this in the kernel in Unix was not necessary because it could be fixed in a library. Complexity was essentially pushed down. Now tables are turned a bit because Unix is much larger than Multics and some of the earlier do-it-right work in Multics is making Unix look like a clunky, insecure mess. The difference is knowing which bits of complexity can be pushed down the stack, out of the kernel or out of core, and which can't.
CGI.pm got second system syndrome compared to &readparse. That begot CGI::Lite and CGI::Minimal and company. And that seems to be the way. People are fixated with the features for a while... but then the novelty passes, reality sets in. The mental cost of relating to the all of the features is often too much.
Like I wrote before, Perl takes a lot of beating for not being clean, serious, enterprise, etc enough. But we're never going to convert the Java programmers en masse. People like what they like, and if they don't like you or your thing, nothing you do is going to impress them.
I concur with you, which is the entire reason I wrote ORLite.
It's small ORM that doesn't try to do more than the basics, and allows plenty of ways around the automation.
Score
Worse is better comes from an article where someone working on Unix was having lunch with (I believe) someone from the Multics team.
I read recently a "definition" of plan9 (sorry, can't find a link) as being something like "everything in Unix only done worse". I wonder if that was referring to the worse is better idea.
