Albert van der Horst <albert@[EMAIL PROTECTED]
> wrote:
> John Passaniti <john.passaniti@[EMAIL PROTECTED]
> wrote:
> >On Mar 27, 6:11 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> <SNIP>
> >
> >> 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.
>
> I was a novice with regards to design patterns. I tried to read the
> book and fell asleep (time and again). It is just a very elaborate
> way to make explicit the tricks, I already used all the time.
> Reading the book doesn't help to use a trick, I would come up with
> in a new situation.
OO is a methodology, and a formal method, and a collection of coding
techniques, and a marketing gimmick.
The methodology is useful whenever it's useful, maybe pretty often. The
formal method is an attempt to formalise the methodology and is partly
successful at that. To the extent it works, you can rationally think
about things you might perhaps have done by instinct before. And it
gives a language to discuss programming with, that stresses some things
and ignores others, and when you want to talk about what you're doing
it's better to have some common language than no common language.
The coding techniques are worse than useless without a clear concept of
the methodology. They are some use when you're clear how to use them,
and you may find better OO techniques to do similar things whenever you
see the value in doing that. The marketing gimmick is old and tired and
ready to be replaced.
> However. It is very im****tant for professionals to at least know
> the book. Sometimes you come accross some absolutely brain dead
> overcomplicated code. Chances are that they copied it from their
> bible "design patterns".
One of the early promises of OO was that great designers could set up OO
systems that mediocre coders could then use, and the coders would find
things arranged so simply that they wouldn't make mistakes. This promise
has failed, probably inevitably. Instead we sometimes get mediocre
designers making OO systems that get in the way for good programmers who
come after them. Of course this is not exactly a flaw in OO, it's a
misuse of OO. But the marketing promise that OO would be hard to misuse
has failed.
> So John, you may be at the side of the fence where objects are
> beneficially used. And I don't agree at all with the OO-ba****ng
> Jonah does. For example my manx2 program, a rewrite of Marcel
> Hendrix's manx program in OO fa****on, is decisively more maintainable.
>
> But surely there is ground for the kind of concerns Jonah expresses.
I don't fully agree with my own OO-ba****ng. I think the time has come
that a new marketing gimmick can replace the OO marketing gimmick, and I
wonder what it will be like, and I fall into that sort of language when
I think in those terms. OO methodology is OK, most of us use it when
it's clearly useful. OO formal methods are OK, they can be useful in
specific cir***stances. OO marketing has run its course.
> Bad programmers/designers don't go looking for a solution to a
> problem. By using a solution they create a problem where there was
> none before.
Sure. And ideally you'd like a system that reveals the problems *right
away* instead of hiding them until a lot of work has already been done.
> >> 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.
> >
> >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.
>
> Indeed. There is this terrain of 3-D graphical games, with AI
> opponents. I'm quite sure nobody would get that far with a 20 by 3
> meter wall full of flow-charts like Jonah seems to propose.
No, I sure don't propose that. I say that OO takes a lot of nonobvious
work to get right in a complex situation, that specific OO coding
practices are sometimes more useful and sometimes less useful, that OO
formal methods cover some of the ground they ought to cover but perhaps
sometimes emphasize the wrong things. That we're ripe for something with
a new name with some new ideas behind it to get marketed the way OO was
marketed long ago. I certainly don't say that it's better to approach
complex problems with no plan, than it is to approach them with a plan
that's sometimes hard to use well and that sometimes isn't a great fit
to the particular problem.
> Good advice, not just to Jonah.
> If he wants to stay within Forth, he may study the manx2
> program available on my site. It uses very simple OO techniques,
> but I cannot answer the question how I would have managed without.
>
> (manx is a music notation, and plays music real time on
> mechanical instruments)
I have the idea you did well to keep your OO techniques simple. Again, I
don't dispute that there are problems for which a good designer can
effectively use OO. I don't intend to say that OO is so bad it always
poisons everything it touches. I do say that we're ripe for something
new that promises everything that OO delivers and more, and I'm
interested in what that might be like. Also, I'm curious whether it
might involve techniques that are particularly easy to do in Forth.
|
