What is Forth?

[scotws]

I just stumbled over this bare-metal Forth on RPI, pijFORTHos (https://github.com/organix/pijFORTHos), which I'd like to recommend to a more general group of Forthwrights because it contains the brilliantly commented syntax of its x86 parent: https://github.com/organix/pijFORTHos/b ... orth.s.txt . Its a model implementation of a DTC Forth with lots of cute ASCII drawings. That is the link to the assembler core, the higher-level words are here: https://github.com/organix/pijFORTHos/b ... orth.f.txt

[barrym95838]

I can't be 100% sure, Scot, because x86 assembly and ARM assembly both give me a headache, but it looks like those implementations to which you linked are ITC rather than DTC, based on what looks like a raw address in each CFA instead of raw machine code in each CFA, the latter of which is one of the defining characteristics of DTC. In other words, a DTC secondary's CFA would contain a "JSR DOCOL" instead of a "DW DOCOL", according to my limited understanding.

I agree with you that the plain English commenting is superb, but I find the paucity of stack comments in the x86 version to be an issue, at least for the primitives in the .s file.

Mike B.

[scotws]

barrym95838 wrote:

I can't be 100% sure, Scot, because x86 assembly and ARM assembly both give me a headache, but it looks like those implementations to which you linked are ITC rather than DTC, based on what looks like a raw address in each CFA instead of raw machine code in each CFA, the latter of which is one of the defining characteristics of DTC.

Ah. Good point, I admit I just trusted the paragraph headline in the assembler file. I hope I can spend more time with the code this week, will try to figure that out.

[GARTHWILSON]

This essay from Jeff Fox is about Forth hardware and software, not 65anything, but is relevant to the topic title anyway.  It's 16 years old but still has relevant philosophy, about computing power versus silicon price and power consumption (Forth processors coming out very strong), whether or not you even need an OS (Forth often acts as its own OS), context-switching speed (Forth again comes out a winner), development speed (again Forth comes out a winner), acceptance by those who don't want to consider a better alternative that they're not familiar with (this is the area where Forth does poorly), etc..
http://www.ultratechnology.com/plan9.htm

[BigDumbDinosaur]

GARTHWILSON wrote:

This essay from Jeff Fox is about Forth hardware and software, not 65anything, but is relevant to the topic title anyway. It's 16 years old but still has relevant philosophy, about computing power versus silicon price and power consumption (Forth processors coming out very strong), whether or not you even need an OS (Forth often acts as its own OS), context-switching speed (Forth again comes out a winner), development speed (again Forth comes out a winner), acceptance by those who don't want to consider a better alternative that they're not familiar with (this is the area where Forth does poorly), etc..
http://www.ultratechnology.com/plan9.htm

In the time since Fox published his essay, computing power in the x86-64 arena has greatly increased, even as the cost per MIPS has plummeted. This tends to reduce the performance arguments in favor of Forth, especially if Linux is considered (Linux was not mentioned in Fox's essay). The Linux kernel has been almost continuously massaged to make it perform with maximum alacrity and stability. Hence the only really viable area for Forth these days is in systems lacking copious amounts of computing power and resources.

The reality is Forth remains a niche environment that doesn't fit well with many common computing tasks. Your average, non-technical computer user is not going to look at an environment that is RPN-based and can be made to self-destruct through simple mistakes. I've been using and programming computers of one sort or another since the latter 1960s and while I've read about and understand the basics of Forth, I have yet to encounter any good reason to invest time in it. When I'm a computer user, as opposed to a programmer, I want to be able to, using an automotive analogy, drive the car without having to first put it together. That's not Forth. If I'm a computer programmer, I necessarily have to develop in the language that will suit the task. That usually won't be Forth, since most of my professional programming is for clients who are not and never will be running Forth.

Forth is great for geeks and nerds, and terrible for the rest of the computing population. Or, to borrow a phrase posted by someone else around here, Forth got voted off the island years ago.

[Dr Jefyll]

I sense a twinkle in your eye, BDD, as you must surely be aware that your post is provocative.

I haven't read Jeff Fox's article, and I don't necessarily defend all claims made by him regarding Forth. It's possible he stated his case too zealously. Talk to him about that. What I will say is that Forth's interactivity makes it extremely fast to develop code with, and this boon doesn't come at the cost of sluggish performance or bloated memory consumption.

Quote:

I necessarily have to develop in the language that will suit the task.

And yet you're willing to write in assembly? -- a language that can be made to self-destruct through simple mistakes?

Quote:

That usually won't be Forth, since most of my professional programming is for clients who are not and never will be running Forth.

You don't seem to recognize that your clients could run Forth and be unaware that they're doing so, just as they could run code written in C or BASIC without being aware. And the code could run under Linux.

Quote:

I've read about and understand the basics of Forth

IMO it's clear your grasp of Forth basics is incomplete. To be fair, even a large amount of reading may not be enough. You have to spend some time in the driver's seat (using the automotive analogy).

-- Jeff

[barrym95838]

Dr Jefyll wrote:

... I haven't read Jeff Fox's article, and I don't necessarily defend all claims made by him regarding Forth. It's possible he stated his case too zealously. Talk to him about that ...

Sadly, Mr. Fox is no longer with us. A heart attack took his life in 2011.

http://www.legacy.com/obituaries/sfgate ... =151440780

Mike B.

[BigDumbDinosaur]

Dr Jefyll wrote:

I sense a twinkle in your eye, BDD, as you must surely be aware that your post is provocative.

Not intentionally so. I'm merely stating perceptions and to some extent, reality. Outside of 6502.org, I have seen very little enthusiasm for Forth. As I said, most non-technical computer users are not going to be enamored with an operating environment that works against conventional thinking, e.g., postfix vs. infix notation. Postfix may be great for the computer, but is contrary to how people process numbers. It's very tough to fight that kind of intellectual inertia.

Quote:

What I will say is that Forth's interactivity makes it extremely fast to develop code with, and this boon doesn't come at the cost of sluggish performance or bloated memory consumption.

That is true, but is hardly unique to Forth. I can recall working on systems in the 1970s in which the entire machine had only 128K (no bloated memory consumption) and could support 16 concurrent users in full conversational mode, making it quite interactive. The primary performance constraints in those systems were related to I/O bound activity, which would have been a constant no matter the chosen operating environment.

Quote:

Quote:

I necessarily have to develop in the language that will suit the task.

And yet you're willing to write in assembly? -- a language that can be made to self-destruct through simple mistakes?

In the case of developing firmware for a computer, assembly language is close to being de rigeuer. That it is possible to crash the machine with simple mistakes is a known weakness of assembly language—my clients are not going to be working at that level. In developing for clients, C is as low-level as I usually get, which while containing a variety of linguistic booby traps, isn't going to crash the machine when a program bug is encountered.

Quote:

Quote:

That usually won't be Forth, since most of my professional programming is for clients who are not and never will be running Forth.

You don't seem to recognize that your clients could run Forth and be unaware that they're doing so, just as they could run code written in C or BASIC without being aware. And the code could run under Linux.

Forth lacks the functionality required to process many business applications. Yes, functions can be developed to plug such gaps, but at what expense in terms of development time?

Quote:

Quote:

I've read about and understand the basics of Forth

IMO it's clear your grasp of Forth basics is incomplete. To be fair, even a large amount of reading may not be enough. You have to spend some time in the driver's seat (using the automotive analogy).

That I would do if there was something to be gained from it.

[GARTHWILSON]

It takes a lot of experience in Forth to truly grasp how much capability is there.  One cannot make a valid judgment from the outside.  It is common for even newish Forth enthusiasts to think there are certain things Forth would not be able to do well or even at all; but as they gain experience, they find that not only can it do them, but offers very elegant solutions for them.  It happened to me, and it still continues to, even after 25 years.  Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done.  There's a flexibility there that I have not seen in any other language.

Regarding applications, Jeff Fox does say in the essay,

• • no single operating system or programming language is ideal over the whole range of machines and application domains

so he's not being naïve in his enthusiasm; but he does speak from a ton of experience in programming and Forth hardware.

I would add that what "conventional thinking" is (the postfix vs. infix notation thing) may depend on the individual.  I much prefer postfix and using a data stack and getting rid of the piles of parentheses.  I understand that the Korean language is post-fix, so Koreans tend to pick up Forth more naturally than Americans do.  English is my first speaking language, but not the first language I learned to read and write in.  (Spanish is.)  That may have some influence on my thinking.  In someone's musings (name withheld to protect the guilty) on language implementations on the 6502, he says that errors in data-stack manipulation are a serious problem in Forth.  This shows his inexperience with it.  Actually, you could write an infix parser in Forth, but I've never heard of anyone wanting to after they come up to speed in Forth.  As for crashes, I very seldom get a crash when developing software in Forth, and when I do, I can usually recover in a couple of seconds, without re-loading software, and I usually realize right away what I did wrong.  No debuggers, etc. needed.

Forth has run entire hospitals and airports with all their business and administrative tasks; so I don't think there's any shortage of capability for business applications.  Forth, Inc. offers their SwitfForth which includes object-oriented programming and all the tools to integrate with Windows, Linux, and Mac OS X.  Please see https://www.forth.com/swiftforth/ .

Regarding development speed, a quote from Jeff Fox's essay which I've seen corroborated in Forth, Inc.'s literature:

• • We have many examples where the smaller team of Forth programmers finished the project much faster than the larger team of 'C' programmers.  The typical ratio in required man-months is about ten to one.

I know Samuel Falvo has said it doesn't have to be that way, but it is common.

Regarding run speed, memory required, and power taken, Jeff Fox says:

• • There are also many examples where the resultant code generated in 'C' was simply too slow or too big or too power hungry to meet the application requirements and where Forth came to the rescue.

It doesn't have to be just Forth though.  My assembly-language techniques, productivity, and enjoyment have benefited a ton from my Forth experience.  I know I should read the book "Thinking Forth" again as it is really about programing philosophy; and although it's Forth-centric, many of the principles in it can be carried into other languages as well.

Regarding "using an automotive analogy, drive the car without having to first put it together," yes, that has been a problem in the '02 Forth world.  I have a pipe dream of porting my Forth (which is far more extensive than FIG's) to someone's SBC they're selling and making a turnkey system that gives results right out of the box.  This does exist for PCs though, reference again Forth, Inc.'s SwiftForth.

Quote:

Sadly, Mr. Fox is no longer with us.  A heart attack took his life in 2011.

yes, sad news

[scotws]

BigDumbDinosaur wrote:

Or, to borrow a phrase posted by someone else around here, Forth got voted off the island years ago.

... and is now currently in orbit around Saturn in the Cassini Probe (see http://lasp.colorado.edu/~horanyi/gradu ... g_MIMI.pdf for details) ... but yes, in the age of majorly overpowered hardware, it is hard to justify Forth for the mainstream.

[BigEd]

Forth's strengths should be found, I think, in severely constrained systems.

Another possible advantage is in learning: does Forth illuminate aspects of computer science which are interesting, which are not illuminated by other languages? I think so. It can show us something about how computation can be organised. That doesn't mean it's necessarily a good first language, of course, and I suspect it isn't.

Another aspect of a programming language is its suitability as an engineering tool - and for that, I'd be interested to hear informed opinions: particularly, has anyone ever had experience in a team environment, writing Forth to solve a problem and needing to maintain the solution over time? (Let's take three people as the minimum team size for this purpose.)

[Bregalad]

Quote:

Outside of 6502.org, I have seen very little enthusiasm for Forth.

I can confirm this. For some reason those forums seems to be a nest of FORTH enthusiasts, but outside of here... virtually nobody seems to be interest. Not saying that's good/bad or whathever, just notice how things happens to be.

Quote:

It is common for even newish Forth enthusiasts [...], they find that not only can it do them, but offers very elegant solutions for them. [...]. Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done.

In other words, the learning curve is very high, which is usually a bad sign.

Quote:

I would add that what "conventional thinking" is (the postfix vs. infix notation thing) may depend on the individual. I much prefer postfix and using a data stack and getting rid of the piles of parentheses.

This is a false debate, because only a very small part of a computer program is actually made of mathematical formulas.

Quote:

a quote from Jeff Fox's essay [...]
Regarding run speed, memory required, and power taken, Jeff Fox says:

So this is a biased propaganda.

[GARTHWILSON]

Bregalad wrote:

Quote:

Outside of 6502.org, I have seen very little enthusiasm for Forth.

I can confirm this. For some reason those forums seems to be a nest of FORTH enthusiasts, but outside of here... virtually nobody seems to be interest. Not saying that's good/bad or whatever, just notice how things happens to be.

There are Forth forums (I just got on one on facebook a few nights ago), but Forth enthusiasts tend to be free-thinkers who will do their thing even if nobody goes along.  Also, Forth's extensibility means you don't need a supplier to keep you advancing with new features.  (I discussed that further on page 1.)

Quote:

Quote:

It is common for even newish Forth enthusiasts [...], they find that not only can it do them, but offers very elegant solutions for them. [...]. Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done.

In other words, the learning curve is very high, which is usually a bad sign.

Not really.  You can get up to speed with the mundane stuff pretty quickly.  It's the more creative stuff that takes time to see the possibilities of, for example, to envision and create new defining words to accomplish the job much more efficiently.  Also, note that everything one might consider to be part of the compiler comes to only a couple hundred bytes in '02 Forth.

Quote:

Quote:

I would add that what "conventional thinking" is (the postfix vs. infix notation thing) may depend on the individual. I much prefer postfix and using a data stack and getting rid of the piles of parentheses.

This is a false debate, because only a very small part of a computer program is actually made of mathematical formulas.

The latter part is so true.  Most of programming is just the logical step-by-step stuff, not mathematical formulae, and infix would have the least benefit for that.  For the math, if you really want the algebraic notation, you can put it in the comments, then you'll have both.  Algebraic (infix) tells you what you get. RPN (postfix) tells you how you get there.

Quote:

Quote:

a quote from Jeff Fox's essay

So this is a biased propaganda.

Why would you say that?  It's not bias.  It's experience.  He had far more experience in it than anyone else here, probably even Brad Rodriguez.  And look at his accomplishments with Chuck Moore, accelerating software by factors of anywhere from a hundred to a thousand.  He also wrote the essay, "Low-Fat Computing."  He does skewer a lot of sacred cows.  It's way past time for someone to do that.


If a newcomer really wants to know what Forth is, I doubt they'll read all the way to page 4 of this topic.

[rwiker]

Bregalad wrote:

Quote:

Outside of 6502.org, I have seen very little enthusiasm for Forth.

I can confirm this. For some reason those forums seems to be a nest of FORTH enthusiasts, but outside of here... virtually nobody seems to be interest. Not saying that's good/bad or whathever, just notice how things happens to be.

That's absolutely irrelevant to whether or not Forth is useful (or even useable).

Bregalad wrote:

Quote:

It is common for even newish Forth enthusiasts [...], they find that not only can it do them, but offers very elegant solutions for them. [...]. Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done.

In other words, the learning curve is very high, which is usually a bad sign.

Nothing worth learning (or at least, nothing that brings above-average returns) is simple.

Bregalad wrote:

Quote:

I would add that what "conventional thinking" is (the postfix vs. infix notation thing) may depend on the individual. I much prefer postfix and using a data stack and getting rid of the piles of parentheses.

This is a false debate, because only a very small part of a computer program is actually made of mathematical formulas.

The use of the stack is not restricted to mathematical formulas... the stack is used for setting up function parameters, too. The main difference to "conventional" languages is that the stack operations are explicit in Forth.

bregalad wrote:

Quote:

a quote from Jeff Fox's essay [...]
Regarding run speed, memory required, and power taken, Jeff Fox says:

So this is a biased propaganda.

Biased in a good way, surely? In the last few posts in this thread the arguments for Forth have come from people who have made the investment of learning Forth and used it, while the arguments against it seems to have come from people who have decided that learning Forth is not worth the effort.

[Bregalad]

I am neither for or against any language, including Forth. I was just pointing out it's usage outside of this forum is extremely marginal, which do not mean the language is any better or worse than anyother.

I learned the basics of Forth because enthusiasts on 6502.org convincted me to do so, and yet I still don't know what to do with that knowledge. I just learned the basics, knowing how to deal with the stack is great and all, but not sufficient for an actual computer program, where concepts such as arrays, structure, memory allocation and strings comes very early and are not natively implemented in Forth, meaning you have to implement your own (which is probably not complicated but still). I think the major reason I wasn't able to get further is that the books I found sucked. I really hope I'll be able to continue and write actual program in Forth however, after I find a good book.

Quote:

Nothing worth learning [...] is simple.

WHAT ?
I think that, 1. everything is worth learning and 2. particularly if it's simple, since it makes the learning process faster.

The understanding I had of Forth is that the language itself is extremely bare-bones, but it is extremely extensible to compensate for that, and allow you to do very complicated things with a few "words". This is nothing special as any program that supports function (a.k.a. subroutines or procedures) can do that, but the way it is syntaxed and factored out with words is more elegant, and I like the concept. Again the only reason I didn't went further is the lack of decent learning material offline, and the fact there was no immediate need for it.