Hacker News Reader

Comment by whobre | Hacker News Reader

I am under impression that more people implement Forth than use it for programming...

we used FORTH extensively in the bring-up of the Atari ST. it was easy for the hardware engineers to come up with little fragments of FORTH so they could exercise their chips without needing much support from the software team

FORTHs are fun to write. they'll teach you a lot about ruthless simplicity

i don't think FORTH is useful for large programs, but that's not the point of the language

Why is it not useful for large programs (if you keep your words small)? What about Factor?

Large programs mean lots of word definitions and essentially writing a DSL, most are not going to document that DSL well enough to make the code readable to anyone else and how many people want to learn a weird adhoc language myopically designed for building one program? I love Forth but it mostly died for good reason. Once you learn its workflow and develop your dictionary it is incredibly quick and easy to use but it will be a chore for anyone else to understand and work with.

So if it is documented well, then it would be suitable for large-enough programs? Or do you have any tips?

I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massive changes to the DSL you designed which also means changes to the program you are using it to write.

DSL is probably not quite the right word, it could be but generally I think it is still going to be fairly Forth like, but you need to think of it that way. You layout what your program does and then reduce it to a few dozen words which work as a description language for the program, then maybe a 100 more words which those words require along with any glue and together all constitute a reasonably sane language. Then you start from the bottom up and implement all those words. The big trick is having the foresight required to pick the function of each of those hundred odd words well enough that no one will ever have to dig into the the 1000 odd words below that it took to implement them. It really forces you to think about how your program may evolve and the bugs which may crop up, you can't change one of those low level words without affecting all that are built on it and if you do the easy work around things start to get messy.

Not sure how well I explained that, I am no Forth expert but I am getting better.

That's a nice take. Implicitly though, that implies treating words not as functions but as coupled routines, possibly because forth is untyped.

If anything goes wrong during development you need that model of the stack in your head to debug- I think that's the main differentiator, and if you had a typed forth with local variables, it would enable greater readability ie. I can scan the individual words/ functions without needing that stack model.

Just my POV, not sure if that resonates?

Forths can have local variables, both ANS Forth and gforth have them and if your forth does not have it you can make your own or possibly just include gforth's if your forth is compatible. Keeping track of the stack becomes second nature and all but the simplest implementations have great tracing and debugging if you get lost.

Forths can also have types but it is slightly different, gforth has a float stack with its own commands and you can implement others and any other feature you want.

Once you get used to working global and without type it gets surpringly easy, it is more difficult for me to work with type and scope than without and when I use something like C I am constantly fighting it and feel like erything is needlessly complicated.

There's no compile-time error checking and words can push/pop arbitrary amounts of data to/from the stack. This means that if a program grows beyond the point where you can keep the whole thing in your head, it's a nightmare to maintain since bugs like giving a word the wrong number of parameters can cause a cascading series of errors that's challenging to unravel. I don't think it's a coincidence that Forth advocates have a philosophy of "if a problem's too complex, redefine the requirements so you can fit it all in your head". Personally, while I find Forth fun to write trivial programs in, I would rather write nontrivial programs even in assembly than in Forth.

There is in Factor, though!

https://github.com/factor/factor

https://factorcode.org/

A great article about why this might be: https://yosefk.com/blog/my-history-with-forth-stack-machines...

It's a great exercise as a programmer to implement a language, Forths and Lisps are popular choices.

It greatly helps conceptualizing computation and what's truly essential at it's core.

there's a myth I know where the true Forth enthusiasts end up making their programs so pure that they start needing their own special hardware (in one version, I heard that machine words were all 13 bits), their own networking stack, their own communication apps. Until eventually they transcend into a second internet, populated only by forth hackers, where everything is optimally elegant.

and that's why we don't hear from them anymore

[Drinks] O true apothecary! Thy drugs are quick. Thus with a KISS I die. [Dies]

((One W. Shakespeare Romeo and Juliet.))

That's okay, it's a fun thing to do!

I always joke that forth doesn't actually exist. The only forth code that seems to exist is forth implementations.

That's kind of by design, and it's why the standardized ANSI forth sucks. It will often be simpler to rebuild the language on your system the way that works for you, than to hammer a generic forth into what you need.

It is educational thing to do. Like Lisp as well.

With Lisp you have beasts like Guile and Guix with Scheme and with Common Lisp, Maxima, Nyxt and even weird stuff like K3D or whatever was called where you could build 3D scenes while programming. A la PovRay, but with Common Lisp and in-place editing instead of batch rendering.

Reply on news.ycombinator.com