Re: FORTH levels

Frank Buss wrote:
Aleksej Saushev wrote:

Have you read the thread?

Yes, and I have collected some reasons:

Difficult language:

- Forth does not enforce a grammar

Perhaps not a necessary reason, since in the beginning the majority of users of the LSE dialect actually *used* it pretty grammatically. But I probably contributed to the trouble here since my style was very influenced by what I'd read, especially Elizabeth's papers. And the style you pick up from the Forth literature is not grammatical.

Regardless, it proved much easier to share ideas in C than in Forth.

- "write only" code

And that's what you get if you don't write grammatically, unless it's a Forth specialist reading it. We needed a language, not just a vocabulary, but nobody recognized the distinction.

- solving a task in Forth needs longer than in C

It depends on the task, of course. For awhile Unix/C and Forth thrived in synergy: Unix had much better machinery to manage source than Forth, and was better at the data analysis "back end" tasks. Floppy drives gathered dust as RCS-controlled source files replaced blocks, but Forth systems proliferated. However, those systems were largely running code written in the time frame before the Unix systems showed up. The Forth code increasingly was a "black box": used and scripted, but not understood. New projects tended to be in C.

In 1983, I had bought a 68k-based development board as a tool to port our LSE Forth dialect from the 1802 to a more modern CPU. But then, an opportunity came up to do a cutting edge experiment if we could cobble together an instrument in a hurry. The 68k board had exactly the resources we needed, and our 68k Unix system could compile and link stand alone binaries. Software was a piece of cake. It was the optics that gave us headaches, but we got it done, got a result, and published.

Now *if* Forth had been a going concern on that hardware, it might have been a little faster and easier, at least for me. But the whole software project took far less time than it would have taken to research commercial Forth systems, procure one, install it, read the docs, etc. We'd done cross development before on an Intellec 8 system, compiling PL/M on Multics, but this was much easier. Not quite interactive, but still, when we had a bit-pushing debugger in ROM for the low level, and we could get around the edit/make/upload loop in a minute for a program that still was going to take 20 minutes to test properly, the advantages of Forth's better interactivity were looking slim.

What C came with was Unix. Unix was a *tremendous* "support system" for programming. Forth, too, but especially C.

And that was 25 years ago. What took a minute now takes a second. Forth's interactivity remains an advantage, but it's not as definitive an advantage as it was in the 70's.


Other reasons:

- Forth has always had a tradition of being willfully bizarre

One former user of both traditional Forth and STOIC told me recently that he considered the text interpreter the biggest defect of traditional Forth. Yet most Forthers cling to it as if it was necessary.

- marking as "obsolete" by decision makers

In the small projects in my world, the decision makers and the implementers are the same. In big projects, there are managers, but at least the smart ones are going to go with what's comprehensible to the whole team. These days, that's never going to be Forth: few if any team members will have heard of it.

I've had customers request that I do projects in C. I've never had a customer request Forth. I've inflicted my private dialect on a few, and they tend not to like it.

- lack of a vital user community
- lack of libraries and published code

Those are absolutely crucial in the 21st century.


But I was interested why they drop Forth at the MIT Center for Space
Research, because they were writing in Forth, so most of the points I
listed, could not be the reasons for them to switch to C.

Eh?


Oh, really? Smalltalk is all about graphical display and interactivity,
much more than Forth, it provides orders of magnitude better tools for that,
it does that for ages, and it still isn't in any comparison as popular as C.

I know some companies who used Smalltalk, which was popular in Germany some
time ago, and switched to Java. Maybe some reasons could help to improve
Forth:

Non-technical reasons:

- Internet hype

Consider Python. Perhaps "internet hype" got it started. In my world, the early adopters of Python were a pain, writing important stuff in this language that nobody understood. Creating unmaintainable code. But then, they started to publish useful modules. Python's module system has proven itself to be the most user friendly system for code sharing ever. Now Python is a major player.

I would enthusiastically adopt and promote a language that placed Python's community friendliness atop a lightweight, hardware oriented foundation. Umbilical PyForth?

- Sun marketing

Hasn't been very effective in astronomy: there's not a lot of Java there (although more than there is Forth). Maybe that's why Gosling went to the SPIE conference in 2006.

- decision of big companies (and money, e.g. from IBM) to use Java

IBM was a lot bigger and more powerful when it was one of the institutions promoting PL/I. Institutional power matters when there aren't other important deciding factors, but when one language doesn't produce much, and another does, you know who's going to win. C beat PL/I and Ada fair and square here.

Forthers brag and brag about their wonderful productivity, but have very little to show for it. The excuse is "it's proprietary", but that won't wash: if Forth is so great, it should be just as great at producing open code as closed.

Compared to spending serious money compiling PL/M on an overloaded timeshared mainframe, punching out paper tape, physically carrying it to the dev system, loading that in, and then trying to debug with toggles and lights, Forth was a great productivity advance. But that was a long time ago.


Technical reasons:

- very stable (long running servers with no crash are no problem)
- Gargabe Collection (easier to write programs with no memory leaks)
- write once, run anywhere
- big platform independant standard library for network, GUI etc.

Another important reason is safety: it is a very simple programming
language and companies can hire cheap programmers, who can learn it fast
and even if the programs contains bugs, Java is very safe and most of the
time the rest of the system still works. In contrast: I'm an unexperienced
Forth programmer and often I miss some stack drop or make a dereference too
much and the whole program just crashs, in some Forth systems without a
stack trace, which wouldn't help anyway e.g. if you overwrite array bounds,
which is too easy in Forth.

Same for Smalltalk: You can change the standard library and the language is
not very restrictive (e.g. no static typing), which makes it harder for the
average programmer and big teams to produce a working system.

That actually hasn't been a big issue in my world. Formal errors like wrong numbers of arguments, wrong types, array out of bounds, memory leaks, etc. are a relatively minor concern. Compared to making the code and hardware work together, and getting them to solve the right problem, formal errors tend not to waste much time or treasure.

--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor necessary to establish practical, real world truth. Those who attempt to use logic for that purpose are abusing it.
.

Relevant Pages

  • Re: Why context-free?
    ... >> reasons to abandon context-free grammars completely. ... >of a language, ... I am specifically referring to using a grammar that includes context. ...
    (comp.compilers)
  • Re: M2 for iPhone?
    ... (I got a bit more clarity about your reasons for Objective M2 now. ... language and interfacing. ... I use libtask because its lightweight and I ... GNU pth is probably more portable. ...
    (comp.lang.modula2)
  • Re: Is VB Caca??
    ... Calling a function of a language "quirky" seems terribly judgmental. ... with all of the VB6 work out there that has not been converted to VB.Net, ... like Java fundamentally yet program in VB.Net for economic reasons and ...
    (microsoft.public.dotnet.languages.vb)
  • Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)
    ... The real spirit of zipis ... a full understanding of zipcan be had by remembering ... making this a defined behavior results in making the language ... your reasons is ...
    (comp.lang.python)
  • Re: Speed Test between C and Fortran 95
    ... forgetting to recompile after editing, 3) forgetting to save the edited ... I'll also note that all generalizations are false. ... than C." There can be several reasons to recode something in a different ... language, but I wouldn't suggest undertaking a huge Fortran/C conversion ...
    (comp.lang.fortran)