On Mar 27, 6:11 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> So I did a quick lit search, and came to some obvious conclusions that
> don't seem to match the conventional wisdom. It looks like OO aids
> programming by organizing code. When you act on an object you don't have
> to remember what data type you're accessing.
I've been saying this in comp.lang.forth for years: Object
orientation is nothing more than a way to organize data and the code
that operates on it. It isn't always appropriate, but far more often
than not, it makes sense (or is at least a good model to start with).
The problem usually comes from people who have been exposed to an
object oriented language (say, C++) and think that because that
language has a particular model for objects, that all object
orientation is like that. They see cl*****, and think that object
orientation means cl*****. Nope. They might look at how a specific
implementation does polymorphic dispatch, and thinks that is the only
way it is done. Nope.
The only cure for this sort of thing is to look at different object
oriented languages and see the richness of what is there. Or, since
Forth doesn't have a standard object model, look at the various Forth-
based extensions for object orientation and look at the variety of
different models, trade-offs, strengths and weaknesses you see there.
> This makes it easier, because you don't have to think as much about the
> details of how things fit together. But it comes at a cost. You have to
> think out all the possible ways things can fit together, ahead of time.
> So you get complexity piled on complexity.
How about a real-world example here?
It is easy to come up with object models that make no sense. But
thankfully, object orientation has been around a while and there is
plenty of published research, practical advice, and code available to
study useful patterns. It's an area of study that crosses language
boundaries and gets into higher-level design.
> But as the design patterns show, the whole thing has been bogged down in
> complexity.
Sorry, but you got it completely backward. Some design patterns are
themselves complex in terms of description, but often when you see the
code, it becomes obvious what the benefits are. This isn't
immediately apparent to novices in design patterns, but that shouldn't
be surprising. Novices to Forth don't often grok the language until
later.
Missing from your casual quoting of some common design patterns was
the "motivation" section which typically details why one would want to
use those patterns. And usually, it's the application of these design
patterns that improves and simplifies the code. I find it amusing
that you got the exact opposite message.
> OO is a mature technology that's mostly failed. The promise was that it
> would work. The reality is that it can be made to work with a lot of
> inspired hard work, but by default it doesn't particularly get results.
> It's an improvement over random activity. Using some specific object
> modules is an improvement over re-inventing everything from scratch
> every time.
Ah, we're back to your style of writing where you make assertions
without sup****ting evidence. OO has "mostly failed" why? In what
context? In what way doesn't it "particularly get results." Try
sup****ting your statements with evidence.
> I'd like to predict what the new thing will be like. It has to explain
> why OO has failed. It must promise to succeed at those things and more.
> Do you have links to the clearest explanations about OO's promises? What
> was it exactly that project managers needed and didn't have, that they
> hoped OO would give them?
Here's a better idea. Since you're apparently a novice at object
orientation, how about you stop writing messages in comp.lang.forth
about how it has failed, and actually write some significant code in
it. Learn what works and what doesn't. Try a language like Smalltalk
or Ruby that is "objects all the way down" to see simplicity through
consistency. Try a language that doesn't use cl***** but uses
prototypes (Javascript is one) and see how that change affects your
code. Look at a language like Lua that provides just the primitives
for object orientation and lets the programmer invent any kind of
objects they want. Look at how objects were added to languages that
didn't have object originally.
Don't just go to the web, find a site on design patterns, puzzle over
confusing terminology, and pronounce that "OO has failed."
What you appear to be doing here is exactly the same nonsense that
some people who say that Forth has failed to meet it's promises. They
download gForth. They type in some examples from Starting Forth.
They get some basic stuff. They learn the basic terminology. And
then, with all of a few hours of Forth under their belt, they hop into
comp.lang.forth and write pretentious messages like yours that claim
that Forth has failed.
|
