|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |