I find statements that Forth is not maintainable to be clearly without merit.
I once had to figure out some code by a person that wrote Forth code
and was obviously a Basic programmer.
Most variables were things like A1 and B2 and such. Still, even with some of
the worst coding I'd seen since looking at poorly written BASIC, I was able to
not only understand what the code did but make the needed modification
to solve the problem ( it was related to intertia and not code ).
I can imagine that a person that is used to seeing tight structure of syntax,
like C might not find looking at Forth as readable.
Well written code in any language is a pleasure to read.
Well written Forth is like reading a a well indexed book. I've never seen any language that compares.
Everything is clearly in sequence. Levels of complexity of task are well organized
so that one can quickly go to any depth to understand the intricateness needed
to solve a particular problem.
When done properly one can easily skip over parts that don't need such depth. Strings
like " 45 ms Delay " or " 45 Degrees CounterClockwise " are not hard to read.
What is missing is all the boiler plate noise found in languages like C.
I can except that there is a learning curve needed for all the ! @ SWAP DUP low level
words of Forth but I think people that see Forth that way are spending
too much time looking at the rebar, gravel, sand and Portland cement to see
the bridge that was built.
Dwight

Ok.


All depends on the size of the code base, and the scope of the change.


But this implies a high level of familiarity with the language. There are many languages that are unreadable to even a skilled computerist with little background in the language itself. The attraction of the Algol-ish languages is simply the familiarity: from Algol to Pascal to C to Java, C#, JavaScript and even Python. Structurally, at a higher level, all of these languages are identical. As evidence of both their longevity and popularity as a family of languages, they obviously did "something right". Meanwhile, Forth, Smalltalk, the Lisps, and modern functional languages remain niche, despite their benefits.


Well, most of the Forth I've looked has been Forth implementations. Perhaps, historically, they are not well written, although they are clearly sophisticated.

The example from the video posted above is very nice, I watched that, and it was easy to follow and easy to read. Of course, it's a very small program, and seeing it developed keeps the context of the individual words in mind. However, the presenter mentions how there's little need for a stack diagram. Not surprising in this case, since most of the work is done through global variables.

Consider, from the F83 source code.


Now perhaps to you, this is casually readable. It's certainly not to me. The mental gymnastics of tracking the stacks [plural], notably in PARSE-WORD and PARSE, makes my head spin.

Or:

This code is GORGED with Magic Numbers. In most anything else, those would be named structure elements. Could it have been written with better constants, or could they have loaded a whole Structure package to make this easier to consume? Of course they could. But, the point, as practicing, expert Forth developers, they didn't. Not back then.

I'll finally leave this:

See, this is "representative" Forth to me, this is the code *I* see, code from "expert" Forth developers. I've shown examples before from Chuck Moore. If there's any notoriety for Forth code, it stems from stuff like this.

Now perhaps it's much different with modern Forth on modern systems, beyond the constraints of 1K blocks.

But then, maybe not. This is from eForth, and comes from a simple text file with no block constraints:

Again, dominated by stack operations, clouding (IMHO) the logic.

As a consumer of source code, the invisible stack shenanigans raises the cognitive load, at least for me. When the code is jumping in and out of named variables, the variables convey information germane to the context. Obviously, with badly named variables (a, b, x, q1, q2), you're just a step above the invisible stack. But at least the data flow is first class in the code, and not hidden.


All of the Forth I've seen is pretty much nothing but sand and gravel, and it's apparent that the developers were comfortable at this level.

All of that "boiler plate noise", like the parentheses of the Lisps, vanish during reading, at least for me. Assuming the code is properly indented. Its still a reality as a developer, you have maintain all of that "noise", but from as a consumer of source code, that stuff all goes away. I don't even see it.

Please look at the source code for C or BASIC.
Again, you are looking at the wrong things.
Dwight

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I must be honest - I find most such claims to be questionable.
Especially when I see the manufacturers claiming 9001 standard development.
(as the first one listed does)
This suggests a documentary tool-chain I've never seen in any forth system.
In fact I was just reading some old usenet posts where people are complaining
there ARE no tool chains for forth.

Whilst that isn't strictly true you do have to pay a very large sum of money
to 1 of 2 companies in the world to get anything even remotely usable in a
business environment.

and as for maintainable - would you ever see a C programmer creating a
function simply called "parse" ? Not anywhere I've been you wouldn't.

I think you'd need better examples to convince me of maintainability of forth
for anything other than minority hobby use.
and what about reverse engineering? I can reverse engineer C programs all the
way back into flow charts if I want to - what tools does forth offer for code maintenance?
Admittedly its expensive to buy a decompiler for executables but they do at least exist
and the flowchart stuff is not overly expensive if you have the C source.

Is there even a flowchart tool targeted at forth development never mind any form of project
control? I've never seen anything to support Forth development. Not even a half decent IDE.

Perhaps I could respectfully suggest that if you don't see the merit in Forth, you either try to see it, or leave Forth alone. Being outspokenly negative about it isn't conducive to a useful exchange of ideas.

Actually, he may have hit the nail on the head. Forth is transformer language.
You don't really write programs in Forth, you transform Forth into the desired
application.
You are probably right, no C programmer would even have thought to do this.
"parse" is a end purpose word. The thought to have created such a word to
make the interpreter/compiler process input streams is the essence of the
use of the Forth language.
I can see quite clearly that a C programmer would never have considered such
a function.
Dwight

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

One other point to consider. High level Forth written with the proper
use of white space is often indistinguishable from a proper
flow diagram. That is the hole purpose of using Forth in the
first place.
A guess that is a good reason to make a business of writing
C so that the code can extracted in a flow chart.
Dwight

I'm not a Forth user and in fact, cannot even understand why anyone would want to use Forth. However, in Forth's defense, I will point out that Forth is its own toolchain, much as timesharing versions of BASIC such as BBx and Thoroughbred are self-contained development environments. If you are looking for an editor/compiler/linker type of environment in Forth, they are not distinct entities as they are in most development situations. In Forth it's all rolled into one.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

To that point, many Forth are (can be) self hosting as well. In that not only is the tool chain present, but the entire source tree of the entire kit. Forth can be used to change and rebuild itself if the developer is so motivated. Especially with the Forth meta compilers. Want to change your Forth from a Indirect style to a Direct style, you can do that, and since much of the code is already in high level Forth, even for a change as significant as that, you probably wouldn't have to change that much. The basic inner interpreter and the compiler, plus any words dependent on the internal layout of the compiled code.

I do, however, have to comment on this:

I only point it out not because I question it (that's a large system, in any language), but in contrast to the style promulgated by Chuck Moore and Jeff Fox. Moore has done some significant software in very small space. He's rumored to have started development on one system basically with DOS DEBUG, and typing in binary code to get a Forth started and going from there. All living on a single floppy. If you've ever seen his talks, he talks about doing stuff in "1% of the code" as other systems.

I don't think that 1.2M lines of Forth is the Forth world that Chuck lives in.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As a data point here, my own (32-bit x86 Linux) Forth system builds both DTC and ITC versions from the same source base. The difference between the two is that each loads a different metacompiler target specification file as part of the build process, which in turn specifies a different "kernel" source file. Total size of both control files together is 1520 bytes. The "kernel" files define the "address interpreter" and parts of variables, constants and DOES>. Total size of both kernel files together is 1200 bytes. The rest of the system weighs in at less than 12K for the metacompiler, less than 8K for the assembler, and about 38K for the rest of the target system. About 4K in build scripts and shared target configuration, about 13K in making Jonesforth a usable bootstrap host, and a bit over half a K in making gforth a usable bootstrap host. And a 1.5K Makefile. And this is not a particularly featureful implementation at this point. The built system is less than 14K total (and the x86-32-DTC target is 100 bytes smaller than the x86-32-ITC target). So, 2720 bytes (2.5K?) for the DTC and ITC specific parts (ITC source is smaller by 6 bytes), vs. about 57K for the entire rest of the system, not counting toplevel build scripts and host environment fixups. Somewhere between 2 and 3 percent of the overall source built for a particular target is threading-model-specific.

Admittedly, the control files contain such egregious hackery as
which is invoked with

Yes, that's the metacompiler compiling the target system's compiler. The first colon invokes the compiler, the second colon is the name of the (target) word being defined. HEAD sets up the new dictionary header, the left-bracket leaves metacompilation state for interpretation state, the egregious hack is run to compile the code to set up a DTC (or ITC) CFA, the first right bracket re-enters the metacompiler, the second right bracket is to enter the compiler (on the target), and the semicolon ends the definition. As far as target-set-:-CFA itself goes, it's defined before colon (a variable created by the metacompiler and used to store the address of part of the "kernel"), LITERAL,A (which compiles a literal that has some displacement to account for a lack of sophistication in my approach to metacompilation), and CALL, (which assembles a literal x86 call instruction), hence the use of INTERPRET.

There's probably an opening here for a discussion of metacompilation approaches and techniques, but that should probably be a separate thread if anyone is interested... Or do we have such a thread already?

Sounds like an excellent idea for a thread!

I'm very interested.