> *You need methods to work around the benefits your objects give you.*
> *You need methods to flexibly handle extreme complexity.*
> *You need methods to reduce the expense of all this OO complexity.*

> 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.

> On Mar 27, 6:11 pm, Jonah Thomas gmail.com> 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 classes, and think that object
> orientation means classes.  Nope.  They might look at how a specific
> implementation does polymorphic dispatch, and thinks that is the only
> way it is done.  Nope. ...

> Jonah Thomas gmail.com> 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).

>On Mar 27, 6:11 pm, Jonah Thomas gmail.com> wrote:

>

>> 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.

> John Passaniti gmail.com> wrote:

>>On Mar 27, 6:11 pm, Jonah Thomas gmail.com> wrote:

>

>>

>>> 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. ...

> Sure. Your advice is good but it doesn't fit my needs. Let's try a
> similar discussion in a different context. I don't like quantum
> mechanics because by all accounts it does not make sense. People can
> solve problems with it but they get no sense of what's possible from it,
> and experienced QM users tend to have no useful intuition about problems
> they have not yet formally solved. In some contexts it looks like a dead
> end. And by some accounts it is sort of invalid, some of the results
> come from things like fudge factors and taking the first few terms of
> series that aren't sure to converge and so on. I don't like it but I
> don't have much to do with it. If I were to go onto a physics newsgroup
> and say I don't like it because it doesn't make sense and I want
> something that will get similar answers that does make sense, I expect
> I'd get a response that's very similar to yours. "Before you criticise
> QM, you need to learn all about QM. Learn all the math. Learn how to
> solve QM problems, and solve a lot of significant problems, not just
> simple textbook examples. Only then will you be qualified to discuss the
> issues with it." But I wouldn't want to do that. Probably I have only
> around 30 productive years left. Should I spend, say, 15 of them
> learning all about something that I have every reason to think will not ...

> 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, ...

> 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.

> I don't fully agree with my own OO-bashing. 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 circumstances. OO marketing has run its course.