Hang on, isn't Forth out of date now? 
Author Message
 Hang on, isn't Forth out of date now?

Sorry for the outrageous subject line, but I wanted your attention, and
I am serious about this.

In the old days Forth was great because of the following benefits:
1. It was simple to build from the bottom up.
2. You could get a compiler to run in a minuscule amount of ram.
3. You could try things out in real time as you built your system.
4. Compared to interpreted basic, it ran really fast.

However, the beauty of Forth was that it made the best out of a slow
microprocessor with little ram. I wrote my own version of forth for the
PC (I was unaware of freeware ones at the time) and admired the elegant
simplicity of the system. But now it looks a little silly nestling
snugly in less than one cluster on my 1.25Gb hard disk and only able to
access 64kb of my 16Mb pentium.

It seems that I get the benefits I need from the Borland C++ compiler. I
don't need to build it myself because it does everything I want. The
fact that it gobbles ram is no disadvantage because I've got tons.
Things compile so fast that I can try every subroutine before I use it
if I want. (The days of going to make a cup of coffee every time you set
a compilation going are long gone!) The Borland compiler has a "Watch"
window to make debugging a cinch, and huge libraries of built in
functions which only get linked into your program if you use them. And
I'd be very surprised if compiled code ran slower than threaded.

I work for a company that makes electronics for cars, and I thought I
saw a niche for Forth on the microcontrollers that we use there, but
when you have a "C" compiler running on a PC connected to it, and an
emulator for real-time target-running debugging, I can't justify it,
much as I would like to.

So there you are- I've got an open mind; persuade me that Forth is still
relevant on todays computers now that the old constraints have gone.

By the way, some of these new words you're all talking about draw a
blank with me- what are POSTPONE and CELL+ ? What I really need is an
alphabetical list of the ANS Forth words, and a definition of what they
do so that I can "update" my own version.

Oh, and "No" Elizabeth, I don't have a "budget". Being able to write it
myself was one of the good things about Forth that I still hang on to!
--
Andy Civil



Sun, 24 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?



Quote:
> I work for a company that makes electronics for cars, and I thought I
> saw a niche for Forth on the microcontrollers that we use there, but
> when you have a "C" compiler running on a PC connected to it, and an
> emulator for real-time target-running debugging, I can't justify it,
> much as I would like to.
...
> Oh, and "No" Elizabeth, I don't have a "budget". Being able to write it
> myself was one of the good things about Forth that I still hang on to!

Sorry, but "electronics for cars" and "no budget" does not compute.
In any practical industrial environment, the cost of the software
development tools is lost in the noise compared to the cost of the
engineers. Productivity is the name of the game, and writing it yourself
is not a good economic argument.

For details of the ANS specs, look on taygeta.com, and for details of
current commercial Forth cross compilers send me your postal address
to one of the addresses below.
--

MicroProcessor Engineering - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 1703 631441, fax: +44 1703 339691



Sun, 24 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

[various deleted]

Quote:
> So there you are- I've got an open mind; persuade me that Forth is still
> relevant on todays computers now that the old constraints have gone.

If you are comfortable with C, then by all means use it.  I personally
prefer to solve problems in Forth.  I have found it easier to solve
problems in embeded system with Forth than with other languages that
don't provide good debugging environments.  Today, C compilers for
embeded environments are getting better, and I suppose some provide
perhaps even good de{*filter*}s.

I believe these choices very often come down to the preferences of the
engineer that will be doing the job.  If you happen to work for a
company that wants (needs) to get things done quickly, then the engineer
will often have wide latitude to make the choices he or she wants, as
long as the project gets done on time.  If you work for a company
that has lots of time (I don't think there are many of these any more)
to paln and implement projects, and has decided to dictate that the
language for their software will be C, then by all means go work for
another company.  This may seem foolish, but when a company has lots of
time to dictate how their software will be written, and in what
language, then you become a cog in a slow inefficient machine.  
Of course we are all cogs in some kind of machine, but I would rather
be a cog in a sleek fast moving machine, rather than a big slow plodding
dictatorial machine.  

I know I'm getting on a silly soap box here, but for me, personal job
satisfaction translates directly into efficiency.  Forth makes me
efficient because it works the way I think, backwards.

Don't take my above comments too seriously, but I think it is always
useful to remind people of the value of a programmer, and the importance
of allowing them to make decisions. (I know I'm preaching to the choir)

Quote:
> By the way, some of these new words you're all talking about draw a
> blank with me- what are POSTPONE and CELL+ ? What I really need is an
> alphabetical list of the ANS Forth words, and a definition of what they
> do so that I can "update" my own version.

Here is alink that will provide you with more current information on
Forth than you can shack a C compiler at.

http://www.*-*-*.com/

Tom Zimmer



Sun, 24 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

Quote:

> ...However, the beauty of Forth was that it made the best out of a slow
> microprocessor with little ram. I wrote my own version of forth for the
> PC (I was unaware of freeware ones at the time) and admired the elegant
> simplicity of the system. But now it looks a little silly nestling
> snugly in less than one cluster on my 1.25Gb hard disk and only able to
> access 64kb of my 16Mb pentium.

> It seems that I get the benefits I need from the Borland C++ compiler. I
> don't need to build it myself because it does everything I want. The
> fact that it gobbles ram is no disadvantage because I've got tons.
> Things compile so fast that I can try every subroutine before I use it
> if I want. (The days of going to make a cup of coffee every time you set
> a compilation going are long gone!) The Borland compiler has a "Watch"
> window to make debugging a cinch, and huge libraries of built in
> functions which only get linked into your program if you use them. And
> I'd be very surprised if compiled code ran slower than threaded.

Your view of Forth is what's out of date.  Comparing a homebrew Forth written
many years ago with today's C compilers is inappropriate.  Take a look at
today's commercial Forth compilers -- they are usually fast 32-bit
implementations, with lots of libraries and add-ons, extensive documentation,
and lots better hot-line support than Borland provides!

Quote:
> I work for a company that makes electronics for cars, and I thought I
> saw a niche for Forth on the microcontrollers that we use there, but
> when you have a "C" compiler running on a PC connected to it, and an
> emulator for real-time target-running debugging, I can't justify it,
> much as I would like to.

We have several customers using our chipFORTH cross-development system for
embedded applications such as you describe.  It provides full interactivity
with your target without requiring an expensive emulator, and is lots easier
to use!

Quote:
> Oh, and "No" Elizabeth, I don't have a "budget". Being able to write it
> myself was one of the good things about Forth that I still hang on to!

What did you buy your Borland C++ and emulator with if you have no budget?  

And aren't you contradicting yourself a little, here, saying that what you like
about Forth is that you can write limited-function versions yourself for free,
but that you like C++ much better because you can get so much more functionality
for your money?

Check out the references other folks have given you to catch up on ANS Forth,
and check our web site for info on some recent professional Forth projects.

--
Elizabeth D. Rather
FORTH, Inc.                 Products and services for
111 N. Sepulveda Blvd.      professional Forth programmers
Manhattan Beach, CA  90266  since 1973.  See us at:
310-372-8493/fax 318-7130   http://www.forth.com



Sun, 24 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

Quote:


>> Oh, and "No" Elizabeth, I don't have a "budget". Being able to write it
>> myself was one of the good things about Forth that I still hang on to!
>What did you buy your Borland C++ and emulator with if you have no budget?  

;-)
Well, I did not check the most recent prices but a Borlang C++ (or anything
from Borland for that matter) with all those goodies used to be god damn
CHEAP.

Not to mention the fact that because half of the PC programmers use Borland
tools, you are very likely to have a chance to take a look at them
somewhere before you buy them.

Where can I see your Forth tools at work before I actually pay a single
cent for them?

Andras



Mon, 25 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

: I believe these choices very often come down to the preferences of the
: engineer that will be doing the job.  

In a single-engineer company this is true.  Once the company gets above
that size, however, decisions are as much dependent on what the customer
wants and what the competition provides as they are on the preferences
of any individual team member.  This is why Forth, Inc. is a successful
Forth enterprise in a "C" of mediocrity (I just *couldn't* resist :-).
And this is also why my employer does not (knowingly) have a single line
of Forth in its major product line and why my desk is a Forth-free
zone.

I've been through this with Julian Noble and others before, but I'll
repeat it -- I do *not* believe that Forth is inherently more productive
by an order of magnitude over other programming environments if you
assume equal knowledge of the application area and equal experience
levels in the programming environment.  Because I write most of my code
in Perl these days, I can bang out code in application areas other than
the one I work in faster in Perl than I can in Forth.

Where Forth *is* inherently more productive is in bringing sanity to
microcontrollers, microcomputers and minicomputers.  In my case, this is
the HP100LX Palmtop PC.  Perl is hopelessly slow and hopelessly wasteful
of memory for many of the things I want to do in this machine, an 8 MHz
80186.  In a 32 KByte executable, I have a complete programming
language, assembler, linker, compiler, interpreter, de{*filter*}, etc.
I'm sure I could find a "C" compiler that fit some of these constraints,
and it might even be compact enough to reside in the palmtop rather than
on a large Windows system (which I don't have :-).  But I haven't yet
found one that even comes close to hForth or Pygmy.

--

Which one of "The Simpsons" is O.J.?



Mon, 25 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

Quote:

>However, the beauty of Forth was that it made the best out of a slow
>microprocessor with little ram.

It still makes the best out of processors. My experience with Acorn's
ARM is that FORTH makes very much out of it. Nice and fast and it hasn't
crashed once in two years. Compare that with a popular PC "operating
system" known to us all...

Even using indirect-threaded code, the jump from the end of one
subroutine (word) to the start of the next takes fewer machine
cycles than are required for a call and return. So threaded code
speed is easily comparable with subroutines as compiled by a C compiler.

Quote:
>[...] and only able to access 64kb of my 16Mb pentium.

That is the way you wrote it!     FORTH is not intrinsically
limited to 16 bits. Just make everything 32 bits, including the
stack, and you'll be able to access your entire address space.

Quote:
>The
>fact that it gobbles ram is no disadvantage because I've got tons.

It's a question of efficiency. I could do more with
16Mb with an efficient system than I could with a RAM-gobbler.

Quote:
>Things compile so fast that I can try every subroutine before I use it
>if I want.

What about the programmer time of writing the routine which
supplies input conditions and then calls your subroutine? You
don't need to do this in FORTH; all words (subroutines) are
accessible all the time.

CELL is defined as the number of bytes taken up by an address. So
on a 16-bit system, CELL is 2. (Z80, 6502, 6809, etc.) this is
also the number of bytes needed for a stack item.
On a 32-bit system, CELL is 4. (68000, etc.)
If you write a 32-bit system for your Pentium, then you'll use a
CELL of 4.

2 CONSTANT CELL     or    4 CONSTANT CELL

you could     : CELL+   ( n-n) CELL + ;
but it really ought to be defined in machine code for speed.
Similarly CELL* ( sometimes known as CELLS) and CELL/
for doing left-shifts and right-shifts.

Those definitions make a lot of code machine-independent. Using
the above, you can make (for example) a Z80 and a 68000 run the same
source code.



Mon, 25 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

I would like to thank *ALL* of you for your responses I have six so far;
it is going to take a while to consider all of them. I may post again...

In particular:


Quote:

>What did you buy your Borland C++ and emulator with if you have no budget?  

>And aren't you contradicting yourself a little, here, saying that what you like
>about Forth is that you can write limited-function versions yourself for free,
>but that you like C++ much better because you can get so much more functionality
>for your money?

You are quite correct, and I am guilty of this. I was confusing three
scenarios (home, work-PC, work-embedded) for simplicity. The
manufacturer of the microcontroller provides the emulator and compiler
(not Borland!) for free because we buy so much, so I forget that they
cost money.

Work has a copy of Borland C++ 4.5 for writing tools for PC's. It must
have been paid for at some time.

And yes, there may be Integrated Development Environments which are as
easy to use and as quick as the Borland one, but for Forth. Sadly, I
will never see one, because the use of "C" is written into our standards
at work, and I can't justify buying one for home when I have free access
to a "C" compiler.
--
Andy Civil



Mon, 25 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

   Even using indirect-threaded code [ on an ARM ], the jump from the end of one
   subroutine (word) to the start of the next takes fewer machine
   cycles than are required for a call and return. So threaded code
   speed is easily comparable with subroutines as compiled by a C compiler.

Interesting.  Could you post the ARM instructions for a typical
call/return as compiled by a C compiler and the sequence of
instructions that implements the jump as the end of one word in the
Forth implementation.



Tue, 26 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

Quote:

> Where can I see your Forth tools at work before I actually pay a single
> cent for them?

1. Any Rochester Forth Conference.  This is in fact how I wound up using
the MPE Forth compiler; Stephen Pelc gave me very nice demo of his
product.  (I was already familiar with the Forth Inc. product, and MPE's
was a better fit to my needs.)  I suspect you could get a demo at
EuroForth as well.

2. Ask a user.  I've demonstrated the MPE compiler to a few local
associates.  (Also at a SIGForth conference, as I recall.)

3. Visit the vendor.  A bit difficult for you, I admit, but we do see
lots of queries from California (Forth Inc.) and the U.K. (MPE).

#1 is the best option because you get the chance to see and compare
different systems at one place.
--

This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html
Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj
Director, Forth Interest Group........... http://www.forth.org/fig.html



Tue, 26 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

|> But now it looks a little silly nestling
|> snugly in less than one cluster on my 1.25Gb hard disk and only able to
|> access 64kb of my 16Mb pentium.

Then use a different one. The one I use, Gforth, lets me access 4GB of
address space on my Pentium and 16777216 TB on the Alpha I'm using (Of
course, both machines do not have enough physical memory and swap
space to fully support this capability of the Forth system).

|> By the way, some of these new words you're all talking about draw a
|> blank with me- what are POSTPONE and CELL+ ?

POSTPONE is a replacement for COMPILE and [COMPILE].

CELL+ ( addr1 -- addr2 ) is one opf the words that lets us perform
address arithmetic in a portable, cell-size independent way (if you
don't remember what a cell is: It's the basic data item of
Forth). CELL+ replaces some uses of 2+.

|> What I really need is an
|> alphabetical list of the ANS Forth words, and a definition of what they
|> do so that I can "update" my own version.

http://www.taygeta.com/forth/dpans.html

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Tue, 26 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?



Quote:
>Sorry for the outrageous subject line, but I wanted your attention, and
>I am serious about this.

We all enjoy good flame bait.  :-)  We haven't seen much of it
around here for quite a while.

Quote:
>In the old days Forth was great because of the following benefits:
>1. It was simple to build from the bottom up.
>2. You could get a compiler to run in a minuscule amount of ram.
>3. You could try things out in real time as you built your system.
>4. Compared to interpreted basic, it ran really fast.

>However, the beauty of Forth was that it made the best out of a slow
>microprocessor with little ram. I wrote my own version of forth for the

Yes, but the terms slow microprocessor and little ram are relative.
Whatever your resources it is small and slow in some comparison.
And software bloat has in many cases expanded faster than hardware, so
even though my PC is more than 100 times faster on benchmarks
than the one I used a few years ago many things take much longer now
than they did then (if I use conventional programs).

Quote:
>PC (I was unaware of freeware ones at the time) and admired the elegant
>simplicity of the system. But now it looks a little silly nestling
>snugly in less than one cluster on my 1.25Gb hard disk and only able to
>access 64kb of my 16Mb pentium.

>It seems that I get the benefits I need from the Borland C++ compiler. I
>don't need to build it myself because it does everything I want. The
>fact that it gobbles ram is no disadvantage because I've got tons.
>Things compile so fast that I can try every subroutine before I use it
>if I want. (The days of going to make a cup of coffee every time you set
>a compilation going are long gone!) The Borland compiler has a "Watch"
>window to make debugging a cinch, and huge libraries of built in
>functions which only get linked into your program if you use them. And
>I'd be very surprised if compiled code ran slower than threaded.

Sounds like the Borland C++ compiler may be a good match for what
you are doing.  It has many useful tools for development as you
point out.  But only comparing in to threaded forth code is like only
comparing with interpretted basic,  Why not compare its code
with inlined optimized native code generated by a Forth compiler?
Or perhaps as his been pointed out your ideas of Forth are out of
date.

Quote:
>I work for a company that makes electronics for cars, and I thought I
>saw a niche for Forth on the microcontrollers that we use there, but
>when you have a "C" compiler running on a PC connected to it, and an
>emulator for real-time target-running debugging, I can't justify it,
>much as I would like to.

Well we hear of many examples of people doing things with Forth
compilers that let them do things on their microcontrollers that
end up being smaller and faster than assembler let alone C++ code.
Of course they are usually not using twenty year old Forth compilers,
maybe you should compare to a twenty year old C++ compiler.  :-)

Quote:
>So there you are- I've got an open mind; persuade me that Forth is still
>relevant on todays computers now that the old constraints have gone.

Since 98% of the computers out their are embedded computer it seems
to me that efficient code and efficient use of memory are still
very very important things in the real world, as is development
productivity.  But if you are mass producing a product, as you
are with embedded systems, then minimizing the cost of the
hardware is more important than software development cost.

We all hear about conversions of software from conventional PC
development tools to minimal hardware with embedded Forth
applications and their sucess stories.

But in the computer industry developers often think that their
status is reflected by the cost of their development environment
and then somehow want to apply their elitist attitude to the  
work they are doing.  "My company pays for a workstation with
all the horsepower and memory we could get, so code and memory
efficiency are no longer issues for me."

We all know of cases where Forth permitted development to occur
ten times faster, or made the code ten time smaller, etc.  But
I alway enjoy seeing the cases where people get 100 to 1000
times improvement in memory use or speed and say they could
never have figured out how to do that if they had not been
using (thinking) Forth.

A couple of years ago there were a lot of threads in comp.arch.embedded
by people who were saying "I do embedded development using ... and
let me tell you that a 66mhz 486 is only capable of doing 2000
empty loops a second, or responding to an interrupt in 500ms or more."
But they love their tools...

I do embedded development and in the last couple of years when I
set out to design a routine for interrupt processing or task switching
my go is usually try to get them under 100ns.

I eventually just came to the conclusion that I was indeed living
in a very different world than the people who love their conventional
development tools.  I encouraged other Forth programmers to post
there and soft of backed out of that newgroup after getting them to
update their faqs with regard to Forth.

The real trick is to know when Forth will be a better choice, AND
being able to get away with using it despite the enormous pressure
often generated by management.  Often management is making such
decisions based on industry hype and stories about Forth from
twenty years ago. At iTV or Ultra Technology this is not a problem.

In short much of Forth's reputation is based on out of date information.
(and some of it is well deserved. :-)

Jeff Fox



Tue, 26 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?


*SNIP*
: Work has a copy of Borland C++ 4.5 for writing tools for PC's. It must
: have been paid for at some time.

: And yes, there may be Integrated Development Environments which are as
: easy to use and as quick as the Borland one, but for Forth. Sadly, I
: will never see one, because the use of "C" is written into our standards
: at work, and I can't justify buying one for home when I have free access
: to a "C" compiler.
: --
: Andy Civil

I've personally compared Borland's C++ IDE with MPE's ProForth for
Windows.  In My Humble Opinion, Forth was far easier to work with.

It took me weeks to get used to the Borland product, and I used it
everyday for months at a time.  I was comfortable with the Forth IDE in
about 1/2 hour.  Obviously, this is a 'taste' concern, but having an
interpretive feedback loop _within_ Windows, _while_ developing makes my
job much easier.

As for cost: the last junk-mail I got from Borland quoted a price of $800
Canadian, WITHOUT printed docs.  Of course, I would never consider paying
this on my budget; I paid the 'student' rate (~$70) on an 'outdated' version.

It makes me wonder what the 'real' price is.

BTW, you should see all the bug reports in the Borland newsgroups... ;>

--




Tue, 26 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?


Quote:
>Interesting.  Could you post the ARM instructions for a typical
>call/return as compiled by a C compiler and the sequence of
>instructions that implements the jump as the end of one word in the
>Forth implementation.

This is how I'd do it in machine-code. Hopefully C is this efficient.

     BL   subroutine       Branch and Link, which means
                           jump and save return address in R14. This
                           doesn't involve a stack.

somewhere in subroutine
     MOV  PC,R14           Move register 14 to the PC
                           which jumps back to where you came from

Somewhere you'll also have to push R14 onto the stack. The official Acorn
standard is that the caller does it, rather than the callee. If the caller
does it, it needs only be done once, as a set up for many BLs to follow.
If the callee does it, every single BL must push R14 onto the stack
at the start of the subroutine. The "return" instruction then must
get the PC from the stack, rather than from R14:

     LDR PC,[S],#4    Get PC from stack; increment stack pointer after load.

or maybe, taking the same time in this case:

     LDMIA S,{PC}     Get PC from stack; Increment Afterwards the stack pointer
                      This may also LoaD Multiple registers from the stack.

S=whatever register you've chosen as the stack.

To choose whether or not to push R14 onto the stack, the C compiler
has to know how deep the nesting goes: all levels except the bottom one
need to push R14 onto the stack. Thus, the bottom level's return
instruction is the MOV PC,R14 . All other levels get the address off
the stack.

In ARM indirect threaded FORTH, the NEXT routine is two instructions:

     LDR  W,[I],#4    LoaD Register W from the place pointed to by I, then
                      increment I by 4. (32-bit address so 4 bytes)
     LDR  PC,[W],#4   LoaD Register PC .... so this is an indirect jump.

I and W are just registers chosen by the programmer. I've chosen I=R11
and W=R14 in my FORTH.
You'll notice these instructions are identical to the instruction to
get something off the stack.

Simon



Wed, 27 Jan 1999 03:00:00 GMT  
 Hang on, isn't Forth out of date now?

Andy, thanks for the provocative question.  It's helped me compose my
thoughts for a flyer I'm writing.

No, Forth isn't out of date.  Forth is still great because of the
following benefits:
1. It is simple to build from the bottom up.
2. You can get an _application_ to run in a miniscule amount of RAM.
3. You can try things out in real time as you build your system.
4. Compared to any other interpreted language, it is fast.

Allow me to elaborate:

1. Forth remains one of the few environments which is totally
comprehensible by one person.  This is a big plus when you're working in
safety-critical systems, or whenever you need to verify program
correctness.

2. Forth does indeed make "the best out of a slow microprocessor with
little RAM."  Such processors are more common than PCs -- they're called
embedded systems.  It will be a long time before your car's fuel-
injection system has 16 MB and a 1.25 GB hard disk.  (And most embedded
processors are NOT supported by Borland C++.)

3. There is simply NO substitute for an interactive interpreter when
debugging.  Even an edit-compile-test cycle of 5 seconds feels clumsy,
after you're used to testing any subroutine by typing its name.  Can
your de{*filter*} let you manually try different input parameters?  (My
Borland compiler can't.)  And you should try a modern interactive
Forth to learn how easy it makes testing embedded hardware!  I've yet to
meet the in-circuit emulator that lets me exercise I/O as easily as a
few simple lines of Forth code.  (Or lets me test multiprocessors or
distributed systems at all!)

4. Forth is still fast.  Modern compilers produce code as good as any
other language -- not all Forths use threaded code!  (I could relate a
horror story I heard about an engine control system written in C++.)
Forth is certainly the fastest interpretive language around; and besides
the debugging advantage, I've found interpretive Forth to be superior
for incremental development.

However, I have other reasons for using Forth:

5. Forth is _extensible_.  This means that if the language does not
support some feature or capability you need, you can add it...not as a
subroutine package, but as part of the language itself.  Can you imagine
writing object-oriented code, if every reference to an object had to be
through a function call?  That's how I feel about other languages'
implementations of multitasking, multiprocessing, and networking.  Only
in Forth can these be truly transparent.

6. Forth lets me work at a high level of _abstraction_.  Between
language extension and "active" data structures, when I write a Forth
application, I am really writing in the language of the application --
not the language of the compiler.  This makes the program easier for a
newcomer to read, and easier to maintain.

Like most programmers, my choice of language is based on personal
preference.  I find that I think more clearly in Forth, and from past
experience I estimate I'm 5 to 10 times more productive in Forth than in
C.  Others may not share this preference or facility.  Forth may not be
your preference, but it's certainly "relevant" -- now more than ever.

--

This brain for rent! See http://www.*-*-*.com/
Contributing Editor, The Computer Journal... http://www.*-*-*.com/ ~tcj
Director, Forth Interest Group........... http://www.*-*-*.com/



Wed, 27 Jan 1999 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Hang on, isn't Forth out of date?

2. Mac vs PC FLAME BAIT Par EXELENCE, was Re: Hang on, isn't Forth , out of date now?

3. Faster than assembler (Was: Hang on, isn't Forth out of date now?)

4. isn't there a Palm Pilot Forth

5. Why Forth isn't popular...

6. Why Forth isn't popular...

7. Why isn't Haskell mainstream?---A newbie's view

8. GNU Script isn't fixing something that's broken, so is doomed

9. COBOL isn't dead, but I'm learning C++

10. GNU Script isn't fixing something that's broken, so is doomed

11. GNU Script isn't fixing something that's broken, so is doomed

 

 
Powered by phpBB® Forum Software