I tried to learn Forth, and found it to be an obfuscated, write-only language.
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.
I love the story of this and the shirt turned out pretty good in my opinion. There's just one problem: I really don't know anything about Forth or its creator. Which is probably a shame, I realize. I simply came into programming as a hobby when C was the hotness, and well, learned C. I wonder greatly if I should ever learn any Forth, and how much. Is it only of historical interest at this point?
Lots of people, myself included, implement a Forth without really using it. That makes it sound like a toy, but it's more like an important lesson in programming concisely and choosing a comfortable level of abstraction for the problem. Forth is designed to be simple to implement and extend, and that's the foundation of Forth as a whole philosophy: choosing a specification that actually solves the problem without generalizing or over-architecting the solution. Forth, the language, is just the set of tradeoffs that Moore thought was best suited to that, a position that most of the industry implicitly disagrees with(because they do things like introduce large libraries and dependencies where Moore is very DIY). It's a very concise language with a lot of sharp edges.
I second the vote for "Thinking Forth." It's free online[1] now. Most of agile development, refactoring, YAGNI, all the buzzwords and advice on programming from the 1990's and 2000's are already there, distilled down into nice examples.
I get into Forth before college, about the same time as I got into Standard ML. I think the most important takeaway is that you start regarding anything in your software stack as potentially optional. It's kind of liberating knowing that, if needed, you could comfortably live with a block editor and no files or filesystem.
This is just a side observation: It's amazing that all any programming language has to do is 1) Store data and 2) Branch. Yet the number of ways to build on these two basic concepts is astounding.
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.
Every coder should if you ask me; I consider C, Forth & Lisp to be the brightest shining stars in PL design. Each of them offers a unique approach cut down to it's core. If you prefer a more convenient and less dogmatic approach, I'm working on a hybrid scripting language [0] that might be of interest.
Forth and Lisp are genius and real power tools for lone hackers. They are unsuitable for projects with many developers though. Forth in particular has driven the philosophy of not-invented-here roll-your-own to the extreme. That is completely fine for short code but "brightest shining stars in PL design" is too much.
Forth in particular has driven the philosophy of not-invented-here roll-your-own to the extreme.
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.
I have to admit that I did not have emacs in mind. With 1.6M lines and 934 contributors we can consider it a sizeable project. https://www.openhub.net/p/emacs
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?
Can you please stop trolling? You make assertions about GNU Emacs development while obviously having no clue about it. Your last question is nonsense (why don't those companies just not build on Eclipse instead of making new IDEs? Has it occurred to you that maybe it is because they want to make a new program?). Programs like Eclipse don't offer even a tiny fraction of the features that I use GNU Emacs for every day, and I only use a small fraction of the different GNU Emacs features and packages.
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.
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.