Lambda the Ultimate

I only have minimal experience with Forth, but I agree with that characterization; it's a backwards Lisp without parenthesis. You also tend to see similarities between the languages, like how CREATE and DOES> in Forth are often used like Lisp macros.

Also, for anyone seeking more Forth resources, I found this tutorial to be excellent.

The big difference between Forth and Lisp in my view is lack of lambda expressions. However there is some recent work towards this end:
by Lynas and Stoddart: http://dec.bournemouth.ac.uk/forth/euro/ef06/lynas-stoddart06.pdf.

Thanks for mentioning me, but for the record it is "Diggins" rather than "Higgins".
:-)

I wonder who spends more time thinking about memory management, Lisp or Forth programmers? Reducing heap-allocation is a major theme amongst (Common) Lisp programmers.

Forth programmers obviously.
But concerns are different, because Forth programmers include the processor, the running program in the picture: what spends more time (and space) dealing with memory management, Lisp or Forth programs?
Again the concerns are different, because the applications and the supporting hardware are different.

All this seems to assume when one says `Forth' he/she means GForth or Forth Inc. or the like. Nope.
You can write a Forth for the JVM, for example, and it won't have to bother with memory-management.

Lisp is much an idea, rather than the implementations. Same for Forth.

I don't think the ANS Forth specification allows a system to use dynamic memory allocation for ALLOT for instance.
It is true that a Forth system may provide some extension that may rely on automatic memory management of the hosting software stack (the OS, the actual implementation language), but it would certainly not be portable.

Memory management is a minor issue in Forth anyway. Thanks to MARKER or FORGET one may allocate static data for a job and release it very easily. Dynamic memory allocation isn't a Forth taboo, but static memory allocation is easier to deal with, more secure, and cheaper; this is quite valuable in embedded software.

I totally agree that Forth is much and idea rather than an implementation, and the idea of many Forth programmers about of Forth is not compatible with GC.

Thanks to MARKER or FORGET one may allocate static data for a job and release it very easily

This is only useful if you're deallocating regions in the reverse order to that in which you allocated them. It seems to me that the kinds of applications for which Forth is well suited are partly determined by this fact.

This is only useful if you're deallocating regions in the reverse order to that in which you allocated them.

True. That means that if one wants to use this, one just has to take care of that. As the main use of it is to compile and execute some part of the application when required (for instance, a database report), this is not a big constrain.
And that's a particular feature one may use, not the only way to manage memory. One can also use regular static storage, write a heap allocator if required, or even write a GC if mandatory.
But I know it's hard for outsiders to see how one may use and combine the unique set of features Forth offers, some of them being even rare among other languages, to do what one has to do.

It seems to me that the kinds of applications for which Forth is well suited are partly determined by this fact.

Well, I don't think Forth would have been used on space missions or in air trafic control systems, among other things, if that is true.

Well, I don't think Forth would have been used on space missions or in air trafic control systems, among other things, if that is true.

Funny, they're exactly the sort of apps I'd expect to fit in neatly.

The comparisons to lisp seem not inappropriate - I'm not sure I can say the same for your condescending comments about people who don't code in forth.

Funny, they're exactly the sort of apps I'd expect to fit in neatly.

I should have also mentionned CAD software.

The comparisons to lisp seem not inappropriate - I'm not sure I can say the same for your condescending comments about people who don't code in forth.

Wrong thread. BTW I made a comments about the comments of people who don't code in Forth. I may admit I spelled it bad, but I think it's appropriate not tell people to abstain from negative comments on languages they obviously didn't really use.

Funny, they're exactly the sort of apps I'd expect to fit in neatly.

I should have also mentionned CAD software.

That's more interesting, but for historical reasons not necessarily so surprising. Forth's nearest natural competitor has often been assembler.

The comparisons to lisp seem not inappropriate - I'm not sure I can say the same for your condescending comments about people who don't code in forth.

Wrong thread.

Right thread - the "we can build anything on top" approach is something that forth has very much in common with lisp.

BTW I made a comments about the comments of people who don't code in Forth. I may admit I spelled it bad, but I think it's appropriate not tell people to abstain from negative comments on languages they obviously didn't really use.

I think the comment in question may well have been appropriate and needed addressing directly rather than with an argument from authority. There are garbage collected concatenative languages that typically operate at a higher level and it seems likely that they would be more suited for applications where GC is near-ubiquitous anyway, no?