←back to thread

210 points JoeDaDude | 1 comments | | HN request time: 0s | source
Show context
tombert ◴[] No.42207795[source]
Forth has been something I've wanted to learn for years now. It seems weird to me that for most stuff in old computers, you have the option of "assembly" if you want your program to be fast, and "BASIC" if you want your program to be slow, but Forth lingers along as the "medium speed" language, despite at least looking pretty high-level.
replies(7): >>42207863 #>>42207931 #>>42208026 #>>42209557 #>>42210559 #>>42213720 #>>42213966 #
FuriouslyAdrift ◴[] No.42207863[source]
Forth was the standard language for hardware development and drivers (along wiht C) for a very long time (still is used all over). Stack based.

https://www.forth.com/starting-forth/

replies(2): >>42207922 #>>42208085 #
tombert ◴[] No.42207922[source]
Yeah I knew that, that's why I've found it interesting.

It looks a lot more high-level than something like C, but is used in similar spaces, which makes me wonder why it never really became more popular.

replies(1): >>42208622 #
selvor ◴[] No.42208622[source]
It may look more high-level than something like C, but it is actually no more high level than a macro assembler with registers eliminated. As there's no syntax tree, essentially every word that is parsed from the input stream is replaced with a subroutine call. So the resulting FORTH code is nothing but a series of subroutine calls.

In my experience quite often writing in assembler is easier than FORTH unless you have a strategy and self discipline, which when acquired makes one a whole lot more productive than using assembler, and arguably more so than a high level language. There're no pointer arithmetics, no rudimentary type checking, not even an array type (you have cells and addresses). There is nothing that throws an error except things like stack over/under-flow checks, and if you are lucky your code will crash. If not debugging can be tricky. Stack imbalances won't be reported/checked for you, there is no bounds checking for anything (not even structs). But there are conventions/strategies to prevent these kinds of bugs from happening that one needs to either discover for themselves, or find out in books (the book Thinking Forth helps, but is not enough I would say).

Working with the stack can be more difficult than with registers, although the latter can be easily simulated with variables, which is often frowned upon. But words like CREATE ... DOES> enables meta-programming that helps with generating code with code, and makes it quite powerful, but can make your code complicated to reason about (see the concepts of compilation vs. execution vs. interpretation semantics described in ANS Forth).

In the end the appeal of FORTH for me is in its "simplicity" (but nowhere any ease of use as it requires mastery of laying out code in memory as you would do in an assembler without any help from the language itself), its overall philosophy (see Chuck Moore's A Problem Oriented Language) on focusing on the nature of the problem rather than thinking in terms of the tools/language given to you (build a "language" for the problem), and providing solutions with as minimal "cruft" as possible.

replies(3): >>42209019 #>>42211960 #>>42212494 #
1. sph ◴[] No.42211960[source]
> Working with the stack can be more difficult than with registers, although the latter can be easily simulated with variables, which is often frowned upon

Yet every time I hear experienced Forth developers recommending to use more variables, and that newbies tend to eschew them, making the code much harder to read and understand than it is necessary.

You become a true Forth programmer once you go past the code golf and stack juggle phase.