The relative verbosity of programming languages isn’t the interesting thing; nor is typing doctrine. What’s interesting is the culture of frameworks and what different communities deem valuable. My sense of it is that on Java, too many web frameworks - think JSF, or Struts 1.x - consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal. –Design for the Web
Java is a general purpose, object oriented programming language. It’s roots in early 90’s object oriented theory, more importantly, the desires and goals of that theory can’t be overlooked when asking why Java is the way it is. The culture of Java design is to push out commitment to a given way of doing things (an “implementation”) as much as possible. In Java culture, dependencies, esp. conceptual ones, are nasty and to be avoided. They’re taboo, even.
The VM
The virtual machine architecture it, itself, the first embodiment of this: rather than benefit from direct access to the underlying operating system and executables there, all access to the OS is mediated via the VM and libraries. It’s considered bad form to actually have to know what OS or even machines you’re running on. There’s good reason for all this, of course, in that you magically swap out the OS or setup and not have to re-code things.
QA loves it when you do that!
Libraries
Nothing represents Java’s distaste for implementation dependency more than the older libraries in Java that follow a plugin architecture. Take JAAS or JNDI, for example. The general functions are abstracted into a handful of classes and interfaces that don’t actually do anything: they just model the possibilities. With some weird wiring up of implementations, you can actually interact with LDAP servers and get things done. The same applies to, for example, XML parsers, transaction engines, and all matter of places.
And thanks to all those layers of abstractions, if you want to magically swap out your LDAP servers to something new (OpenID?), you can just do it!
Again, QA loves it when you do that. They embrace it!
UIs, including the Web
Java’s take on UIs is much the same. You never know when you’re going to want to swap out your UI, so you better work with an abstract layer to buffer you from dependency on any given UI. That Swing based app needs a web UI? No problem, just edit that XML file. Magic!
QA especially likes it when you change the UI.
Sarcasm Check: All this Swapping Out
Now, I’m being glib about all this swapping in and out of things. There are some things that it works well for in Java — file systems, sorting algorithms, collections, and all sorts “low level” API things. At the framework and application layer, however, I think the notion that abstraction help you is largely crap:
By the time you’ve written your abstraction layer, you’ve essentially written your own framework. Chances are, you’re not a good framework writer, and it’s going to suck, and you’re going to realize that one or two versions down the road and re-write it.
New frameworks and ways of building applications will come along that you want to use (web applications, clustering, Ajax, mobile access) that don’t readily map to the metaphors, idioms, and expectations of your abstraction layer. At this point, you’ll get upward leak as the new things you want to do are bolted onto your abstraction layer.
The chief reason it’s crap, and to Bill’s point, is that you’ll always be sacrificing fully taking advantage of things you’ve abstracted away, or making them harder.
To be fair, I’m jaundiced when it comes to heavy abstraction, ladened with the unreasonable exception that most everything will be re-written sooner rather than later. This is probably due to me having worked in less than ideal conditions in the past, so for those of you working in what would be to my experience, relative nirvana: hats off!
If anything, I would concede that abstraction is better left as the coda to a round of development. Again, if you’re smart enough to do design up-front: hats off, dear reader! Your ‘umble servant is not so.
Java Applications vs. Web Applications
More pertinent to Bill’s point of ETags in Java, the problem is that Java developers are building Java applications, not web applications. As such, your concern is doing things the Java Way, not the web way. You trust that by doing things in the Java way, Java will help you avoid the long term problem of maintenance and changeability. The strict practices of Java won’t let your code cement and take ages to update and will prevent your code from becoming incomprehensible piles of tangled wire.
(I could go off on a long tangent about that being the last, and often over-looked, point of good software development, but I’ll keep it short: making it so that, come version 5 of your software, you can easily add in new features with out taking a long time and costing a lost of money. Unless you end up staying at the same programming job for more than 2-3 years, this point is really irrelevant, so most people could give a damn.)
It seems to me that people building LAMP, Ruby, django, or other applications think of themselves more as building web applications with whatever technology tools they need to use: web services, cron jobs, MySQL, ruby, PHP, python, maybe some Java: whatever. What matters is getting the web application working.
People who using Java see themselves primarily as building Java applications that happen to have a “view” (as we OO head-jobs would call it) that’s the web. Our primary goal is the metaphysical and headless application, not the delivery mechanism. Hopefully you can get a sense for my view of Java culture at this point: it’s more concerned with keeping the concepts, work-flows, and design of the application pure and tidy than optimizing the delivery mechanism, or implementation. Them UML diagrams should look good.
Again, Java’s belief is that this will save you in the long run, which may be true. I have not coded in Eclipse, but those who do, like Mik Kersten, tell me that Eclipse’s object oriented nature over the long haul has paid off when it comes to adding in seemingly “simple” features like hyperlinking to any piece of text in the UI.
Ultimately, Java is a culture that emphasizes knowing less rather than more. Anything you know and act on in your application is a dependency that can cost you time and money in the future. Better, the thinking goes, to deliver less and be able to sustain it over the long-haul than to deliver more and run out of code energy in long run.
People Are the Ultimate Leaky Abstraction
Obviously, all of this is a generalization. But, I think it’s handy for sorting out the difference between Java programming and web application programming. The allegiances for each are to different philosophies driven by the goals of the developers (to stereo-type: long term maintainability vs. ultimate end-user experience), and the resulting cultures and, thus, applications, are starkly different.
The people you choose and the resulting technology they choose will result in wildly different applications than another set of people. That, dear readers, is the ultimate leaky abstraction.
Disclaimer: Eclipse is a client, as are MySQL and Sun.
Previous Topic
