Re: Is Forth more focused on detail rather than on concept?

On Tue, 03 Mar 2009 14:39:56 +0100, Bernd Paysan <bernd.paysan@xxxxxx>
wrote:

Stephen Pelc wrote:
Why is ANS unsuitable? Give examples, not hand-waving please.

IMHO, the situation now is not as bad as it was, because Forth200x reopened
the standardization process, so people like me who write their own Forth
can move ahead, and drag the rest with us. ANS is so 1990s,

It's a product of the 1990s.

and using
proprietary extensions sucks a lot. E.g. the VFX port for MINOS has 1500
lines of extensions I need to make to VFX before I can start using it (most
of them are small files, apart from OOF, which is 50% of those 1500 lines),
and another 1500 lines of just platform specific code in the form of C
bindings. The next port will have those 1500 lines again, because the next
platform will have another different C interface (the next port is to
Gforth, and will use the CC-based C interface).

That's why some us have been banging on about standardising the C
library interface for years. It's only when you start porting big
library code that people understand why it's so important. I doubt
that we'll ever be able to do without any harness code (Gforth itself
proves it for C code), but good practice (lots of documentation) when
porting makes the sencond and third ports very much easier.

If anyone is around for the Forth200x meeting 25-27 march 2009 before
Forth Tagung, I arrive Tuesday afternoon. One of the topics I hope to
discuss is a Forth library Action Group (FLAG).

The problem with ANS Forth is that it is incomplete. You either need a
system that comes with the extensions you need, or you need carnal
knowledge to implement these extensions - like C library access, which is
vital for any real project in a hosted environment. So the gunslingers
prefer to write their own system, because there they have the carnal
knowledge, and don't have to carry arbitrary baggage around

The downside is that you can't port that way, so library reuse doesn't
happen.

The other option is: Take a popular open source Forth system where you can
get into fast enough (usually problematic; either it is complex, but
provides most of the features required, or it is simple, but lacking
features), and where you can become part of the team, so that it is both
*your* Forth *and* widely used. But you still have to carry the baggage of
this system around, because it's not tailored to your needs.

It's not an Open Source issue, it's an issue of having the source
code, which is available for most of our products, including VFX Forth
and the cross compilers. We'll happily incorporate well thought out
extensions, but unlike the gunslingers, we will not break existing
code.

Guess what: You'll never be called to rescue left-overs of a properly
managed project. What you see is self-selected. When you offer help, you
will be called by people who need help, not by those who can help
themselves.

That's not always true. Many of our customers want to be tool users
rather than tool makers. We deliberately do applications so that we
have to "eat our own dog food".

You need a dung beetle mentality for job satisfaction: the heap
of *** is your meal. But in reality, Stephen, you have the same gunslinger
mentality as we all, so you are grumpy ;-).

No, no, no. I don't want a heap of ... I want a clean system.
Unfortunately the real world isn't clean. These days MPE spends
far more time implementing libraries outside the kernel than time
spent modifying Forth kernels.

Stephen


--
Stephen Pelc, stephenXXX@xxxxxxxxxxxx
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
.

Quantcast