Skip to main content

new vocabularies for new problems

Posted by michael_n on April 18, 2005 at 1:44 AM PDT

Increasingly, I feel like being a good, responsible Java developer no longer means merely being able to write solid code in Java, but rather increasingly it means knowing when not to program in Java. And that's a lot more work.

(author's note / disclaimer: I just realized after posting this that the title makes this sound like an entry on domain-specific languages, which would have definitely been an interesting blog entry... unfortunately, that'll have to wait. This post is about the proliferation of (open source) frameworks and building blocks, and thoughts on their acceptance, rejection, and their impact (good/bad/ugly) on the lives of developers.)

In any project, there are the typical constraints of time, quality, and cost [1]; and so many fingers can type only so fast to produce so much code. (And, adding more fingers to an already late project only makes the project... have more fingers.)

But, as Rich Unger recently wrote, there's a ton of existing stuff out there already, claiming to make life easier on us poor haggard developers. Sometimes, I swear, more code is written by developers for developers than for projects that have actual users [2].

But then, I think to myself... if only I already completely understood each of these projects, how they can (or shouldn't) fit together.... and, if I were aware of the new ones that are daily popping up on the scene, and their viability, with an awareness of which ones are dropping off the radar.... If only this, I think I could really improve my productivity, and materialize those 15 ideas I've got bouncing around in my head, with chunks of code that themselves will only continue to improve in quality and functionality, just by pasting off-the-shelf building blocks into off-the-shelf frameworks; tab-A into slot-B type stuff. And other developers will understand "my" code, since they've already seen those same building blocks... (That's always been the dream, hasn't it?)

I don't know if we all afford to be such über-developers and keep track of this plethora of projects (merely in terms of time commitment, all other things being equal - which they're not). Certain Darwinistic concerns require us to have at least a little time away from the computer, now and then, if we are even to have future generations to inherit our oral tradition of "punch card" stories....

One of the inherent problems I see is that developers tend to have a hard time understanding something (a framework, for example), unless they write it themselves, even at the toy example scope. That's the language developers speak. Perhaps some of the best tools out there, which mask the most complexity from the developer, will become the least widely adopted, merely because the framework itself cannot be easily replicated at a "hello world" scale (I'm not talking about a usage-example, but rather an "internals" exposition). Most of the "neat" ways of doing things may, at some level, require a paradigm shift of sorts, and these... take... time....

This is, I think, one of the greatest reasons behind the success of the Design Patterns "movement"; it merely builds a vocabulary upon a common shared experience (since patterns are, after all, pre-existing solutions to commonly occurring problems). For developers of new frameworks, one of the most important indicators of success of the project will be the definition (and clarity) of the Language chosen to describe the Work that the framework attempts to do. Remember the whole mess (and excitement) around trying to clarify what MVC-"model 2" meant, vs. traditional MVC?? Despite not being a very good "vocabulary", this MVC-model 2 thing was in part responsible for the success (in terms of adoption) of the Struts project.

I thought for sure I wouldn't have to (or want to) learn another language after getting so comfortable with Java (besides, say, Beanshell or something). But my vocabulary has always had to increase in order to remain productive and solve new problems; first, the ridiculous expansion of the Java "language", from 1.0 through 1.1, 1.2, and 1.3 and beyond (an API almost tripling in size with every "minor" release); and then, the power of Design Patterns to describe larger ideas with precious few words; and next, ...? What powerful, clear, expressive language is coming to help developers "grok" the next star-favored framework?


  1. My corollary to the old theorem, "Given {Quality, Cost, Time}, only Two can be Picked":
    Given N constraints {Quality1, Cost2, Time3, ..., CN }, if you consciously pick to achieve X constraints from the set of N constraints, you will always achieve < X . (In other words, N-1 is never a "given" for X.)

  2. In the parlance of postmodernism, this is the highly "self-referential" stage in our development away from the "modernity" of our presumed progression from assembly to C, to C++, to Java, to Java about Java....

Related Topics >>