Noons 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!
>
> 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.
>
> One!
>
> That is NOT a technology that anyone should follow to reduce costs...
> As for quality, the lesser said the better.
> ~
I'm with Noons ... I've yet to see one. J2EE is the latest manifestation
of one tool fixes all problems. It isn't the fault of the tool so much
as the single-mindedness of those that wield it.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)
Received on Mon Mar 14 2005 - 08:21:51 CST
