Hacker News Reader

Comment by progman | Hacker News Reader

> Forth is not powerful. It is ugly, stupid and mean.

That's a statement of someone who doesn't understand Forth. Of course, one can write ugly code easily. Any language with raw power (Asm, C, Forth, Ada) needs a disciplined developer to get beautiful and maintainable code. Forth code can be really beautiful if the vocabulary is well thought out.

I consider Forth the best choice for tiny iOT devices, Firmware, and other essential things which can be kept simple and stupid, following the KISS principle which works very well in many cases.

Our vastly proliferated software security problems come from complexity which developed by despising the KISS principle. Many developers didn't choose the simplest way, they chose the most convenient way. Now, we realize that keeping things simple and stupid is not that bad after all.

View on HN

I've written a standalone Forth system that could boot from a floppy and recompile itself. I've ported the core interpreter to C so I could use libraries. I've rewritten it using various threading techniques. Up to that point it was just toy systems because i never did something useful with those. Then I rewrote a Forth interpreter than would play really nice with C. That thing right now is around 30k/3KSLOC. This time I wrote various utilities I needed for my job using it. One of them is a log server that runs 24/7 that provides web interface, and I consider making it send emails... So I think I do understand Forth a little bit.

Doesn't your latter post contradict your previous post? If Forth is not powerful how did you manage to do such things with Forth, and why did you stay so long with Forth despite its "ugliness" and "meanness"?

"powerful" too often means "it does things I don't really need or that I don't even understand; but hey, I might use them someday" - or at least that's how it sounds to me.

"ugly, stupid and mean" is actually intended to the beginners or to those who want to try it. That's what most systems are out-of-the box, especially for the minimal ones (bigger systems like gForth might be a bit better).

That's their starting point. R> and R> are hideous so at one point they'll want to replace them with "pop" and "push". Stack juggling looks bad so they'll have to learn to minimize them. And they'll have to get used to RPN. There's no GC and not even heap allocation (unless ANSI-Forth added it as an extension since the last time I checked?), so they'll have to deal with the lack of memory management that are in every other high-level language. There's neither static nor dynamic type checking so they won't get any warning if they dereference a character. Instead, it will crash again and again without any stack trace.

So they'll have to deal with all this ugliness, stupidity and hostility that they won't expect "enough" because Forth fans praise it often without a warning about the fact that it takes a really long time to fully tame such a rabid language.

Why did I stick with Forth for so long? I made it progressively more beautiful for me; I learned to fight complexity and factor, which indirectly prevents mistakes; I implemented warnings in my system for mistakes that are hard to find (e.g. a redefinition) and are easy to check for.

> "ugly, stupid and mean" is actually intended to the beginners or to those who want to try it.

When I encountered Forth first (6502 figForth) I felt it quite convenient. At that time there were only two other options - Basic and Assembler. Maybe that most developers today are too pampared by all the available IDEs for other languages. It's the same attitude why so many people stick with Windows instead of learning OSX or Linux, despite all the flaws of the Windows ecosystem.

> lack of memory management that are in every other high-level language

As already mentioned, I consider Forth suitable for tiny systems, iOT, Firmware etc. I would never use Forth for big software. I would not use even C++ for that. In that area Ada, Rust or Nim works much better for me.

Forth is an amplifier. Bad programmers will write very bad programs, good programmers will write very good programs.

Reply on news.ycombinator.com