Be Moore Like Chuck
sigusr2.net
sigusr2.net
Forth programmers give a lot of lip service to writing short, well documented, elegant words (functions) but in real-world programs I've seen the opposite: the tendency has been to long, poorly documented, and convoluted words. (At least that's been my experience with open-source Forth programs. I've heard the libraries for commercial Forths are of much higher quality, but I have not verified this myself)
Forth has been compared favorably to Lisp, but I found them to be like night and day, and Lisp (and especially Scheme) to be far more elegant and easy to both read and write.
Forth might arguably be better than assembly, but unless you have a pressing need to write the tiniest programs possible (like on some resource-starved microcontroller), I'd be hard pressed to find a reason why you'd want to use Forth instead of some higher level language that is far less painful to work with.
In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language.
Don't get me wrong, I really, really wanted to like Forth and spent a lot of time trying to learn it, but in the end it felt like it just wasn't worth it. I might give it another go if I get heavily in to programming microcontrollers where Lisp or Scheme is not an option.
Even more off-topic:
> Maybe you'd like to subscribe?
I love that this links to an RSS feed.
Please go tell this to everyone on the GNU Emacs mailing list, I think I am not the only one who missed the memo.
Now, unsuitable does not mean impossible. It is just harder than with other languages. Which means you will hit a complexity ceiling earlier.
Also, Emacs is just a text editor and platform for anything. Java with Eclipse has eclipsed (hihi) it. Why hasn't the Emacs community made it into a real IDE with refactoring for example? They certainly have been challenged often enough. Why have multiple companies built new IDEs from scratch instead of building on Emacs?
Have you ever tried working on an Eclipse plugin? You obviously have no experience writing extensions to GNU Emacs if you think that "It is just harder than with other languages." You are living in Java fantasy land.
There are literally dozens of Emacs packages for different programming languages offering refactoring support. The vast majority of Emacs development is done outside of the main repository. People decide to build on built-in GNU Emacs code, on other third-party packages, and sometimes third party packages get merged into the main repository. There is a huge group of different development communities around GNU Emacs that is unmatched by any IDE, and few other applications at all, right now. GNU Emacs is an overwhelmingly successful example of a project with a large number of developers, and among other things it shows that you do not need namespaces (modules) or OO for this.
To be fair to Forth and Forth programmers, Forth is very often used in environments where they are running on the iron and need to roll there own. There were environments where Forth used the local libraries like Forth on the early Macs[1]. You could access the Macintosh Toolbox just like the other languages.
They are unsuitable for projects with many developers though.
I don't know about that. I get the feeling that Forth would be fine but require a common, shared dictionary for the project which isn't far from a common class library used in other languages. I'm not sure it would require more interaction than something like Smalltalk which has been used in large projects.
1) Forth was an early Macintosh language because of how cramped 128Kbytes is.
Look up "Thinking Forth" for more in this vein.
I would not call it over-architecting, if you sacrifice portability, maintainability, *-ility too much. What exactly is "too much" depends of course.
It is unlikely to come up in practical use now, admittedly.
This accords with my intuition from seeing that things like SKI combinators and ELF relocation headers are Turing complete. However, I'm interested in whether there is any theoretical justification for that particular breakdown of features.