Re: Development Trends in Web and Oracle

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 14 Mar 2005 20:00:04 -0600
Message-ID: <usm2xcwcu.fsf@hotpop.com>

On Mon, 14 Mar 2005, wizofoz2k_at_yahoo.com.au wrote:
> Galen Boyer apparently said,on my timestamp of 14/03/2005 12:58 PM:
>
>

>> delivered faster and less buggy.  If the CPU is fast enough so that
>> the overhead is small enough, then corporations will choose the
>> less-performant solution to get to delivery faster with higher
>> quality.  It has happened this way throughout the life of technology.

>
> yes, Galen. The problem is: the CPU is not fast enough to
> cope with the immense overhead that is being placed on it
> in the name of a dubious "simplification". That is why there is a
> constant need for this famous "scalability": the only way to extract
> ANY performance out of the darn thing is to throw immense hardware
> resources at it.
>
> Show me ONE Java or J2EE or XML project that has resulted in LESS
> code being written.

One that I was involved in two projects ago. They passed XML around and it was immensely successful.

> One!
>
> When I see more code I see complexity, difficulty of integration,
> difficulty in maintaining and improving.
>
> The purpose of the evolution of programming languages and
> architectures is to make programming easier. Have you looked at a
> program that processes XML or follows its architectural demands? It's
> not pretty... Same applies to J2EE.
>
> I have yet to see ONE project using either XML or J2EE that hasn't
> resulted in massive "refactoring" (read: re-design and re-development)
> once someone wants to expand the base delivered functionality.

I blame that on the idiots that want to rewrite the technology of the database tier in the middle-tier. To tell you the exact issue, its the J2EE spec which is the issue. Armed with a J2EE spec, developers now user terms like "industry standard" and "business logic in middle-tier" and caching, and ...

2 years ago, Entity Beans were industry standard, stateful session beans were the rage and stateless session beans were the workhorses. They were part of the J2EE spec, so clearly, they were the correct way to go. Now, each one of those is shown to be horrific designs and they are starting to talk about Plain Old Java Objects, but I guess thats an architecture.

> One!
>
> That is NOT a technology that anyone should follow to reduce costs...
> As for quality, the lesser said the better.

Quality is all about the architect and implementation. It can be done with java and XML.

-- 
Galen deForest Boyer

Received on Mon Mar 14 2005 - 20:00:04 CST