Reading chromatic's journal entry on why he prefers Perl, I find I agree entirely.
Perl's ability to change direction and solve things in the most appropriate paradigm from module to module (or even line to line) is hugely useful to me as someone that solves problems.
Ruby programmers also display a similar joy for being able to adapt the language in different ways.
But for me this leads to a line of thought on WHY these differing attitudes exist, and I think we need to environment in which people are using languages.
One of the joys of OSDC is that that, for a multi-language conference, there's extremely little clique'y'ness (unlike, say, OSCON).
I spend as much or more time at OSDC hanging out with interesting Python people or Java people as I do with interesting Perl people.
One thing I notice with Python developers (to paint a very broad brush) is that they focus more on what they are solving rather than the language itself.
Python is cool, but it's a cool way to Do Something Else.
This isn't universal of course, but I suspect that the style of Python naturally attracts this type of personality or problem solver, hence a stronger population.
I've noticed in particular quite a strong showing from the physical sciences in Python communities (physics, astronomy, environmental sciences, etc). I see very few such people in Perl by comparison.
This is much in the same vein as PHP's extreme form of Elaine's Law makes it attract (as Rasmus put it at Linux.Conf.Au when I had a chance to talk to him) People That Aren't Programmers.
So, lets create a Hypothesis for these observations.
Syntactically expressive languages attract people that care about the language, syntactically simple languages attract people that care about the solutions.
And since languages are just APIs to processing engines we can generalise the hypothesis.
Expressive interfaces attract people that care about that layer, simple interfaces attract people that care about higher layers.
Refactored into generalized terms, we can see all sorts of additional observational evidence.
Take the highly controvertial Tiny modules that tackle problems with strict definitions. In particular, XML::Tiny and YAML::Tiny.
These intentionally and blatantly display an extreme sacrifice of expressiveness and functionality for simplicity.
If the hypothesis is correct, they going to be naturally devisive by their very nature.
If you care about XML or YAML, you are almost certainly going to hate them. Likewise, if you don't really care about XML or YAML, you will probably like the.
If you look at the XML::Tiny reviews, you'll see comments polarised into either the "1 star - This is silly. The module ignores important aspects of XML" camp, or the "5 stars - I'm no wizard when it comes to XML, and I just needed to deal with some simplistic data" camp.
If we take the (I hope) reasonable assumption "For any interface, there exists more people that don't care about that layer than do care about that layer" and combine it with the hypothesis, we can derive Elaine's Law.
Simply by virtue of there being more people that don't care, and these people being attracted to the simplest solution instead of the highest quality solution, we end up with a situation whereby (in raw market share terms) a simple low-quality solution should be more successful than an expressive high-quality solution.
(I continue to use "expressive" rather than "complex" because it implies the complexity is not needless complexity and is a necesity to make use of the high-quality solution).
This doesn't make the simple solution BETTER necesarily, just more popular with people that don't care. The only situation this might equate is in business, where popularity and profits DOES equal better.
Perhaps we could simplify things even further to just:
Most People Don't Care
So, finally, to predictions!
IF this is all correct, can we use these ideas to predict anything interesting?
Well, in the most general case, we can certainly come up with a good guideline for API design.
If your users don't care about your problem, a simple interface will recieve the best reviews.
If your users DO care about your problem, an expressive interface will receive the best reviews.
And if you can hit the sweet spot, an expressive interface that is simple to install, where extensive sensible defaults allow the interface to also be used in a simple way, without introducing too much bloat, you will appeal to BOTH people that care and people that don't, and ultimately dominate that problem space.
I look to examples like DBI and DateTime here, that let you work in both simple and expressive ways.
I'll be addressing this topic a bit more over the coming weeks.
And if you can hit the sweet spot, an expressive interface that is simple to install, where extensive sensible defaults allow the interface to also be used in a simple way, without introducing too much bloat,...
A fine definition of "Good Design" if I've ever heard one. Any formula involving $n always reduces when $n=1. It's usually not a good idea to hardcode the assumption "1" into your program/design/API/language though.
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
