Re: Why forth is not popular

"The Beez'" <hansoft@xxxxxxxxxxx> writes:
>2) The lack of a standard (1980-1990).

There was Forth-79 and Forth-83, as well as the de-facto standard
fig-Forth.

> My $40 "Starting Forth" helped
>me very little with my Artic Forth compiler.

Tough luck. Looks like you were seriously bitten by Arctic Forth
(Frostbite:-). Why did you shell out $40 for it if it was so bad?

But anyway, I don't think that has much to do with the answer to the
question.

>3) The lack of books. Nowadays, we have a standard, but there are no
>easily available books anymore. I can't find none in a Technical
>University City with many good bookstores.

Hey, Michael, stop posting in Hans' name!

> And the books that ARE
>available (usually from the internet) are IMHO as a licensed teacher
>lacking from a didactical standpoint.

In that case, maybe you should help improve them. I believe that
current crop of books are better on average than the books in the 80s.

>4) Forth is unforgiving. One error, segfault, and you have to start all
>over again.

Not sure what you mean by that. Is it that youyr Forth system is
unforgiving?

Mine converts segfaults and other signals into Forth exceptions that
the application can catch; if the application does not catch it, then
the system catches it and reports the exception with lots of
additional information, including a backtrace, and leaves you where
you started from (either the Forth command line or the OS command
line). What else do you want?

> That is true for many low level compilers, of course, but
>Forths architecture makes it particularly hard.

Well, looking at higher-level languages (I assume you mean languages,
not compilers), the Lisp systems I have experienced do pretty much the
same as my Forth system, whereas in Prolog errors often result in an
uninformative "No."; ghostscript produces a dump of its stacks, which
is sometimes helpful.

>5) Forth is alien to people used to a modern IDE. I don't like to write
>Forth code a word at a time, like most programmers. I write my program
>and debug it.

Yes. So do I.

> Executing MARKERs is not my idea of fun.

Neither is it mine.

> People want to
>catch the error, change their code and run the thing all over again.

That's the way I work with Forth. Gforth is tuned for doing this kind
of stuff:

% gforth program.fs -e bye
.... gforth notices an error, throws an exception that the application
.... does not catch, and exits. I change the program, save it, then:
% gforth program.fs -e bye

Very quick turn-around, no MARKERs needed.

However, this is quite different from what most people think of as
IDE. For such people, there is HolonForth.

>6) People want to compile a program and hold a executable in their
>hand.

Python seems to do great without this nonsense. Emacs Lisp would be
much nicer if .el (source) files were just as fast as .elc
(byte-compiled) files.

Of course, for people who like this nonsense, there are Forth systems
around, but I don't know much about that, for lack of interest.

>7) Forth has been holding on too long to its heritage. Forth was used
>to BE the OS. Nowadays, virtually no one does (or wants to do) without
>his Linux/Windows/OS-X (or pick your favorite poison). Block files are
>nice, but most programmers prefer plain source files.

Nearly all Forth systems since about 1990 support line-oriented
("plain") files. Judging from the numbers of sources published in
line-oriented format, most Forth programmers prefer that format, too.
I certainly do.

You make a lot of anachronistic points (in particular, this one and
point 2). Maybe it is you who is holding on too long to the past.

>8) Although there are some heretics, Forth is basically a typeless,
>procedural language. That goes against all trends.

The trend being towards declarative languages like Prolog or
functional languages like Haskell? Not really. All of the most
popular languages are procedural.

The approach of Forth to type checking (not doing it) is indeed rather
unique nowadays, as most of the other languages with similar
approaches (e.g., BCPL) are even less popular than Forth.

However, I think that its unique characteristics have helped sustain
Forth, whereas more mainstream languages are often quickly superseded
with another variation on the Algol theme. E.g., whatever happened to
Modula-2?

>And yes, I know Forth is so good, just because it is so different. But
>"different" will not make you a prom queen and that was what this
>discussion was all about, wasn't it?

Good point.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html
.

Relevant Pages

  • Re: Aspiring highest-order programmer
    ... >> programmers will avoid such things, ... Almost everyone that uses a compiler or group of compilers ... Germanic trolls with beards good at technology, ... > portably languages are chosen. ...
    (comp.programming)
  • Re: parser
    ... Demand for C++ programmers has fallen linearly from 30% market share in 2004 ... Are you talking about the common code base in all languages or just the ... The same is even true of commercial resources such as books. ...
    (comp.programming)
  • Re: After read a whole OS written by C, someone asks `What is the advantage of C
    ... It's more accurate to say that C *compilers* have had extensive research on optimization done on them. ... Many languages have *potential* for optimization that's as least as great or greater than that of C, but the compilers for them don't bear this out, even though optimization in general has made great strides since the early days. ... First, for most platforms, the cost of operations is proportional to the difficulty of using them in C, so programmers are forced to pay attention to what they're doing. ...
    (comp.lang.c)
  • Re: Case sensitivity in programming languages.
    ... Programmers who deliberately create different ... languages and seen different case used on different projects, ... standards which are simply the conventions and personal choices of one group ... readfile(), readFileand ReadFile. ...
    (comp.lang.php)
  • Re: RAC or Large SMP...?
    ... the lack of good support in many ... The few languages that provide such support ... towards programmers that are API driven code monkeys that have little ... parallelized applications will have to do the analysis and design work that ...
    (comp.databases.oracle.server)