On a related note, I saw this on reddit this morning: <a href="http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html" rel="nofollow">http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...</a><p>What's sad is that I have no idea if this is a joke or not.
Here's the dirty little secret that no one wants to talk about...<p>The purpose of "assisters" like frameworks and higher level languages is NOT to make good progammers more efficient.<p>It's to make mediocre programmers more likely to produce <i>something</i> of value and to make poor programmers capable of producing anything at all.<p>And if the bell curve tells us anything at all, it's that these "tools" target 90% of all programmers.<p>But think about it, my fellow top 10% (lol), do you really need all this stuff? If you're working alone or on a small team with a clear objective, haven't you always had everything you needed with low level tools? If you need any higher level tools or reuseable components, haven't you already been building these all along?<p>Sure it's fun to play with new things and learn from others, but when it comes time to really produce, don't we all know how to (and need to) roll with what we know?<p>The need for frameworks and high level languages only becomes apparent when we grow so large that we <i>can't</i> find enough senior hackers. Only when you dip down into the mediocre masses do you need this help.
Frameworks can sometimes be annoying. It's like learning a new sub-language on top of the programming language as there is a certain amount of familiarity you need with a framework's calls (ex. to program in Python, it goes a lot faster if you know that it's len(list) not list.length() and similarly if you're using Rails it's important to know that there is no validates_is_number, but there is validates_numericality_of). So, you start learning all these things that may or may not apply to your project - the language of the framework. And in some places it slows you down and you feel like there's abstraction just for the sake of abstraction, but in the end I think it's worth it.<p>I also think Joel misses something: most programmers are bad programmers. They'll dig you into holes, write lots of spaghetti string code, etc. At least when they're using a framework there's some constraint on their madness. Frameworks (generally) make it a tad difficult to work outside of their constraints and so the default becomes to work in that standard way. So, you don't get people doing weird things as often - like building a string that is the page that they'll echo out like the piece of PHP I'm working on today does (guess they didn't realize that you could simply go out of PHP mode to do that).
An oldie (2005) but goodie.<p>Although it is less about frameworks and more about a disease which was largely contained to Java enterprise-y architecture stuff. (I say as a practitioner in that field... remind me why we are using the Factory pattern here, again?)
A friend convinced me to try AppFuse once. I have a burning, probably un-justified hatred of Eclipse, so I tried the AppFuse + NetBeans tutorial.<p>That may be the most unproductive I have felt in my entire life. I made a damn login form and it took like 12 pages of tutorial, tons of setup, generating a whole bunch of files that seemed like they could have been done algorithmically because they are always the same, editing like nine different XML files with little bits of glue, and eventually like one or maybe two lines of code.<p>Then, I got to wait for the WAR to compile each time I wanted to test a change, because the tutorial didn't seem to know about a developer mode which probably exists.<p>I hate to sound all ranty and partisan, but I could find no way in which that process could be efficient and couldn't imagine anyone doing it voluntarily unless they were ordered or just had no exposure to the rest of the world.<p>Also, I sort of object to having code stuffed in an eight-folder deep hierarchy where the preceding seven folders contain nothing at all. That's a lot of wasted navigation and clicking time and distraction.
Over-complexity is common in the Java space. I was aghast at using JMS. You make a Context so that you can tell it to make a ConnectionFactory, so that you can then ask that thing for a Connection, <i>then you finally get to login</i>. You can then instantiate Producers and Consumers and finally get messages.<p>Why do I need to have 5 different objects when one would do? Having 5 different objects did absolutely nothing for the client code except make it more complex. (And this actually complicates good coding for the user experience. When we notify the user of network problems, I have to add additional code to see if objects exist in the first place just to prevent exceptions.)<p>It would've made no difference if there was just one Object. (Except for shorter code.) I could use it to login to a server. I could use it to register interest in a topic then ask for messages on that topic. If I want to connect to a different server, then I could instantiate a second object. Why do I need 5 freaking instances to do the most basic thing possible?
Frameworks - used properly - can be INCREDIBLY helpful.<p>Why develop my own routing code when there's already a robust, well-tested version available? Or validation code? Or payment authorization code?<p>Though it needs to be said that the number one thing a good framework does is GET OUT OF YOUR WAY. I've seen some Java frameworks that take an hour to put together a simple Hello World and that's just nonsense.<p>Currently I'm using Kohana, which is nice because it's really very simple and easy to extend. So far I've been able to spend so much more of my time actually writing business logic instead of routing logic and the like.
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape, etc...<p>Oh, and if you need them to be different from the default, you can modify them as you want, but we think the default works for most people.
I stopped reading after "In the process, I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks."
The more people talk about J2EE, the more I think it was invented to give programmers busywork and multiply their workload with no increase in productivity.
This is about as ridiculous as trying out one bad programming language and then writing an article titled "Why I Hate Programming Languages". Clearly the author has a problem with one particularly bad set of frameworks he's dealing with now, and one set of framework-making mentalities. Yes, there are bad frameworks. There are good frameworks too. I don't imagine anyone draws their own buttons on the screen anymore. To continue the discussion in any general format is useless, since there are countless examples of bad frameworks and countless counter-examples of good frameworks. A more compelling discussion would be one on what makes certain frameworks useful rather than trying to place a final value judgement on the idea entirely.
I feel the analogue here is a bit off.<p>I'd say a framework is more like a factory that produces a variety of fixed-size spice racks (among with other products). You have to learn what button to press to get the right ones, and the spice racks produced will never be exactly how you want them to be.<p>If you want to quickly generate lots of generic spice rack, then a spice rack factory is all you need. But if you want something really outstanding and unique, then a factory may be anti-productive, and you are better off building it with your own hands.
I've seen good frameworks (OWL, Nitrogen + Powerplant, maybe 1 or 2 more), and I've seen a crap-ton of bad frameworks (any web framework on java, minus <i>maybe</i> WebObjects).<p>They're necessary, but they're hard to do right. The man who did Powerplant said he went through about a dozen different designs before getting one he liked. That's why it was often so useful. Most times, people say "hey, let's take these APIs and let people subclass! yay!"<p>And that's how you end up with crap like doGet(), doPost(), etc.
Was anyone else put off by "And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer"?<p>I get it's a joke, but violence against women, when used in a semi-professional context in a community of software engineers is one of those things that keeps more women out of the field in the long run.<p>I'm not trying to be PC intentionally -- it just struck a raw nerve for me.
The essay itself is funny and rings true, but then in the comments the author says:<p><i>"What I'd really like to find are some appropriate libraries that I can use to provide several kinds of functionality for my project."</i><p>And then lists a bunch of high-level website functionality requirements (user accounts, content management, etc). I realize that the J2EE landscape was drowning in complexity and was pretty dismal in 2005, but this guy doesn't understand the issues involved in developing web applications.<p>First, to suggest that individual libraries can provide re-usable high level web application code is completely ludicrous. It can't work for so many reasons:<p>* All those libraries will have to interact, and the interface between them will be complex. If they do work together they will end up being tightly coupled and before you know it you have a framework.<p>* High level functionality that includes data models, persistence, and presentation layers is not generic enough to effectively be a library. The complexity and configuration would quickly balloon out of control before it met even the requirements of 5% of web applications.<p>* Such libraries would end up being far more constricting than a traditional framework. A good example is Drupal, which is a very powerful framework/CMS with an impressive hook system, and an extremely high code to functionality ratio. Anything you might want to do with a website can probably be done in Drupal using a combination of existing modules, and you can write additional modules that access almost any part of the system and modify its behavior. The problem is that fine-tuning of the interface or certain kinds of customizations become very difficult under the crushing weight of the underlying assumptions that Drupal makes to enable it's magnificent generic-ness. The result is that all the various sites made with Drupal end up feeling very Drupal-y and there's a disincentive to really design your UI from the ground up and create a very optimized application.<p>What J2EE has blinded the author to is the fact that web frameworks exist to solve the most common problems that come up over and over again in web development. He needs to go write a few PHP applications to get a feel for the issues, then try something lighter-weight like Django or Rails that confronts those issues directly and then basically gets out of the way. In the first half of the decade it was hard to find a good lightweight framework because people were still wrapping their heads around the actual issues that needed to be solved. Nowadays, not so much.