The Paradox of choice...
The Paradox of choice states, briefly, that too many options are detrimental for one's motivation and satisfaction. Various experiments prove surprising facts:
The three studies described in this report demonstrate for the first time the possibility, that while having more choices might appear desirable, it may sometimes have detrimental consequences for human motivation. Studies 1, 2, and 3 provide compelling empirical evidence that the provision of extensive choices, while initially appealing to choice-makers, may nonetheless undermine choosersâ subsequent satisfaction and motivation. Study 1 showed that while more consumers were attracted to a tasting booth when the display included 24 flavors of jam rather than 6, consumers were subsequently much more likely to purchase jam if they had encountered the display involving only 6 jams. Study 2 revealed that students in an introductory college level course were much more likely to write an essay for extra credit when they were provided a list of only 6, rather than 30, potential essay topics. Moreover, even after having chosen to write an essay, students wrote higher quality essays if their essay topic had been picked from a smaller than from a larger choice set. Finally, Study 3 demonstrated that people reported enjoying the process of choosing a chocolate more from a display of 30 than from a display of 6. However, despite their greater initial reported enjoyment in the extensive-display condition, participants proved more dissatisfied and regretful of the choices they made and were subsequently considerably less likely to opt for chocolates rather than money as compensation for their participation.
-- When Choice is Demotivating: Can One Desire Too Much of a Good Thing?,
Sheena S. Iyengar, Columbia University and Mark R. Lepper, Stanford university
In his book The Paradox of Choice: Why More Is Less, social theory professor Barry Schwartz mentions another study, done on 1,000,000 employees in 2,000 different workplaces on choosing mutual funds for their retirement plan. For every 10 extra mutual funds that employees were offered, 2% more did not choose anything. These employees lost in the process up to $5,000, the matching money from their employer. In effect, because of excessive choice, these people gave away free money.
Prof. Schwartz has a highly insightful and entertaining 19-minute TED talk on the Paradox of choice.
...and how it applies to web development
Different programming languages and web application frameworks have different philosophies:
- Perl - There's more than one way to do it (TIMTOWTDI)
- Python - There should be one-- and preferably only one --obvious way to do it. (The Zen of Python)
- Ruby on Rails - "Convention over Configuration": a developer only needs to specify unconventional aspects of the application. CoC is a software design paradigm which seeks to decrease the number of decisions that developers need to make.
Perl seems to go against the grain here. Naturally, Perl fans will quickly praise TIMTOWTDI... but some won't:
I don't like ThereIsMoreThanOneWayToDoIt. In fact, I hate it from the bottom of my heart, and it's my belief that it's the root of all evil. There should only be one way to do it. One obvious way, anyway. I find that having to choose between similar methods just for the sake of choosing is pointless and just takes lots of energy. You should be allowed to do it differently if you really need to, but those cases are exceptions.
-- Daniel Brockman at http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt
Note that the last phrase, "You should be allowed to do it differently if you really need to, but those cases are exceptions", is just Ruby on Rails' philosophy. Other times, TIMTOWTDI becomes a nightmare:
TAFTMWTDI There are far too many ways to do it!
Example 1: templating modules
What TIMTOWTDI did for Perl
While Perl fans (myself included) will rapidly (and based on facts, to be honest) prove how Perl is superior to PHP, or how Catalyst is superior to Ruby on Rails, let's see how choice and capability translate into quantity of web applications. Quality is harder to determine: user experience and visual design get in the way, and server-side code is rarely available. Also, there are great and crappy sites written in any language. Let's focus on their numbers then, using a very neat service, AppliedStacks.com:
- Python - 1,938 sites
- Ruby - 2,334 sites
- Perl - 708 sites
Paradoxically, Perl has the advantage of being the oldest programming language of the three: Perl (1987), Python (1991), Ruby (1995). The web frameworks all appeared around 2004-2005. What then explains Catalyst's orders of magnitude lagging behind?
Does Perl have worse gotchas than Ruby? No. Is Perl more difficult to learn? No, Perl's learning curve is "shallow (easy to learn)". Does it have good modules? You bet. Everyone is proud of the tens of thousands of modules on CPAN... which is maybe where the problem lies exactly. We've seen it above with templating modules, but it goes on in the MVC. First off, what framework do you choose? Besides Catalyst, there exist 18 (eighteen) other Perl-based web development frameworks: Jifty, CGI::Application, WebGUI, Gantry, Egg, Maypole, Solstice, ClearPress, CGI::Prototype, Konstrukt, Tripletail, MasonX::MiniMVC, Rest::Application, Squatting, Mojolicious, Apache::PageKit, OpenInteract, Mason. And then, you have to pick some more...
- or not a RDBMS even, but an ODBMS like KiokuDB, CouchDB, or Pixie
- all of them
Compare this with Ruby on Rails, which basically mandates ActiveRecord and Prototype/Script.aculo.us. Again, technically, Prototype is generally considered technically inferior to Dojo, ExtJS, jQuery or YUI. Similarly, Django eliminates much choice by including an ORM and a templating system.
Still, Rails with Prototype/Script.aculo.us and Django have led to the creation of an order of magnitude more sites than Catalyst. What was different was not the intrinsic power of a programming language, or the size of the community (Perl started way before the others).
My claim is that Django and Rails won because they eliminated excessive choice.
...and an update from Matt S Trout, Catalyst core team member
Below is an IRC conversation with Matt S Trout on this topic:
we aren't [competing with rails], never have done, and don't want to do anyway
I had working code within 24h of discovering catalyst on google
catalyst is a meta-framework
the model and view agnosticism allows us to adapt to system shock conditions
and embrace parts of the community who disagree
vox is Catalyst and TT, but with Data::ObjectDriver on the backend
dave rolsky uses Catalyst and Mason with Fey on the backend
of course, you can trivially avoid the paradox of choice by going with what the tutorial tells you to
except we don't have a one true answer to forms yet
but that's because there've been successively better "sort of true" answers
but allowing choice as a core value is what gained catalyst critical mass, and what ensures it's extensible to meet the needs of any given project
which is why catalyst gets heavy usage on in-house code as much as in public facing apps
and we don't force people to advertise their catalyst usage
so stats gleaned off the various scraper sites are basically completely useless for gauging adoption
and herein lies our strength
natural selection favours those who can evolve quickly and cheaply
we can. rails is now tearing itself to pieces in order to get the ability to pick and choose we've had all along
What do you make of Rails and Merb merging?
it's going to be infinitely painful and we'll still have a more flexible codebase
but it's nice to see -them- trying to compete with -us-
[the X-Catalyst header] is [debug mode only and] of course completely not there on any live site
and appliedstacks.com is ... basically a user submission
so what you're saying is, more catalyst users have heard of some random wank 2.0 site
which is why the stats are bollocks
last time we looked at this the catalyst community is ~50% the size of the django community
[that appliedstacks.com popularity metric] measures people who've heard of appliedstacks.com
[and the] likelihood of people putting themselves on a powered by list
nah the stats aren't bollocks, but the confidence interevals are somewhat unknown
I know that many cat apps are behind firewalls. Can the same not be said about Django or Rails?
not to nearly the same extent
the original django sites' back office data is managed by DBIC
maypole didn't give you a choice. the death of CDBI killed it outright.
jifty doesn't give you a choice. jesse vincent told me to put catalyst in the enlightened perl extended core because we whould have a one true answer
the templating system and ORM arguments don't exist for catalyst newbies and haven't for years
and django's gone through several form systems in that time
and rails doesn't actually have one
and has lots of arguments about templating systems
so no, the paradox of choice isn't the primary problem
it's there. but the biggest problem is that we are the perl community and we fucking suck at marketing
what happens instead is somebody bitches
and everybody bikesheds for a week whining about stuff
and not actually doing anything
and really, did the catalyst tutorial ask you to choose a templating system? or an ORM?
Showing changes from previous revision.