Forth versus C | Hacker News Reader

Forth versus C

inventio.co.uk

33 pointscoliveira23 comments

> Q. Could you define “better” in this context? > A. Easier to read and maintain, fewer bugs, smaller, faster development.

That's fairly subjective. I find the whole "keep track of the stack in your head" thing quite irritating, to be honest. Forth is more dynamic than C, certainly, but beyond that, I find C much easier to utilize in that you mostly concentrate on what you're doing rather than dup dup swap drop roll bee bop a lop bam boom tutti frutti etc... C's big "extraneous" overhead is keeping track of memory allocation.

You can use variables in Forth. It's just scorned as non-Forth-ish. And you also have to keep track of memory allocation in Forth. (Though it's possible to write a garbage collector.)

  "Though it's possible to write a garbage collector."

There is a Garbage Collection package available for Forth here (http://www.complang.tuwien.ac.at/projects/forth.html).

But take note:

   > Q. So why  doesn’t everyone use Forth?

   > A. Because it is also possible to write worse programs 
   > in Forth than in C.

That's their rationalization, at least. I think that for the average programmer, having to keep track of the stack is just added mental overhead that gets in the way of making their program do something useful.

Probably if you substitute Lisp for Forth, and Java for C, it would be more "modern" and still true.

They are in two different segments.

Forth and C are low-level languages. I can (and do) use them to develop firmware.

Lisp and Java are for "big-iron" system.

But you are right, one of the strength of Forth and Lisp is the availability of a REPL.

REPL is indeed a great feature. Once you get used to it, you can hardly ever go back.

Lisp was for big iron in 1975. Machines with over a megabyte of RAM and several hundred KIPS. There are several Lisps and Schemes targeting the embedded world these days.

Yep!

Even Java is used in the embedded world today (luckily not my world).

Simply, C and Forth can scale down to really small MCU with few hundreds bytes of code space and some bytes of RAM (with Forth, on such small target you will probably loose REPL).

A readily available OSS Forth I really like can be used on small MSP430 where no lisp or scheme can go! (www.camelforth.com)

Currently most embbeddable scheme I know is the Armpit http://armpit.sourceforge.net/

Java was designed as an embedded language for a set-top box.

True, but that was oak (oak 0.2 langage spec is here https://duke.dev.java.net/green/OakSpec0.2.ps).

BTW this specs put some lights on some java behavior: http://www.devx.com/Java/Article/10686.

I was thinking about similarity of Lisp and Forth in that programmer can very easily create DSLs.

Regardless the merits of the language itself, the culture of Forth has some serious issues that cause me to doubt that a skilled Forth programmer truly has a development speed that is a multiple of that of a skilled C programmer. Cf. this advice from Thinking Forth:

"Some Forth practitioners advocate storing source code in variable-length, named text files, deliberately emulating the approach used in traditional compilers and text editors. This approach may become more and more common, but its usefulness is still controversial.

Sure it's nice not to have to worry about running out of room in a screen, but the hassle of writing in a restricted area is compensated for by retaining control of discrete chunks of code. In developing an application, you spend a lot more time loading and reloading screens than rearranging their contents.

"Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition."

(from page 144 of the 2004 edition)

There are some developers that prefer the block-oriented approach of creating Forth code. Remember that Forth is a dynamic language, so there is a tradition of viewing the system as an image (similar to Smalltalk), instead of a bunch of static files saved on a file system. They achieve this by creating small blocks of code that are dynamically loaded as necessary.

This doesn't mean you can't create Forth programs from standard text files. All modern Forths work this way, providing blocks only as an additional feature.

My main beef was with the last bit - ""Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition." This reeks of Stackholm Syndrome, where having toiled under the limitations of a system for some time and developed workarounds and jerry-rigs* to get by them, one begins to view them as strengths for no other reason than their familiarity.

If nobody thinks like this any more though, congrats on escaping what is normally a sure route to smug weenie-ism.

*Eg. later in the same section, Brodie suggests defining constants associated with block numbers as a sort of ersatz filenames

Stackholm Syndrome

Nice.

IIRC the 2004 is simply a retyping of the 1984 edition, so all the content is nearly thirty years old (Thinking Forth Project http://thinking-forth.sourceforge.net/).

So this kind of information is a bit dated.

If you look at current forth implementations (gforth, Forth inc and MPE comes to mind) none of them is screen based; you can decide if is good or bad ;-)

I was just scanning 40K c++ header I'd written..

1K block limit seems like it could be a useful device for making functions understandable at a glance.

As I remember, Steve McConnell said studies have shown the most bugs can be found in very long and very short functions...

Also, Forth can compile itself into a new compiler!

And so can C. And almost any language out there with a reasonable implementation. We call that "bootstrapping".

Did you mean something else?

True, but it's a bigger undertaking in C.

The linker and makefile are not at all part of the c standard.

Also, I assert that any "A versus B" will almost invariably favor A.

Reply on news.ycombinator.com