The author also wrote the "kitten" programming language which also has been talked about on here as well back in 2017:

https://news.ycombinator.com/item?id=13345832

Om is a novel, maximally-simple concatenative language - https://news.ycombinator.com/item?id=33382397 - Oct 2022 (49 comments)

Stem, an interpreted concatenative programing language - https://news.ycombinator.com/item?id=39151094 - Jan 2024 (74 comments)

A Simply Arrived Concatenative Language - https://news.ycombinator.com/item?id=15576215 - Oct 2017 (21 comments)

Factor: A Practical Stack Language - https://news.ycombinator.com/item?id=32215048 - Jul 2022 (45 comments)

Xs: a concatenative array language inspired by kdb+ and FORTH - https://news.ycombinator.com/item?id=23437003 - Jun 2020 (27 comments)

Cat: a statically typed concatenative language - https://news.ycombinator.com/item?id=24534755 - Sep 2020 (13 comments)

8th: a secure, cross-platform, concatenative programming language - https://news.ycombinator.com/item?id=15672361 - Nov 2017 (59 comments)

Programming in the Point-Free Style - https://news.ycombinator.com/item?id=14077863 - Apr 2017 (101 comments)

side effects are quite the thorn in this theories side. hard to describe message passing in purely applicative terms.

    main = do
      let
        hello = foo world
        world = bar hello
      putStrLn $ show hello
      putStrLn $ show world
     where
       foo v = [v]
       bar v = length v

Modern programming is. But look at assembly, which is what actual machines do. And you can write assembly with tons of gotos and not a single function in sight.

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.

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.

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 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.

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 write code in both and they seem pretty much equally powerful to me.

There are two big differences for me:

1. If I look at Forth code I wrote a month ago I have no idea what it's doing. This is never a problem with Lisp.

2. I can -- and have -- written a complete Forth compiler bootstrapping my way up from assembler. Sounds like you've done the same thing. I could never bootstrap a Lisp compiler that way.

> Forth and other similar languages write-only

If you see write-only Forth programs, that's probably because they are poorly written, or maybe you are not familiar enough with Forth to read them.

> is that you can easily lose track of the variables when you are forced to toss them all on a stack

You don't "have" to keep everything on the stack in Forth any more that you "have" to allocate everything on the heap in C/C++.

A Forth programmer who is not a dilettante will look for the data which is used throughout the program (e.g. a file or device handle, a memory address) and put it in a (global) variable.

This eliminates most of the stack juggling and your definitions generally use no more than 2 arguments, so it's easy to tell what they do by looking at them.

This is mostly a problem of concatenative language design. There is nothing preventing function definitions from having type signatures that are statically checked. In my concatenative language compilers, I always provide a function that causes the compiler to halt and print out all of they types on the stack at the call site during compilation as well as a runtime function that prints out the runtime values. I have found this to be quite effective for debugging. Because I don't support global variables, these functions give a complete view of ALL of the live values at any point in the program, which is quite hard in most languages.

Local variables are also not necessary to have reasonable ergonomics, even in mathy contexts. Instead, the language can define special operators that access fields on the stack by type name and move or copy them to the top of the stack. For some reason, in the math example, the author deliberately added an unnecessary parameter that had to be dropped and put the arguments in the wrong order. Cleaning up the signature, there are several reasonable ways to solve the problem in a concatenative language with the features I've described.

    type n number
    type y n
    type x n
    def op_math_example [(y x) -> (n)] \\x * \\y \\y * + \y abs -

where \FOO moves a value of type FOO to the top of the stack and \\FOO copies the value to the top, leaving the original where it was. Yes, the \\ is a little ugly, but these should generally be used sparingly.

Even if we restore the original signature and use the author's syntax, there is a much cleaner solution to the problem without the move/copy operators.

    def sq dup *
    def op_math_full drop swap sq over sq + swap abs -

This is extremely cryptic. I suspect most forth programmers would have added a stack signature comment, but it is even better if the compiler statically verifies the signature for us, which is how the language I am describing differs from vanilla forth (where stack comments also have the risk of being wrong in an evolving system). If we restore the type system, it becomes:

   type n number
   type x n
   type y n
   type z n
   def sq [(n) -> (n)] dup *
   def op_math_impl [(y x) (n)] sq over sq + swap abs -
   def op_math_full [(x y z) -> (n)] drop swap op_math_impl

Of course it is still not as obvious to the reader what op_math_full actually does as (y * y) + (x * x) - abs(y). But in practice it would have some name like projection_size so once it has been written correctly, it doesn't really matter that it is a bit obscure to read at a glance. You also get really good at simulating the stack in your head and they type signature makes this much easier. Still, when you are confused, you can always add stack debugging like so:

    def projection_size [(x y z) -> (n)] drop swap PRINT_STACK sq over sq + swap abs -
    1 2 3 projection_size

and the output would be something like:

    ({ y 2 } { x 1 })

Writing programs in this style is very nice so long as you have enough tooling to facilitate it.

I have only used concatenative languages that I have implemented myself, however. I have read quite a bit about forth, but for me, there are clear problems with vanilla forth that are solved for me with the meta operators like [, [[, \ and \\ as well as good debug tools like PRINT_STACK above. Forth was an incredible discovery for its time. We can do a lot better now.