[dewster]

THE central problem with pure stack machines and stack languages:

The programmer knows in their heart that moves, swaps, dupes, drops, etc. - any stack manipulation that doesn't involve a functional change to the data itself - is an inefficiency to be minimized, but this effort isn't in any way related to the problem at hand (writing a program to do something) so it's unwelcome mental overhead.

I like puzzles as much as the next person, but not so much when they seriously impede the solving of a bigger more serious puzzle, nor when the sub puzzle solving is an exercise in the minimization of something bad rather than the elimination of it.

[coliveira]

Traditional languages are pushing and dropping data from the stack every time a function or procedure is called, they just give it another name: parameter passing. Making it explicit, at least Forth tries to reduce the need of copying things from the stack to local variables.

[dewster]

I don't think the stack in a traditional languages is the same as stacks in stack machines and languages. It's a lump of memory that gets allocated to a thread for stuff, and the allocation is indeed done in LIFO fashion, but I believe access to individual memory locations in the allocation is random. Name is the same, LIFO and all, but the mechanism granularity makes it quite different.

[coliveira]

It is true that traditional languages lump local variables and return information in the same stack. But the difference is only in the way this is handled by the program. In traditional languages the programmer has no idea how parameters are passed in the stack and the compiler does everything. In Forth this is made explicit, but on the other hand there are no formal parameters to worry about (notice that Forth can use local variables if you want, it is just not the idiomatic way).

[fasquoika]

If you're programming in Forth and you find yourself doing lots of stack manipulation, you should at least consider using local variables. Once you accept that there will be times when variables make more sense, you'll be surprised at how infrequently you actually need them.

Edit: Be aware however, variables dramatically reduce composability (in any language actually, most just aren't very composable to begin with). By using local variables you essentially turn a procedure into a monolithic block

[dewster]

Pure stack machines don't have local variables. They have at most two stacks and that's it.

[fasquoika]

I was under the impression we were talking about Forth, not a pure stack machine

[dewster]

Both. And under the hood, Forth implements a virtual stack machine on top of a non-stack machine, which is inefficient.

I guess I'm just trying to counter all the mythos and happy talk surrounding Forth and stack processing in general. In the end Forth is a highly (too?) simplistic language, a product of its time, and nothing all that special or powerful. It does a lot of stuff poorly and the code tends to write-only. The syntax is so loose that the entire dictionary has to be searched to know you're dealing with a number. It's no mystery that we aren't all coding on it now.