Forum OpenACS Q&A: Response to A Technical Paper on Java

Collapse
Posted by Andrew Piskorski on
Imperative programming has proven not to be well suited for complex application development which allows reusability. One step into this direction is OO related programming ...
Sometimes, it's what's not said...

Malte's colleague's comment caught my eye, because just a week or two ago I read Patterns of Software : Tales from the Software Community by Richard P. Gabriel - you know, the guy who founded Lucid and wrote the Worse is Better paper.

Patterns of Software is really a somewhat random collection of Gabriel's articles, and certain parts of it do seem to verge on rambling philosophical mumbo-jumbo. But in other parts Gabriel makes some fairly strong arguments to the effect that the "reuse" argument for OO progamming is greatly overblown, and that abstraction in general as a software technique is greatly over-used, over-emphasized, and just plain abused.

When somebody says "reuse" in the context of OO programming, I guess they usually mean stuff like subclassing and other such OO techniques. Gabriel suggests that "the form of reuse in object-oriented languages hardly satisifes the broad goals of software development", and that "reuse" is a bad term for the reuse-like properties of object-oriented languages. He suggests that a better word and concept for this than "reuse" is "compression" - the characteristic of a piece of code that the meaning of any part of it is "larger" than that piece of code has by itself, which is accomplished by drawing meaning from its surrounding context.

So yeah, while OO programming may be a "step" in the direction of "reuse", it's not necessarily a productive step!

Hoo, well, that's more abstract language crapola than I usually like to get into - time for me to go and write some nice concrete Tcl and SQL code.

I grok Ben's "show me a site where it actually works" style argument much more fully. Also, that sort of argument tends to stay much closer to what I learned in school to be engineering, as opposed to the pointless coffee-shop style philosophical rambling that some programming language, style, and productivity arguments sound like to me.

I don't think there's been too much good science done on how programming languages and other tools impact productivity and maintainability, nor on how mixing several different tools together affects productivity and maintainability. This tends to be a problem for things like Ben's "Why not Java" article. So Ben, it might be useful to point that out, and then cite specific examples of your practical, hands on experience with overly complex and overly brittle systems, as empirical replacements for the lacking hard scientific data.

While it may not be exactly what Ben had in mind for his Java article, I find commentary like his "I have a feeling your friends worked for a big eBusiness consultant ... I've also seen the way this stuff *actually* works, and it isn't pretty ..." or Philip's bashing of Netscape Application Server in his Scalability, Three-Tiered Architectures, and Application Servers article pretty entertaining. "X sucks, here's why, here's what we can can learn from that." - I'm kinda fond of that format. :)