

Forth versus C - coliveira
http://www.inventio.co.uk/forthvsc.htm

======
davidw
> 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.

~~~
eru
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.)

~~~
pietrofmaggi

      "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>).

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

~~~
pietrofmaggi
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.

~~~
kbob
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.

~~~
pietrofmaggi
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/>

~~~
mahmud
Java was _designed_ as an embedded language for a set-top box.

~~~
pietrofmaggi
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>.

------
KaeseEs
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)

~~~
coliveira
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.

~~~
KaeseEs
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

~~~
randallsquared
_Stackholm Syndrome_

Nice.

------
sgt
Also, Forth can compile itself into a new compiler!

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

Did you mean something else?

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

------
afhof
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.

