Selecting languages and frameworks for developing web applications and the Blub paradox

Via a post on the Scala list I read about the ‘Blub paradox‘ (which roughly stands for the fact that most programmers tend to stick with the languages they already know and/ or go for middle-of-the-road) for the first time, years after it was written. There are a couple of fantastic quotes in there, like:

“You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.”,

and:

“But if you work for a startup that doesn’t have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.”.

I particularly like the first quote. Most web application framework comparisons I know of sum up things like the number of job listings, downloads, list activity and ‘famous references’. And while Wicket is doing pretty well with at least a couple of these numbers, I believe they are crappy arguments. The only thing in favor of even considering those numbers is that when you evaluate technologies, you’ll typically want to know you’re buying into something that has the kind of support you need (bug fixing being the most important part of that). For the rest… it is entirely possible that 100,000 people are just plain wrong.

So what should a good framework comparison look like then?

First of all, match technology with goals. Maybe you are already using a certain combination technologies, and you experience problems with them. Define what these problems are, and seek technologies that try to address these things. The main reason I ended up using Wicket was the inability model 2 frameworks to scale the development effort. But your goals might very different, ranging from delivering as quick as you can, to addressing scalability concerns of your site, to being able to outsource part of the development.

Secondly, the comparison should not be confined to just one language. Compare Wicket with GWT with Rife with Lift with RoR with Django with Seaside first. The language a framework depends on is important, but look at the complete picture.

Third, look at the quality of the framework. When you read (the better) language comparisons, often a fair amount of attention is given to how expressive and elegant certain choices are. And whether what you would produce with that language would be maintainable and easy to read. Include such considerations in that framework comparison. What can you say about the framework’s conceptual integrity? What would your code look like, and what do you think about the framework’s code? Considering the quality of frameworks is largely ‘art’, and – except for undeniable excellent libraries like Guice and Joda Time – it probably comes down to what your taste is. But try to form an idea on this regardless.

Fourth, just bother with the promising ones. A common complaint of people is that there is too much choice. It’s a known economical principal that too much choice makes people less happy with whatever they chose. But it is also known that competition drives innovation, which of course in the end will produce frameworks that will make your life as a programmer better. A complicating factor here is that in the real world, companies go out of business when they fail. That’s not true for open source software. Which is both good and bad. It is good because a library can work great for you, even if it never got a lot of attention. Pnuts is an example for this: it doesn’t seem to be particularly popular, yet I’ve used it in a couple of projects and I am very happy with it. On the other hand, some software should just go away. While Google will hide the greatest losers for you, unfortunately, bad ideas can stick around for a long time. Don’t include Struts 1 in your comparison: it sucks. While it was a helpful project a few years ago, by now there are many far better alternatives. Accept the fact that Struts is a victim of creative destruction. Struts is not alone either, but you can decide that for yourself.

Fifth and last (at least for this post), there is no substitute for trying stuff out yourself. It is never a waste of time to learn a new language, and in a similar fashion, I thnk spending a few hours with a framework you might consider isn’t wasted either.

About these ads
Tagged , , , , , , , , , ,

7 thoughts on “Selecting languages and frameworks for developing web applications and the Blub paradox

  1. Fred Daoud says:

    Agree with all of your points.
    Very well written post.

    Cheers,
    Freddy

  2. From my point of view it is the combination of different goals and the ease of development that make me choose a framework/technology. The goals you mentioned in your first point doesn’t have to exclude each other (you didn’t claim they do, I just want to make it clear :-)). It should be the maxim of each technology to combine as many “goals” as possible anyway :).
    You’re right it’s never a waste of time to learn a new language, but as far as I’m concerned I’d rather live with a drawback of a framework in a language I already know than learning a new one from scratch …

  3. @ Michael,

    Yeah, I agree. Try to maximize on the mix that works for you. They don’t have to exclude each other, but neither do they have to have the same weight.

    As for living with the drawbacks of a framework… well, that really depends on how big the drawbacks are (of both the language and framework). It is entirely possible that the new combination pays of within say a month, making it ultimately more efficient to go for that. :-)

  4. While Google will hide the greatest losers for you, unfortunately, bad ideas can stick around for a long time.

    And, sadly, the reverse is true – you can find a great open-source project through Google (or an old link, etc…) and be saddended when you see that what was once a project with a lot of promise has had no progress for the past 2 years :( (this recently happened to me when checking out MC4J).

    Good post!

  5. Nicolas Janin says:

    I’ve also embedded the Pnuts language with success in a project and I agree it’s a very good unassuming piece of software. It deserves much more praise than it currently receives.

  6. Nicolas Janin says:

    I’ve also embedded the Pnuts language with success in a project and I agree it’s a very good unassuming piece of software. It deserves much more praise than it currently receives.

  7. for the scala list
    “I agree with your sentiment. I just want to be very conservative. The
    reason is that I’d hope we’d minimize the mistakes that go into the
    standard library. Once a mistake is in there, to the extent Scala is
    successful, it will be impossible to remove. The Java API is littered
    with bad design and regretful decisions. It adds a lot of noise to
    working in Java. Scala is such a nice language that it would be a
    pity if its standard library was full of noise.”

    I agree with that. I think it would be a good idea to be very clear to
    what is officially part of the Scala family – and things like using
    scalax.* or even hosting downloads on the same web site will give it
    an official flavor – and what are separate initiatives that should be
    evaluated as such. Anything with that official flavor should be great,
    undisputed code.

    Also, I think that JEE is a good example of what Scala should not
    follow. Many things in JEE are disputed, and JEE has been holding back
    innovations more than it fostered.

    -A. Bilstein

Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: