A Cornucopia of Frameworks

Software developers these days are faced with a bewildering array of choices. Although I refer to frameworks in the subject line, by that meaning primarily Web frameworks, we also have a stupendous amount to choose from when it comes to programming languages and libraries. The number of application programming interfaces (API's) for many languages is now so large that one can only scratch the surface.

Matt Raible posted a very good comment by David Sachdev about the proliferation of Web frameworks. And not infrequently I have found myself also agreeing with Angsuman Chakraborty, who writes about abandoning frameworks and going back to Java, JSP and servlets (and plain old JDBC). Having started out with J2EE when this was all that was available, on the Web side, I'd recommend this experiment for any developer who has never gotten down to the bare metal. Best practices, of course... The same applies for frameworks on other platforms. The fact of the matter is that these frameworks are often overkill.

The Python Wiki has something to say about API proliferation, as do innumerable other sources referring to other languages:

A persuasive argument once upon a time was the simplicity of the Python standard library's layout in comparison to the "aggressively hierarchical" layout of the standard Java APIs, for example. But with a large number of overlapping modules and packages within the Python standard library reducing its relative coherency to Java's API proliferation (see java.sun.com for details), it seems appropriate to perform a reorganisation of the library's layout in order to promote a more memorable and intuitive structure that can be more coherently documented.

Java has come under criticism for excessive API bloat, as has .NET. This November 2006 article on Java Web technologies even says "There are too many Java technologies to list in one article." When one considers that a Java enterprise programmer will have to be fluent in Java, conversant with a large subset of J2EE APIs, familiar with any other Java APIs relevant to the problem domain, and very likely will use a framework besides, there is a very real obstacle to rapid delivery of reliable and scalable applications. Note that no small number of enterprise apps actually have fairly simple requirements, and really don't need a massive API stack to solve the problem. .NET has essentially the same problems. [1]

Couple this with the influence of advanced IDEs - regardless of the very real benefits that such environments offer, the argument can be made that they dumb programmers down. Charles Petzold in 2005 delivered a presentation to the NYC .NET Developers' Group, which discusses the effect of Visual Studio on programming habits...this is applicable to other comparable IDEs as well (say, Eclipse and NetBeans or IntelliJ). To quote from Petzold's article:

It’s not that IntelliSense is teaching us to program like a machine; it’s just that IntelliSense would be much happier if we did.

And I think it’s making us dumber. Instead of finding out exactly the method I need, or instead of trying to remember an elusive property name, I find myself scrolling through the possibilities that IntelliSense provides, looking for a familiar name, or at least something that seems like it might do the job.

I don’t need to remember anything any more. IntelliSense will remember it for me. Besides, I justify to myself, I may not want those 60,000 methods and properties cluttering up my mind. My overall mental health will undoubtedly be better without them, but at the same time I’m prevented from ever achieving a fluid coding style because the coding is not coming entirely from my head. My coding has become a constant dialog with IntelliSense.

So I don’t think IntelliSense is helping us become better programmers. The real objective is for us to become faster programmers, which also means that it’s cheapening our labor.

Anyone who has used Java IDEs can identify with these comments. Despite the undeniable usefulness of these programming environments, one wonders if any novice developer should ever be exposed to them. The combination of a good programmer's text editor and API documentation, and running SDK tools from the command line, should be required first exposure to a new language (and libraries) for anyone...you have to think about what you are doing when you have to hunt for the class and/or method in an API document, and then type out the code.

There used to be a guideline that a good programmer only turned out a few dozen lines of tested, efficient code per day. Modern IDEs and frameworks have now made it possible for developers to churn out hundreds of lines of code during a shift, but there's no guarantee that it's good code...although your IDE will tell you if it will compile.

What we need is a movement back towards the basics. In other words, a much more careful use of "labour-saving" technologies, less reliance on frameworks, and strict guidelines accompanying the use of IDEs.

1. See Microsoft worried about .NET fragmentation