NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/forth/3143

Internet Message Format | 1992-09-15 | 7.7 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!mtxinu!sybase!hamish
From: [e-mail] (Just Another Deckchair on the Titanic)
Newsgroups: comp.lang.forth
Subject: Re: Sampler Forth
Message-ID: <[e-mail]>
Date: 13 Sep 92 23:13:42 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Sybase Inc, Emeryville CA USA
Lines: 163

In article <[e-mail]> [e-mail] writes:
>Excellent post, Alan, which hit the nail right on the head.
>
>I agree that most Forth implementations are severely misguided.
>(I am not talking about Forths for embedded use here, but Forth
>as a general purpose programming language.)  I'm of the "Forth
>should be small and understandable" school, but this doesn't
>mean that a Forth system has to be as rickety as the Apple II
>ML monitor.

    [Rest of James's points deleted]

I'm a long-time lurker in this group, and I've watched the postings
about Forth and its status in the world of general purpose programming
go by for a long while without commenting. I used to use Forth way back
in the good old days (a decade or more ago, I can't remember...), and
I've got to admit I'm bemused by the thought that it could ever be
pushed as a "general purpose" language. It's great for specific
applications in a limited mileu (we used it as a meta-machine
language), but in general? I can't see it, I'm afraid, for a variety
of language and implementation reasons.

Let's look at this from my point of view (as a software designer and
implementer working as part of a large team), and from the top down
(i.e. from the team leader or company level rather than the individual
programmer's). I help develop kernel-level software for a large group;
the sort of things programmed actually amount to virtual database
machines, with lots of tasking, I/O,  a bit of math, etc. A nice place
for Forth, you might think?  No.

We use C, or C++ and would never seriously contemplate Forth. What do
we look for in a programming language?  Not usually "speed" (in the
first instance anyway), not usually things like the behaviour of
language-specific editors, not whether a specific implementation does
or does not offer a particular extension; we're more concerned with
more abstract things like:

* Is the language (relatively) well standardized?

    This is a good indicator of portability and overall language
    implementation reliability - something *really* important to
    us in general. We would not consider a language that has a lot
    of widely-differing implementations of the core language.

    Note that "standardized" doesn't necesarily mean by (say) ISO
    or Ansi - it really just means that the variations between
    different implementations are small (in context) and
    well-understood and documented.

* Is it widely available and supported on all the likely target systems?

    A language that is not available on all our target platforms
    will simply not be considered; similarly, unless full
    commercial-level support is part of the package, we're highly
    unlikely to use it. "Support" here means being able to phone
    the vendor with specific questions and requests and to know
    that the answers will be both reasonable and useful, and that
    if we are in trouble due to the vendor's implementation, we can
    expect timely help. This is simply crucial for most software
    products in the real world - compiler experts cost money we'd
    rather spend somewhere else - compilers are our *tools*, not
    our products.

    (We're talking systems ranging from VMS throught the various
    Unices through Windows/NT through Mach etc, in UP and MP
    versions, on a variety of hardware types, etc. here).

* Is it widely known and understood?

    This makes our job a lot easier - we don't need to explain C
    (or, increasingly, C++) to new hires. C is (relatively)
    standardized - we do not need to explain particular
    implementations to newcomers; they can start on day 1.

* Is it "open" in the sense that it can use or be used by
  other language modules and/or libraries, etc, on all target
  systems?

    This is simply crucial. For most applications we would never
    seriously consider a language that did not allow us to (say)
    call the already existing extensive C libraries in a simple,
    straightforward, hopefully portable manner. Similarly, any
    language must be able to produce these libraries - software
    must be reusable on the target systems, in the format and
    manner supported by those systems.

    This also implies that the languages have enough *standard*
    concepts in common that this is easy - any language had better
    standardly understand C-like structures on the host system, for
    example.

    This isn't really one of Forth's strong points....

* Can it allow us to simply use all the host system facilities
  (esp. system calls)?

    Any language that didn't allow us to use all available host
    system calls, *and that did not have documentation for using
    these facilities from within that language as a standard part
    of the language*, would not be seriously considered.

    The system, including all file, signal, socket (etc), window,
    process, task, internationalization, etc, facilities is there
    to be used, not reinvented. The proposed language must
    understand the host system conceptual blocks (structures, for
    example), in a standardized manner, and have a well-defined,
    supported, fully-implemented and easily-used interface to these
    facilities - and preferably one that doesn't change from system
    to system.

    This does not, of course, apply just to system calls - *any*
    system facility (math, windowing, error-logging, etc) must be
    visible and easily usable (implying well-documented), at least
    as easy to use as a C library call.

    Again, this isn't really one of Forth's strong points....

* Is the language reasonably "safe"?

    This is pretty important (though this isn't exactly C's
    greatest strength...) - if the language itself isn't
    particularly safe (e.g. allows aliasing, random pointer
    arithmetic, etc) then does the support environment give us
    tools to analyse and/or enforce code safety? Can we enforce
    (say) bounds checking, or floating point arithmetic error
    checking?

    Bugs from unsafe code are catastrophically more important (and
    more common...) commercially than performance problems caused
    by a slightly slower language implementation.

* Does it support our design methodologies and programming models?

    This is pretty important - it's the design that matters, and if
    someone's just produced a nice object-oriented server kernel
    design, it's a lot easier to implement it in an appropriately
    (and standardized...) OO language than it would be in a
    language whose paradigm is not at all OO or has had OO tacked
    on to the top of it (shame about C++, really...).

* Can it be used to produce standalone applications?

    This is pretty obvious - can I make a host system application
    that can be called from (say) a Unix shell without a
    specialized environment? Without any specialized calling
    procedure? Etc....

* What environments (debuggers, profilers, etc) are available for it?

* ...etc.

Remember, most general programming is done in teams, and most software
projects are more concerned about specification, design, testability,
etc, than the actual programming language and programming itself.

C is hardly brilliant at this, but it says volumes that a Forth hacker
like myself, working in a software domain that seems ideally suited to
Forth programming, would never seriously consider Forth for the task.

    Hamish
---------------------------------------------------------------------------
Hamish Reid       Sybase Inc, 6475 Christie Ave, Emeryville CA 94608 USA
[phone]   [e-mail]  [e-mail]  uunet!sybase!hamish