Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Stack-oriented programming is a pretty non-widely used paradigm (well, PostScript gets used under the hood a bit here and there). This in mind, what problems are stack-oriented languages good at? What would they do better than [paradigm] does? Also, for what problems are they a bad choice?
Is stack-oriented programming just a niche paradigm?
The main problem with stack-orient programming languages is that they are conceptually quite difficult for humans to understand. The advantage is that they are very easy for computers to evaluate and generate.
Which is why it was chosen for PostScript. It wasn't that long ago that printers only had a very small amount of memory and very under-powered CPUs. So giving them programs in a language that was easy to interpret and also easy to generate, you didn't require a super-computer inside your printer to evaluate.
Also keep in mind that many languages today, while not stack-oriented themselves, actually get compiled down to stack-oriented bytecode (think Java and .NET). Again, the reason being that stack-oriented processing is very easy for a computer to reason about.
Thorbjørn already made the point about compilation - if I remember correctly, Java bytecode is an example of a stack-oriented language. Though this isn't universal. LLVM uses a "static single assignment" thing which certainly has a stack, but in which local variable accesses and expression evaluation use a kind of write-once-then-immutable virtual register model. For mutable data, these things basically hold an immutable pointer.
Anyway, a stack-oriented language can do anything that a Lisp-like or ALGOL-like language can do, computationally speaking. The stack may even have implicit metadata, doing things roughly equivalent to the type inference in ML, for instance - evaluated at compile time, without doing a single run-time push or pop.
The real issue is readability, so the question is which of these do you find more readable...
a * b + c * d
(+ (* a b) (* c d))
a b * c d * +
In principle, the Lisp-like prefix thing could be done without parentheses - but would have to use a fixed number of arguments per operator (just like postfix and infix) to do it. I think there's some truth in the old "Lots of Infuriatingly Stupid Parentheses" joke, but that could be avoided while still keeping the operator-comes-first ordering. In other words, you could write a compiler that would accept...
+ * a b * c d
On what is most readable, that is clearly debatable. Infix is more familiar for newbies, but it doesn't take much to get comfortable with any of those forms.
Personally, I'm not even convinced this counts as a paradigm. It's just notation, with little or any semantic impact. For example, all three forms could be handled using a Yacc grammar - all three using precisely the same AST form, so that the semantic analysis and code generation doesn't even need to know whether the syntax appears to be "stack oriented".
EDIT
Oops - I think the basic point is above, but I guess I should explicitly state my answer. Which is basically that IMO there isn't any particular problem that favours any of those notations. People may favour one or another, but that's a different thing.
What Lisp programmers will point out, though, is that metaprogramming works quite well with a Lisp-like notation. That's more about the parentheses than where the operator appears, though - a variant of Forth that allowed...
(1 2 3 4 +)
... would be just as good. The benefit either way is the simple notation to manipulate using code - the same reason that stack-oriented intermediate languages (bytecodes, etc.) are popular. Though arguably, manipulating the ordering-agnostic AST form can be done fairly easily too - that's kind of what pattern matching does in Haskell and ML.
EDIT - A clarification...
Using a postfix/stack-based form means just that. For example, it doesn't imply any change of argument order. The following examples can all be equivalent, other than the syntax used to express them...
(< 1 2)
(1 < 2)
(1 2 <)
Note - there isn't any need to swap the order of the 1 and 2 just because the operator is postfix
(if (< a b) (handle a_smaller) (handle b_smaller_or_equal))
((a b <) (a_smaller handle) (b_smaller_or_equal handle) if)
((a_smaller handle) (b_smaller_or_equal handle) (a b <) if)
Maybe you'd want to keep the condition near the if, maybe you wouldn't. Either is fine.
Forth doesn't express an if either of these ways, but there isn't any reason why a postfix/stack oriented language can't do so. Forth only allowed integers on its stack (at least originally), but Lisp allowing side-effecting expressions to be passed as parameters has nothing to do with being prefix rather than postfix. A postfix language could allow code to be passed as arguments (that is, pushed on the stack) too.
a b * c d * + was exactly what I would type for years.
Oct 1, 2012 at 3:30
I've used a few stack-oriented languages over the years.
At university, I had some fun confusing system administrators with tiny PostScript programs which seemed to take an in-ordinate amount of time to render just one page of output. Yes, the laser printer we had access to had more floating point power than the mini computers we were given accounts on, so it was great for doing mandelbrots.
I also worked with transputers. These were processors which were highly optimised for performance per transistor. Every bit of silicon needed to pull its weight, so it had a Huffman encoded instruction set (the most common instructions were coded in a single byte) and rather than having traditional register set it had a pair of stacks. One stack was low priority, the other high, which meant that it had a context switch time (low priority process to high) measured in microseconds rather than milliseconds - great for fast interrupt response in the robot controllers we made.
I also worked on some robotic systems which used embedded Forth processors which ran Forth pretty much like machine code. I remember that we would buy twice as many CPUs as we needed and bin them according to performance, selecting the best half to put into systems, that's because it was cheaper to buy several un-rated chips than buy a single chip rated at the speed we needed them to run at. *8')
Forth is almost dead, I think. There is J, however, I don't know whether it has a notable influence. Postscript is not really used for programming by humans, is it? So I'd say, stack oriented languages virtually do not exist anymore.
As far as I see it, they are good as replacement for assembler on stack oriented hardware architectures. Firmware and such stuff. But I am not sure if such hardware exists anymore in the post 16-bit processor area.
