Re: [stack] Jon Purdy: Why Concatenative Programming Matters

eas lab <[email protected]> wrote:
> This commentor appropriately acknowledges the important cognitive-load aspect:-

Indeed.

> ]the code was always *intensely* write-only since you had to have a
> ]mental model of exactly what was on the stack where to even hope to
> ]follow it.

He's talking about HP RPN code -- fairly low-level code. It's not
entirely fair to attribute cognitive load to stack code when most of
it is due to bad language design.

> *nix piping is beautifully simple yet powerfull, since the stack only contains
> "it" [the previous output]. So that at each/every stage, you only need to know
> about your single-supplier.

True for pipes. Not true for programming in general -- you need more
than one data item per function call.

> Apparently, if the output of stageN includes item/s in addition to what
> stageN+1 needs, they can be left on the stack for stageN+2. But he and
> Haskell/monads seems to 'wrap' the extra item/s and pass it on, and
> imply that some automagic relieves you from the mental load of
> remembering what was left on the stack for all possible
> combinations of stages afterN+1 ?

Haskell would be a fine language to learn; it gives a large reservoir
of concepts to discuss language design.

But no, monads don't relieve your mind; they tend to require a lot of
careful thought, especially if you start mixing them. They have
interesting mathematical properties. You can implement a concatenative
language in Haskell using monads; the stack language is a monoid
(well, according to von Thun).

-Wm