From: hamish@sybase.com (Just Another Deckchair on the Titanic)
Newsgroups: comp.lang.forth
Subject: Re: Sampler Forth
Date: 13 Sep 92 23:13:42 GMT
Organization: Sybase Inc, Emeryville CA USA

In article <1992Sep10.142241.11172@exu.ericsson.se> exuhag@exu.ericsson.se 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
+1 510 596-3917   hamish@netcom.com  hamish@sybase.com  uunet!sybase!hamish