OO and Flexibility 
Author Message
 OO and Flexibility

One of the great features of APL as far as I'm concerned is its
flexibility.  I work in a very dynamic environment, so I frequently have
to rewrite code.  In APL, this often just means replacing a line or two
and prehaps commenting out other lines.  The problem with OO in my
experience is its rigidity.  Before you can do any programming, you have
to define the object structure.  If you make a mistake at this point,
you very often have to start the whole project over again.  And, if
you're in a dynamic environment, don't even bother using OO, as your
objects will be subject to frequent change.  The task, then, is to
somehow incorporate OO features without destroying the flexibility which
many of us need.  This is most certainly non-trivial.

BYTE a few months ago had Componentware as its lead story.  It argued
that OO requires too much initial effort.  By constructing programs from
existing components, much time can be saved.  This is particulary useful
for constructing interfaces.  Instead of defining classes and instances,
one can simply call up a component and customize it in a visual
environemnt.  Visual Basic is the most prominent example.  Perhaps what
we really need is Visual APL.

Chuck Coleman                   "Sorry, no concluding witticism"



Sat, 08 Mar 1997 23:17:07 GMT  
 OO and Flexibility

Quote:
Chuck Coleman writes:
>One of the great features of APL as far as I'm concerned is its
>flexibility.  I work in a very dynamic environment, so I frequently have
>to rewrite code.  In APL, this often just means replacing a line or two
>and prehaps commenting out other lines.  The problem with OO in my
>experience is its rigidity.  Before you can do any programming, you have
>to define the object structure.  If you make a mistake at this point,
>you very often have to start the whole project over again.  And, if
>you're in a dynamic environment, don't even bother using OO, as your
>objects will be subject to frequent change.  The task, then, is to
>somehow incorporate OO features without destroying the flexibility which
>many of us need.  This is most certainly non-trivial.

And worthwhile, I think.  The objects folks (see comp.object) routinely
argue over this point (I saved a long thread, 220 msgs in 3 weeks alone).
The "static typing" camp say it forces them to design better and to write
safer programs; the "dynamic typing" camp say it is more powerful and
flexible, should design requirements change or become better known after
initial exploratory programming.  So, you have lots of allies (including me)...

Quote:
>BYTE a few months ago had Componentware as its lead story.  It argued
>that OO requires too much initial effort.  By constructing programs from
>existing components, much time can be saved.  This is particulary useful
>for constructing interfaces.  Instead of defining classes and instances,
>one can simply call up a component and customize it in a visual
>environemnt.  Visual BASIC is the most prominent example.  Perhaps what
>we really need is Visual APL.

But this only dumps the OO problem in the lap of APL vendors.  I mean, _they_
need OO to build these components.  Maybe they can do it in C++, but that
would take a long time.  At some point, they will have to use OO inside APL.
Also at some point, _we_ will have to use OO inside APL, because they do.




Tue, 11 Mar 1997 23:01:17 GMT  
 OO and Flexibility

   ... The problem with OO in my experience is its rigidity. ...

Not to put to fine a point on it: what is your experience?  That is,
which languages have you used, and on what projects, that brought you
to your conclusion?



Wed, 12 Mar 1997 17:24:53 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. OO and Flexibility

2. Forth flexibility

3. Namespaces, Flexibility & Dylan

4. IBM Compiler and Library for REXX on zSeries Release 4 increase efficiency and flexibility

5. try/except/else flexibility...

6. SENIOR OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

7. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

8. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

9. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

10. Use of O.O. metrics to estimate the effert and cost of O.O. projects

11. Real OO (was Choice of OO primitives in Ada95)

12. Real OO (was Re: Choice of OO primitives in Ada95)

 

 
Powered by phpBB® Forum Software