[massung]

Forth is awesome. Simple as that. But it's important for people (especially those just being exposed to it) to completely understand why, and what it's done for everyone.

The indirect threading model was absolutely brilliant. Almost every bytecode VM in existence today owes Forth (and Moore) a giant "thank you." If you never write a lick of Forth code ever, you'll be a better programmer just by researching how its put together.

Forth also pushed for simplicity before it was fashionable. Most "modern" languages pride themselves on their landing-page code samples:

sum = fold (+) 0

But, again, this is old hat for Forth programmers. Languages today use a lot of great, new ideas to accomplish this: FP, pattern matching, closures, etc. But Forth was pushing - back in 1970 - for all functions to "do one thing" succinctly. If it can't be done in one line, you needed to factor the code some more. And, it's not just that the result is one line, it's that _anyone_ can look at it and know what it does instantly. Remember, this was back when BASIC and FORTRAN ruled with GOTO.

Finally, I feel that Forth programmers learn - early on - something I don't see many (very good) programmers learning today: instead of constantly abstracting and obfuscating to try and "simplify" a solution, take a step back and try and simplify the _problem_ so the solution is obvious. For example, this is what I feel the Rust team has done with memory management. Instead of just throwing more brain cells and cycles at trying to improve old-hat solutions, turn the problem upside-down and - in essence - remove it entirely.

[dewster]

>Almost every bytecode VM in existence today owes Forth (and Moore) a giant "thank you."

Funny, I see bytecode VM as one of the things that's fundamentally wrong with computing. It's one more layer of unnecessary crap that doesn't even remotely resemble the underlying hardware.

[vanderZwan]

> that doesn't even remotely resemble the underlying hardware.

And that is what makes the code portable and re-usable. See also Rob Pike's Eulogy on Dennis Ritchie[0], where he explains the true strengths of C and Unix:

> In the late 1970s, Dennis joined with Steve Johnson to port Unix to the Interdata. From this remove it's hard to see how radical the idea of a portable operating system was; back then OSes were mostly written in assembly language and were tightly coupled, both technically and by marketing, to specific computer brands. Unix, in the unusual (although not unique) position of being written in a "high-level language", could be made to run on a machine other than the PDP-11. Dennis and Steve seized the opportunity, and by the early 1980s, Unix had been ported by the not-yet-so-called open source community to essentially every mini-computer out there. That meant that if I wrote my program in C, it could run on almost every mini-computer out there. All of a sudden, the coupling between hardware and operating system was broken. Unix was the great equalizer, the driving force of the Nerd Spring that liberated programming from the grip of hardware manufacturers.

> The hardware didn't matter any more, since it all ran Unix. And since it didn't matter, hardware fought with other hardware for dominance; the software was a given.

[0] https://plus.google.com/u/0/+RobPikeTheHuman/posts/33mmANQZD...

[dewster]

The true strength of C is being a good fit to the underlying hardware.

And hardware still very much matters, even if it's running Unix, because of binary compatibility.

I still don't get the VM thing. I mean, I get it from a portability standpoint, but in practice it's been a pretty horrible thing because a stack machine of all things is often picked as the virtual target. Why not a generic register based machine, like most hardware actually is these days? My feeling is the people doing the implementing are infected with the Forth virus, and a stack based VM is one of the few ways they can force their crazy ideas on the rest of us.

[vanderZwan]

You do understand that hardware development has been shaped by C being the defacto standard low-level language? That is, if new hardware isn't easy to code for with C it has little chance of it catching on, unless it's so incredibly low-level and minimal that ASM is the most complicated language you need.

And while I'm no compiler writer, I suspect stack machines are a great choice for modelling an intermediate language because converting it to optimal register use is fairly simple, yet at the same time is completely agnostic about how many registers an underlying machine has.

[dewster]

>You do understand that hardware development has been shaped by C being the defacto standard low-level language?

No, I don't understand that, and honestly have no clue what you're talking about. C is about as simple as things come, and it doesn't necessarily make strange demands on the hardware. It may seem that I'm contradicting my previous statement, but C working well with hardware doesn't necessarily mean it is a force for shaping modern hardware.

Three operand register-based load / store machines make too much sense from a variety of angles for many (any?) other configurations to touch them, that's why they're everywhere.

Stack machines are inherently less efficient, and you only see a bunch of designs (mostly as amateur soft cores) to this day because they are almost trivial to for enthusiasts to implement, not because they kick ass.

[vanderZwan]

> No, I don't understand that, and honestly have no clue what you're talking about.

Clearly.

https://en.wikipedia.org/wiki/Lisp_machine#End_of_the_Lisp_m...