From: fish@ecst.csuchico.edu (Kevin Haddock)
Newsgroups: comp.lang.forth
Subject: Re: Forth and Adaptation
Date: 28 Jan 93 21:01:31 GMT
Organization: California State University, Chico
NNTP-Posting-Host: cscihp.ecst.csuchico.edu

In article <28370@sybase.sybase.com> hamish@sybase.com (Just Another Deckchair on the Titanic) writes:
>[my stuff deleted]
>
>So why *hasn't* Forth adapted? Why *don't* we see armies of Forth
>programmers out here in the Real World (tm)?

Well, as if I didn't already answer that question with my previous post
(which you quoted) how about these 3 letters:  A.T.T.?  Is that
a good enough reason?

> Why doesn't a company like
>(e.g.) Sybase use Forth in applications that would seem to be ideal for
>Forth?

Is Sun a real enough company for you? What about Federal Express?
How many others are using Forth and not fessing up to it?  I've
heard Apple has used it for some of thier internal projects (maybe
it's hiding in some of thier roms like Sun?)  

>What makes something a "fundamental 'real-world' application"?
>And why are so many of them being written in something like Smalltalk
>(the Forth for the nineties...) rather than Forth?
Smalltalk?!?  How about the multi-megabyte overhead of Smalltalk?
How about it's inefficiency?  I'll agree that with specialized hardware
Smalltalk might be an attractive option for low production applications
and/or exploratory (prototype) work.  I think you are talking apples
and oranges here.  With an OO and GUI layer Forth could do what
Smalltalk can do (although you wouldn't necessarily be forced to
use it).  Can you say the opposite is true?  Forth is a FULL BANDWIDTH
language.  You can run while you compile, you can extend it into
any other language (even a user level lexicon) easily.  You can
assemble, inline code, interpret, macro, etc.... What more is there
to say?

What makes something a fundamental real-world application in my book
is something that has to get the job done in the real-world with
a minimum amount of monkey motion, both on the computer's and the
programmer's part.  This means not having many megabytes of useless
overhead and wasted clock cycles.  In most applications it is
cheaper just to throw a lot of hardware and 'tools' at the
problem.  But what happens when you want to replicate that application
many times over, or when that application pushes the envelope of what
hard/software is able to do?  It is then that the everything and the
kitchen sink approach falls apart.  The only snag is that less hardware
is cheaper and more reliable (not as much to break down).  Less software
is easier to support and allows simpler, more reliable programs.
>
>There's more to adaptation than just having a nifty *language*. It's
>not language adaptability that's all important - rather, it's the
>adaptability of things (applications, modules, etc) built in that
>language that's important, and the adaptability of the programming
>tools and environment.

I disagree wholeheartedly.  I just finished a stint with a language/
environment that 'integrated' everything you needed.  The whole
time I was wishing I could use a minimalist Forth.  Believe me,
the language's adaptability is ALL IMPORTANT!  That is the WHOLE
FORTH CONCEPT.  A small set of really tight tools that fit
together easily rather than a bunch of loose tools stuck together
with chewing gum and bailing wire.  This project was
a nightmare because of all the 'vendors' whose binary layers did
nothing but get in the way.  They did more work on neophyte user
interface and protecting thier asses than they did on helping me
get my job done.  A good vendor that focuses on providing a tight
system with a lot of attention on performance and iterative
loop and one who provides SOURCE CODE is on the programmers side.
These people are providing value for value.  They give you what
it takes to deliver to the customer.  Those who don't provide
the above are just exploiting the programmer by fooling him that
he may actually be able to do the job which is usually not the case.

>
>Even more important is the ability to let the vendors do as much of
>your work as possible - why reinvent the wheel? If a system supplies a
>set of networking and (say) windowing functions as a C library or C++
>or Smalltalk class hierarchy, you should just plug into these for the
>services (and generally can in any of the languages I work with).

I don't disagree with letting the vendors do most of the work.  I just
question thier ability to be able to debug every line of code that
I might want to use.  I appreciate thier contribution unless it turns
out to be a trojan horse (which is usually the case w/o source).

> 
>Similarly, interoperability is a huge issue - if I can't work in all
>three of the languages together on the same (large) application or
>suite of applications, then I'm screwed.

I still think performance is still the biggest issue.  If I have
enough performance I can write simpler programs and I don't need
so much interoperability.  I can use direct files instead of b+trees.
I can do brute force lookups instead of 'linear hashes', etc...
Performance is the art to which function can aspire.  Performance,
in the run-time, compile-time, and iterative loop is what counts.
Special purpose simple tools provide that.  General purpose
complex tools do not.
>
>Similarly, if I can't easily use the system-supplied tools on my source
>code, then it's not even worth considering the language. The recent
>screens vs. files argument was classic - if a Forth source can't be
>made to look exactly like a normal text file to my tools (grep, SCCS,
>RCS, Envy, etc. etc. ad nauseam), then it's lierally worthless.
Unix was invented to provide the adequate text processing for languages
with complex syntax and which did not compress well.  C provides some
level of compression (cpp, functions, terse operators, etc...) but not
to the level that Forth does.  I think that what I was trying to say
was that this 'compression' negates the need for most of the tools
you mentioned.  You are welcome to your opinion and I'd hope I'm
welcome to mine.  I personally try to make my code turn out looking like
state tables and charts so maintenance is not a real problem.
>
>*Those* are the sort of things that are important in this little
>corner of the Real World (tm), where, frankly, even though I was once
>a Forth evangelist, I wouldn't even consider it for serious work
>now....
So now you just come around to torpedo the rest of us?  Sounds like
you couldn't hack it to me.

-Kevin
fish@cscihp.ecst.csuchico.edu

-------
There are no complex problems; only complex solutions!
-------
Bureaucracy:  The process of turning energy into solid waste.