Re: Emperor's new clothes - ACM followup.

[Lawrence Dickson <tjoccam@xxxxxxxxxxxxx>]

I think Jim and Andrzej both missed Dyke's point. Of course tools like
OO have their value IN RESTRICTED AREAS: for instance, OO is excellent
(apparently) for point-and-click menu applications with lots of 
screens. It was a "tool to manipulate data" that bollixed it. 

Perl does offer the capability of paralleling data flow processes in
a few lines, as my son discovered when debugging a phone company's
data choking problem. He wrote a script that simulated thousands
of simultaneous users. It was easier than C or bash.

OO is so knowledge-centralized that using it on any assembly of 
truly independent components tends to suffocate the project in
complexity. I have been involved in at least two projects that
ground to a halt this way (one was revived in C, the other in
Perl). A data flow design with truly independent (running) 
components is not only quickly completed, but also documents itself
for the developer entering 6 months later (I'm doing exactly this
at the moment). Because all information passes through channels
instead of hierarchies.

Larry Dickson

>From owner-java-threads-out@xxxxxxxxx Mon Feb  4 11:00:35 2002
From: "Lewandowski, Andrzej" <andrzej.Lewandowski@xxxxxxxxxx>
To: "'Dyke Stiles'" <dyke.stiles@xxxxxxxxxxxxxxxxxx>,
   Java Threads
	 <java-threads@xxxxxxxxx>, occam <occam-com@xxxxxxxxx>
Subject: RE: Emperor's new clothes - ACM followup.
Date: Mon, 4 Feb 2002 13:57:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk

 
> 
> This month's ACM had three letters in response to Ledgard's 
> piece that I 
> reproted on earlier. All agreed with Ledgard that OO was not 
> solving the
> problem.
> 
> One had another concrete example: his firm hired a Java/OO 
> consultant at 
> $150/hour to do a parallel development of a tool to 
> manipulate data. After
> 6 weeks the Java had nothing running; the other group 
> completed their PERL
> implementation in one week. 
> 
> 

"Parallel development of a tool for analysis" or "Development a tool for
parallel
analysis"?... I see a little support within Perl to do parallel computing.

By the way, what the above example is going to prove?...

A.K. 



>From owner-occam-com-out@xxxxxxxxx Mon Feb  4 12:06:45 2002
Date: Mon, 4 Feb 2002 19:03:56 GMT
From: Jim Davies <Jim.Davies@xxxxxxxxxxxxxxx>
To: dyke.stiles@xxxxxxxxxxxxxxxxxx
CC: java-threads@xxxxxxxxx, occam-com@xxxxxxxxx
In-reply-to: <3C5ECA34.94F2E3C8@xxxxxxxxxxx> (message from Dyke Stiles on Mon,
	04 Feb 2002 10:51:48 -0700)
Subject: Re: Emperor's new clothes - ACM followup.
References:  <3C5ECA34.94F2E3C8@xxxxxxxxxxx>
Precedence: bulk


(okay, this wound me up - if you don't feel the need to read a Monday
 evening rant on Software Engineering, then please delete this now).

   This month's ACM had three letters in response to Ledgard's piece that I 
   reproted on earlier. All agreed with Ledgard that OO was not solving the
   problem.

All showing that there's no entry requirements, or fees, at the school
of stupidity and self-promotion.  (So why, oh why, did I have to pay?)

   One had another concrete example: his firm hired a Java/OO consultant at 
   $150/hour to do a parallel development of a tool to manipulate data. After
   6 weeks the Java had nothing running; the other group completed their PERL
   implementation in one week. 

OO is a wonderful way of understanding and organising complex systems
and situations that gives you a chance of being able to maintain that
understanding when the organisation, or the components thereof, have
to change, or when the complexity increases, or when time just passes
by and you don't have the consultants around and for some reason you
still need the system that they built for you.

Time and time and time again you get *proof by example*, when all that
this method allows you to do is prove that some assertion is not
_universally_ true, or that there is at least one case in which your
argument appears to be true.  No need for formal methods.  No need for
OO.  No need for whatever new technology or approach (or art, if you
like) you can suggest.

And boy, don't people like an excuse not to think, or not to learn. 

I'm not going to bore you with a patient explanation of why OO *is*
invaluable, and why most other sensible structured approaches boil
down to the same thing, and which bits of the OO bandwagon are simply
nonsense and always were, and how OO is the modelling framework we
needed for projecting and slicing smaller models for analysis using
formal, or rigorous, or transferable (my current favourite) reasoning.

(look! naked formal methodists!)

I suppose that the article and letters might be part of a convergent
sequence of opinions, but it's irritating to see the true position go
past time and time again, because people won't address enough
contextual information, or even think too much, in their quest for the
latest approximation.

And no, I have nothing to say.  Except YES! if you have a simple
problem, that fits PERL's domain then of course you should use PERL.
Doh.  If you have a serious, large software engineering problem, then
you might use PERL for some simple, flat aspect, but you don't start
using it for the Walls.

x Jim

p.s. this isn't intended as any kind of rant against Dyke, or even a
cogent response to his email, naturally