NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/4038

Text File | 1993-01-28 | 10.2 KB | 212 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!ukma!netsys!decwrl!csus.edu!netcom.com!hamish
From: [e-mail] (Just Another Deckchair on the Titanic)
Subject: Re: Forth and Adaptation
Message-ID: <[e-mail]>
Organization: Pandemonia PLC
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jan 1993 02:51:15 GMT
Lines: 201

In article <[e-mail]> [e-mail] (Kevin Haddock) writes:
>In article <[e-mail]> [e-mail] (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?

So Forth can't stand on its own merits?

>> 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?)

Yes - and what proportion of each of those companies' products are
written using Forth?

<>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?

Little except that your point about all those companies using Forth
also, of course, holds for Smalltalk. You seem to have almost no idea
about Smalltalk and its potential - you sound like the sort of person
who knocked Forth a decade ago. My company, like many others, uses
Smalltalk extensively - we just don't make a big thing about it. My
company lives or dies by performance, memory usage, and portability.
That's *why* we use Smalltalk and not Forth.  Oh, and we're not talking
toy applications here...

<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.

Indeed. But all these comments are, in my experience,
language-independant. Since we need to "replicate that application many
times over", we use portable, *standardized*, languages like C or C++.
Once again, real-world performance is rarely much to do with langauge
issues, and often more to do with algorithms, I/O models, and
suchlike.

>>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.

A good description of the original aims of Unix, BTW. Again, you're
saying nothing, nothing at all, about anything other than Forth - your
comments on the advantages of Forth hold for many of the langauges I
use. On the other hand, you seem to have missed the point by a wide
margin - in the Real World (tm), the ability to work with
vendor-supplied tools is a life or death issue commercially. You
typically get little choice. Langauge adaptability, per se, is only a
small part of it.

>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.

That's true. Success in the Real World, though, goes largely to those
who are on the *customer's* side.

>>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).

This is the crux of the matter - I'm simply pointing out that even an
old Forth bigot like myself can't justify using Forth for "obvious"
applications when we can *not* use what the vendor has supplied (at
least not in any standard way). IMO, and in my experience, very few
vendor supplied packages turn out to be "trojan horse"; they are
usually an absolutely essential part of getting the job done.  Usually,
using these facilities is simply not negotiable. The customer calls the
tunes....

>>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.

So do we - that's why we use Smalltalk (seriously). Look, there's
infintely more to real world performance in many applications than pure
language "efficiency", whatever that means.

>If I have
>enough performance I can write simpler programs and I don't need
>so much interoperability.

I'm afraid I can't make sense of this at all - are you saying that
interoperability is something that gets traded for performance?
Interoperability is simply an absolutely essential requirement for
many large real-world applications. It's not something you get to pick
or chose - if your client wrote something in (god help us) Ada, and
that client wishes us to use that application, then interoperability
isn't a tradeable option.

>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.

Sure - sometimes. Often it's also a matter of how you got there - and
other things way beyond your control. To reduce it to the above is,
IMO, naive.

>Special purpose simple tools provide that.  General purpose
>complex tools do not.

Indeed. But Forth isn't the only option here. Your description sounds
a lot like Unix and C....

>>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.

To you, maybe. Frankly, "compression" (did you mean terseness?) has
little do with what I was saying, but even here, IMO, it's a red
herring. Terseness is not an issue, one way or another; neither,
within an order of magnitude, is code size - with a good code
management system, it's not an issue to us (but compiled object size
is). To say that terseness negates the need for good source code
control systems, etc, is to say that large applications development,
with large numbers of programmers, thousands of files, etc. is
irrelevant. I somehow doubt it....

>>*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.

"Torpedo"? Is Forth that sinkable? That much of an easy target? Oh,
and yes, the word "hack" stands out like a sore thumb there (but you
might not understand why, given the tone of your reply).

    Hamish
-------------------------------------------------
Hamish Reid   [phone]   [e-mail]