Warp wrote:
>   I don't see it that language development has been stuck with OOP for 30
> years.

I haven't seen a new "wow, this is a great improvement" sort of thing 
happen, tho.

>   If course many/most languages support some form of inheritance and
> dynamic binding, but practical software development uses those tools
> a lot less than was expected at the height of the OOP craze. 

Agreed.  I think it doesn't solve most of the problems of "reusable 
software" it was supposed to solve.

The modularity is good, and transcends programming languages, yes.

>   But otherwise I have seen a trend in programming design to move a bit
> more away from pure OOP and more towards dynamic programming. 

What do *you* mean by the term "dynamic programming"? I know what I'd mean 
by it, but I don't know if your background would make it mean the same thing 
as mine does.

>   Of course OOP will never die. It's just too useful for many situations.

Sure. Structured programming never died - it's still inside each method, for 
example. It just doesn't scale to really big programs.

> (For example GUI programming in modern windowed systems is a situation
> where OOP seems to be just perfect. It's like OOP was invented to solve
> the GUI programming problem in the best possible way.) It's just that its
> purest form has fallen a bit out of fashion.

GUI and lots of kinds of data structures, but not really too much bigger 
than that.

I'm thinking something along the lines of LISP-power macros or other 
templating sorts of programming, or "aspect-oriented programming" might be 
next.

My guess is this:

Ignoring programing paradigms forced by hardware advances (like 
multiprocessing), I'd say the modularity has to keep getting increased. But 
the only way to do that is to have numerous bits of code in different places 
all be interacting at once. You need to separate out the error handling, the 
logging, the sanity checks, the assertions/preconditions/invariants, the 
performance hints, etc.  Sort of like the way SQL's performance information 
is separated out from the semantics - tables are tables, but index creation 
statements give you the performance you need.

I think you'll see things like the ability to say "log this message whenever 
this method gets called" or "that method can never get called with a null 
pointer", instead of having them inline in the code. Kind of like how C++ 
makes all the clean-up when there's an error be off in another bit of code, 
in the destructors of the local variables, instead of how you'd do it in C 
with an if statement or in Java with a finally clause.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message