A Battle For The Future
I stumbled upon this article about why Java will not be the language of the future. The author makes the assertion that because using XML is so painful in Java (which I won't disagree with), Java is a lousy language to do lots of text processing with. This misses the essential point of a good object-oriented language. A good object-oriented design should push the XML-specific concerns to the very ends of the request-response model. The bulk of the code should have a nice domain model that has XML transformations at the beginning of the request (into objects) and at the end of the response (into XML).
His assertion is based on the notion that XML (or XML-like structures) would pervade your code and be your domain model. This smacks of the kind of reductionism that views the world simply as lists or parallel arrays. The implementation and storage are intimately tied together completely removing any layer of abstraction. The fundamental problem with a lot Perl/PHP solutions is that there is little separation between the bare-metal shuttling of database data onto web-pages.
There is an argument to be made for avoiding an overly grand design. For certain web applications I can understand the frustration developers would have dealing with the behemoth that is the J2EE web container to build a simple interactive application. But somewhere in the continuum of complexity the cheap and easy, bare-metal solution won't scale. It becomes way too hard to maintain that kind of application because there are no layers of abstraction. These layers should be here not for the sake of high-minded academic design, but to serve as firewalls to change throughout the application.
His assertion is based on the notion that XML (or XML-like structures) would pervade your code and be your domain model. This smacks of the kind of reductionism that views the world simply as lists or parallel arrays. The implementation and storage are intimately tied together completely removing any layer of abstraction. The fundamental problem with a lot Perl/PHP solutions is that there is little separation between the bare-metal shuttling of database data onto web-pages.
There is an argument to be made for avoiding an overly grand design. For certain web applications I can understand the frustration developers would have dealing with the behemoth that is the J2EE web container to build a simple interactive application. But somewhere in the continuum of complexity the cheap and easy, bare-metal solution won't scale. It becomes way too hard to maintain that kind of application because there are no layers of abstraction. These layers should be here not for the sake of high-minded academic design, but to serve as firewalls to change throughout the application.
0 Comments:
Post a Comment
<< Home