Library Oriented Programming
What do you think of this idea? It's an idea about a way to program. I call it Library Oriented Programming.
I don't know if this is a new coinage, but it refers to programming principally with third-party libraries and using the main program to glue the libraries together. You model the problem as a sequence of library calls.
I got this idea after reading Josh Susser's response to David Heinemeier Hanson's talk at RailsConf two weeks ago.
Short synopsis:
DHH says there are three ways that Rails could lose its "advantage" over "mainstream" web frameworks.
- Mainstreams frameworks copy Rails' good features
- A new technology comes along that is better
- Rails becomes mainstream
Josh Susser insightfully responds that a fourth option is possible: that mainstream technology comes up with something that is "good enough". Rails could have ten times the productivity of other current technology. The new techniques might only double productivity, but that's good enough for the mainstream guys. And that will defeat the Rubyists' hopes for world domination.
It made me start thinking about what advantages Java has over Lisp. And definitely the proliferation of Java libraries is an advantage. So even though Java is not as powerful as Lisp on its own, the availability of several orders of magnitude more libraries is a distinct advantage. It helps explain Java's dominance in the market.
I often underestimate the network effects of lots of users. And the effect of millions of dollars being funneled into Java library development. I hate how Java makes me create an anonymous class just to create a lambda. But I have to do it a lot less than I would have since so many of the libraries are decently designed. And that means they are designed to use the strengths of Java and avoid the weaknesses.
So the language doesn't have to have the powerful abstractions of other languages. It takes more work to build a library. But who cares how much it costs when IBM funds it? The libraries take Java halfway---and that's often good enough.
Syndicate
Navigation
Recent blog posts
- Avoiding the Functional-Relational Bridge
- Lispy Idioms
- The Paradigm Cycle
- Java is not Object Oriented
- A Killer App for Common Lisp
- Lisp, too, is mainstream
- Help your users kick ass
- The next LLL killer: High Level Optimization
- Automatic Refactoring Framework for Common Lisp
- Lisp has always been about easy
Comments
Scripting and such
This sounds a lot like the commonly accepted definition of "scripting". It isn't necessarily in line with how so-called "scripting languages" are used, but it's an ideal to aspire to, and you really can't fault people for preferring to do general purpose programming in Perl, Python, or the like when they can get away with it (suggesting that designating them specially as scripting languages is itself a bit silly with definitions like these).
Mainstream technology is the very definition of "good enough". Java strikes me as extraordinarily cumbersome and unsuitable as a glue language, though. If you're programming at such a high level where you're just constructing graphs of library-provided objects and piping data through them, the noise in creating and connecting them will overwhelm the signal. Even if you find it's an acceptable cost, someone else will sell an easier way to the world with a fancy name, and the cycle will continue.
That said, I think the case for libraries is made too strongly these days. They make your software hard to build, add maintenance and versioning headaches, and all too often are necessitated only to abate the gratuitous complexity imposed by external requirements beyond your control -- user interfaces, XML, baroque communication protocols, complex file formats, the colossal clusterfuck of a technology stack presented by modern web browsers, and workarounds for the prevailing buggy and incompatible implementations of all of the above. They're certainly useful or even indispensable for many classes of tasks, but rarely are they pertinent to the core of the task being solved, and I regard them as more of a helpful nuisance.
As an aside, it strikes me as disingenuous to discuss programmer productivity as if it were an isolated topic in a world which, in the name of progress, regularly moves the goalposts without a clear conception of the cost, particularly given how often the proposed solution is to fight the unacknowledged enemy of complexity with more complexity.
Too Many Frameworks
I wrote on the antithesis of this topic, and even consider Library Oriented Programming harmful. See http://www.falvotech.com/blog/index.php?/archives/359-Middleware-Conside...
Other languages on the JVM
I'm pretty surprised this wasn't mentioned in the post, but what about the other languages on the JVM? For instance, Clojure is getting a decent amount of press lately. It's a Lisp dialect built with concurrency and interoperability with Java libraries in mind. Not to mention Scala, Groovy and various ports of non-native languages.
Now that Sun seems more receptive to these other languages built on the JVM, I'd guess that they'll continue to gain traction. While Java the language isn't going to actually die out any time in the foreseeable future, I wouldn't be surprised if Java the platform became more of the norm in the coming years.
Post new comment