Rather, the key characteristic is that there is an important implicit feature available, namely the stack (or, as for example in the case of PostScript, several stacks), by which arguments can be passed along.
As a consequence, you get a form of compositionality of language elements that is not available in languages that lack this feature: A language element may consume, change and create entities on the stack, and the next language element can pick them up implicitly.
This often allows very concise and elegant code, and can also be interpreted very efficiently.
Presented by way of being an interesting link, and the educational nature of reading the best arguments in favor of something. I haven't done anything in concatenative programming in about 20 years, since I left math class and didn't need my HP 48G anymore.
So, for instance, let's elicit an error using Ghostscript, a freely available and efficient PostScript interpreter:
$ gs
GPL Ghostscript 9.27 (2019-04-04)
...
/f { /hello g } def
Therefore, when I then invoke "f" via:
GS>f
Error: /undefined in g
GS<1>pstack
/hello
[0]: https://groups.google.com/d/msg/rec.arts.int-fiction/HNtntxC...
PostScript is a real programming language and can be used for many things (especially graphics). I also wrote a JSON parser in PostScript (see message <[email protected]> on comp.lang.postscript), and then someone else post their JSON parser in PostScript too.
I think PostScript isn't such a good protocol or document format, but it is good as a programming language. It is what I might use if I want to make a diagram (but unfortunately Ghostscript cannot produce SVG output; it can output PDF though, as well as many raster formats).
Someone was unsure how useful would be the JSON parser I wrote in PostScript, but if you want to print some diagram based on data in JSON format, then it can be helpful.
(I could implement Z-machine in Forth too if I wanted to do, but I have not done so yet because I have other things to do; I don't know if I might do so in future or not. I could implement Z-machine in any programming language with byte arrays, including assembly language (I started but haven't finished one in 6502).)
is a fractal fern. This is page description, but not in the normal way that it's used. Compare the output in a PS or PDF viewer with the source code which is under 1.5K.
But I think maybe you meant in the sense of "in the real world", and I can't think of any examples. Prefixing some postscript to a document to manipulate that file is something it can be suited for, rather than using an external language to do so.
https://www.cs.bham.ac.uk/research/projects/poplog/primer/#s...
Functions that return several results, implicit parameters, open stack, etc. It's a lot of fun.
1. Push the literal 2 onto the stack
2. Push the literal 3 onto the stack
3. Execute the Plus Operation
Therefore, there is no need to use a compiler, or even Dijkstra's shunting-yard algorithm[1], to reorder the statements for execution. This makes it extremely easy to write a compiler or interpreter for a stack-oriented language with postfix syntax: you never have to do any parsing at all, you just execute (or emit byte code) for each token as it comes, never needing to look forwards or backwards even a single token.
I would say that RPN is part of a paradigm - and if you pardon my bias I would say the Forth paradigm, really. The stack is part of a strategy of complexity reduction that start at the compiler/interpreter level.
A core question, though, is why? Is tab-oriented programming have a wikipedia page where programs are written predominantly using tab stops instead of spaces? It's honestly a very similar sort of distinction to make.
1. I'm trying not to stray too far into all turing complete languages are turing complete and thus difference is meaningless land.