In the interest of discussion.

talk_at_forth.com wrote:

> Original sender: Marcel Hendrix <mhx_at_iaehv.IAEhv.nl>
> Charles Esson <charlese_at_cvs.com.au> writes Re: SFTALK - OOF
>
> >> A little more seriously: OOF *will* take off when somebody writes
> >> extensive non-trivial libraries in or with it. Not when yet another
> >> slick extension comes along.
>
> > And that won't happen until the syntax is standardized, and the syntax is
> > not going to get standardized, QED.
>
> Then a standard is not needed (how do you standardize what is not used?)
>
> Here are some alternative thoughts to shoot at.
>
> a. "Forth won't happen until the syntax is standardized, and the syntax is
> not going to get standardized, QED." (said 12 years ago). We certainly
> wouldn't have living Forths today (e.g. SwiftForth) if everybody had
> waited for a standard to materialize.

I won't enter that one other than to say FORTH inc. are heavily involved in the
standardization effort, and I assume they are not there for there health. I am
of the view that forth would not be where it is without the fig
implementations. A implementation offered as the fig version were, are a
standard, a standard that has no loop holes.

>
>
> b. One reason OOF doesn't break through is because it is not useful enough
> to a single programmer.

Yes that's how C++ is sold, with this method you can better hide the
functionality. I don't buy it, OOP is just a another technique. I myself have
always preferred table driven programs, that is the job gets done with large
table sets and a small interpreter, that's why I like FORTH, it's easy to do in
FORTH hard to do in C. But It doesn't mean other methods are invalid

> It might be a big benefit in multi-programmer
> teams.

It might be but I don't think so, I think it's more likely to be a big benefit
to a particular set of problems. As I said before, objects are useful if you
want to call a function at runtime with no knowledge of the data type at
compile time.

The trouble with OOP is that it requires a different mind set, and one extra
level of abstraction to deal with. Do you want a persistent object ( in the
dictionary ) a temporary object ( on the heap). And the cross compiler, the OOP
extensions make does> look like a piece of cake.

Because OOP adds this extra level of complexity it would never be an option I
would use for a large programme team.

> This might mean OOF will only happen when big users start to
> demand it. However, typical OOP projects like the Linux OS, with
> enormous programmer teams, are not using it.

They tried C++ and abandoned it. But your argument revolves around the
assumption that it is a useful tool for large projects, I maintain it is a
useful tool for a particular set of problems.

> And the big commercial OOP
> softwareteams of our time don't have enough real competition (can you
> say Office-97?) to enable us to decide if their approaches are *really*
> working.

> c. OOF *is* enormously useful, but in special domains that are not of
> extreme interest to most Forth programmers (e.g. GUI design, graphics,
> desktop programming).

I won't flame this as I tend to agree, I also think its a nice solution to the
OS I/O problem, a project I had put on the back burner waiting for OOP
standardization but I am now doing as it is obvious standardization will not
occur.

An I spell check this email I had the thought, spelling standardization brings
advantages, but the english would can't even do that, we have renegade counties
that go off and do there own then thing.

Regards Charles Esson

> (If you choose to flame this one, please use
> non-trivial examples).
>
> -marcel
>
>

.
Received on Thu Jan 28 1999 - 07:55:30 PST