Hacker News Reader

Comment by pmarreck | Hacker News Reader

Do most people tend to conclude that concatenative languages are absolutely an intellectual curiosity for any nerd who knows RPN and thought "what if we kept going?", but kind of fail in larger-scale production contexts?

(Yes, I'm aware of PostScript... Seems to be one of the sole exceptions here... And, uh, PDF... of course...)

View on HN

The odd thing is that RPN is actually pretty intuitive for people. It's the "language" of cash registers! I had never used cash registers, and I lent my HP rpn calculator to my girlfriend to use. I said it's a bit weird, do you need help.

She gave me the dirtiest "are you mansplaining me" look.

Using the HP was perfectly natural for her as she had used cash registers.

The Open Firmware bootloader also used a Forth as its command-line interface. That was used on PowerPC Macs before Apple switched over to Intel. (So, you know, two processor architectures ago.)

A common theme is that Forth-likes are very easy to implement on constrained hardware. I have a Strange Loop talk a couple of years ago where I go into this at the end, calling out uxn from the Hundred Rabbits folks. You might consider that more "hobbyist" than "production", but people are deriving real joy making apps and games in that ecosystem.

https://dcreager.net/talks/concatenative-languages/

https://100r.co/site/uxn.html

For a counterargument, this is the most commonly cited argument that I've seen _against_ using a Forth-like in an industrial context:

https://yosefk.com/blog/my-history-with-forth-stack-machines...

I think the fundamental flaw is:

> It is considered good functional programming style to write functions in point-free form, omitting the unnecessary mention of variables (points) on which the function operates.

This is wrong.

It may be considered good programming style in certain small use-cases when a small local composition is clearer. But as a general software engineering principle, the exact opposite is true: It is considered good style to break larger constructs into smaller pieces and give them meaningful names.

There's no reason that function parameters should be an exception to that and in practice, names for function parameters are often some of the most critical names for understanding a system.

I think concatenative languages are really cool as a mental exercise in getting a lot of power out of something simple. But as far as why they aren't used in practice. I think it's largely because they are a bad idea carried to its logical extreme.

I’m pretty sure the programmability of PostScript was a mistake. Adobe clearly thought that because most of it was removed from PDF.

I was working in sales/support/marketing for printer companies in the eighties and people were buying PostScript printers for the scalable fonts, device independence and compatibility. The most common objection was performance which was somewhat related to the programmability.

We used to supply the red and blue books with each printer but I don’t remember anybody breaking the seal on them.

Having said all that I have spent the last year writing a PostScript interpreter.

I’m not sure I’d call PDF concatenative, you certainly can’t cat two PDF files together to make a merged document. There are header and footer sections to deal with.

> I’m pretty sure the programmability of PostScript was a mistake. Adobe clearly thought that because most of it was removed from PDF.

I do not agree. I think the mistake was using PostScript as the output document format, not its programmability. PostScript should be the input format and not the output format.

I think PDF has many problems and is badly designed in many ways, though.

PostScript is a bit like .Net CLR or WASM: while widely used, it's basically never written by humans directly.

Forth is a wonderful way to build a high-ish level self-contained programming environment on very low-resource hardware, like a 8-bit MCU. But thinking in terns of the stack is useless mental gymnastics, this is something a machine should do instead.

People do write in PostScript directly (and I have seen .NET and WASM code written directly, too). I use PostScript directly and so do some other people.

Absolutely. Years ago writing programs for *BSD/Linux, PS was the natural, most direct way to implement printing to printers equipped with a PS interpreter.

Fortunately the PS language was very well documented. That made writing PS pretty straightforward, at least for the reasons I was using it. Curiously other concatenative languages have been harder for me to grasp. Maybe that's because I regarded PS as a specific-use tool vs. a general purpose language.

If nothing else PS showed the value of excellent documentation. Lack of it probably accounts for many software project failures, particularly in the open-source world.

You can also run PostScript programs on the computer; you do not need a PostScript printer.

> Maybe that's because I regarded PS as a specific-use tool vs. a general purpose language.

In my opinion, it is both. Many of the programs I write in PostScript do not involve a printer at all.

> If nothing else PS showed the value of excellent documentation. Lack of it probably accounts for many software project failures, particularly in the open-source world.

I also find a problem with many programs that do not have good documentation. When I write my own, I try to provide documentation.

From what I can tell the mental gymnastics are leaning how to think in terms of Forth instead of how to think in terms of the stack, which is the stack effect and not the stack itself. You only think about the stack itself with your base words (when stack and stack effect are essentially the same), after that it is the stack effect; a single word may push and pop thousands of times but you don't need to think about that, just make sure that it leaves the stack (or stacks) in the state you want it (them). Once you have built up a few layers from the base words I find it more like having a single variable which you store the current state in than a stack, so functional stateless programming but with a tiny dash of state?

There are mental gymnastics but they are far from useless and not just thinking in terms of the stack. I don't quite have it down yet but I am getting closer and can see the sense in it, I haven't quite figured out how to plan and structure a program in Forth.

Reply on news.ycombinator.com