On 28 Mar, 06:14, John Passaniti <john.passan...@[EMAIL PROTECTED]
> wrote:
> 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: =A0Object
> orientation is nothing more than a way to organize data and the code
> that operates on it. =A0It 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. =A0They see cl*****, and think that object
> orientation means cl*****. =A0Nope. =A0They might look at how a specific
> implementation does polymorphic dispatch, and thinks that is the only
> way it is done. =A0Nope.
>
> The only cure for this sort of thing is to look at different object
> oriented languages and see the richness of what is there. =A0Or, 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. =A0But
> thankfully, object orientation has been around a while and there is
> plenty of published research, practical advice, and code available to
> study useful patterns. =A0It'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. =A0Some design patterns are
> themselves complex in terms of description, but often when you see the
> code, it becomes obvious what the benefits are. =A0This isn't
> immediately apparent to novices in design patterns, but that shouldn't
> be surprising. =A0Novices 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. =A0And usually, it's the application of these design
> patterns that improves and simplifies the code. =A0I 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. =A0OO has "mostly failed" why? =A0In what
> context? =A0In what way doesn't it "particularly get results." =A0Try
> 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. =A0Since 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. =A0Learn what works and what doesn't. =A0Try a language like
Smalltalk=
> or Ruby that is "objects all the way down" to see simplicity through
> consistency. =A0Try a language that doesn't use cl***** but uses
> prototypes (Javascript is one) and see how that change affects your
> code. =A0Look at a language like Lua that provides just the primitives
> for object orientation and lets the programmer invent any kind of
> objects they want. =A0Look 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. =A0They
> download gForth. =A0They type in some examples from Starting Forth.
> They get some basic stuff. =A0They learn the basic terminology. =A0And
> 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.
I agree with all that John Passaniti says above.
I'm writing this to feed in some experience of using design patterns
with Forth. After being introduced to the GoF Design Patterns book a
few years ago and wanting to build a Forth cross-compiler for myself I
decided to use the Abstract Factory Pattern to build a target ANS
Forth system. The idea was that the bulk of the cross compiler would
be standard and there would be different factories for the type of
desired target system. The target source code was to remain unchanged
if possible.
For example the initial, and so far only, factory is for direct
threaded code with detached headers. In principle if a traditional
indirect threaded code target is wanted all I have to do is write a
factory to do it, i.e. define the appropriate subcl***** and the
methods needed to generate that type of code. Similarly for a byte
code target. Again in principle, but I'm less confident this could be
done as easily, factories could be written to generate a target system
in C or assembler.
There is nothing really new in this approach, as John Passaniti says
using the OO approach is simply a different way of organising the
code. I did it with the specific aim of being able to generate code
for different targets.
Was it successful. Yes I think so - I've been using the direct
threaded code system since with few problems. As for re-targeting it I
can't yet say as I haven't had the motivation or need to do so but am
confident it would be fairly easy. I'm sure the source code for the
cross compiler is much bigger than it need be due to the OO approach.
There were a few things I couldn't abstract to a higher level in the
target source code e.g. >BODY. Also as it generates a form of byte
code that, on loading is resolved into calls to primitives, relative
addresses made absolute etc. the source code for the target system has
to indicate whether any preset data are addresses. A potentially
useful by-product from the fact the target source code, except for the
primitives, is written in ANS Forth (unproven as yet) is that a Forth
application could be cross compiled for a particular target.
As I said I'm just re****ting some experience.
Gerry
|
