Re: [stack] Advantages of cat, joy ..?

If you're looking for something useful, this list probably isn't the
right place to go. Most of the discussions are about theory that
doesn't get anywhere, and most of the people who post don't actively
program in concatenative languages; they just implement interpreters
for them.

I find that one particular concatenative language, Factor, makes me
personally very productive. Some of the advantages come from the fact
that Factor is concatenative, and some come from the great
organization of the Factor libraries and class hierarchy. From being
concatenative, we get a nice, clean point-free data flow (cleaner than
Forth because some combinators help with data flow) and the ability to
factor things out very easily. It's also nice to have a simple,
easy-to-understand left-to-right evaluation order.

As far as Factor-specific features go, Factor is a dynamically typed,
garbage collected language with object oriented features and a
well-developed set of libraries for practical things like HTTP, SMTP,
Unicode and XML. Factor also shares some particular advantages with
Forth, eg extensible syntax with a simple parser. (If you don't like
Forth syntax, though, I guess you won't like Factor syntax.)

As far as knowing the "algebra" of concatenative languages goes, it's
something interesting but I don't find it useful in everyday
programming. Stack code is pretty easy to analyze automatically (which
can be useful for certain macros, like a pattern matching library I
wrote) and to generate (as Factor's Lisp-like macros do, sometimes
with fairly complicated data flow).

Dan

On Mon, Feb 16, 2009 at 7:17 AM, chris glur <[email protected]> wrote:
> Since I started reading this mail-list all I've got is:
> 'look ma I can wear my cap backwards;
> and you can turn it inside out;
> and if you turn it to the right and march north,
> it points in the direction, where the sun rises,
> which will tell you approximately where the sun sets'.
> So what ?
> What the point of it all ?!
>
> What I've been hoping for is pointers to increased
> productivety, based on:
> * we naturally want to be more productive;
> i.e. acheive more output with less effort;
> * computer programming is constrained by human
> attributes, eg.
> A. the 7+-2 rule, and
> B. 'recognition is easier than remembering';
> * etc. - this is psychology, not compt-science.
>
> Which leads to facilities which aid productivety eg.:
> * any thing that helps reduced the mental clutter,
> by chunking several items together into a single
> idea: subroutines, data structures ...OOP.
> * since we've spent a life time reading, lets
> use this honed skill and have mnemonic IDs.
> Although java's verbosity can overwhelm.
>
> The coming productivety increase I'd
> hoped for is formal methods, whereby
> an 'algebra' would allow sequences of
> statements/expression to be reduced to
> simpler [in size or understandability]
> form. Imagine what magic Pythagoras is
> if you've got a W * H tunnel and you need
> to know if a L wide strip can pass through it.
>
> To concretize my criticism with a real example,
> I recently investigated gforth > OOF, and
> reached the following 'feeling' [obviously it's
> subjective and fuzzy]:-
> * perhaps the mental clutter can be reduced
> once a suitable class heirarchy is built ?
> * the gap between forth's syntax and natural
> language [which we've been practicing all
> our lives] reduces productivety.
> * the arbitrary syntax of especially the new
> constructs of OOF, could be profitably handled
> by templates, or even better a structured
> editor, instead of 'learning telephone numbers'.
> * forth is good for bootstrapping a new make of
> CPU, but not much else - ito productivety.
>
> IMO forth is cute and fascinating but not
> productive.
>
> AFAIK the 'joy web site', mentions the word
> "algebra", but doesn't show any complete
> solution of a problem, eg. "the following
> form <X> can be transformed the <Y> which
> is seen to prove P; which solves problem Q".
>
> Top down design means define the problem
> and show how it's solved.
>
> Is there any useful contribution to increased
> productivety yet, in knowing that language
> X can be viewed as a sequence of
> tranformations of stacks ?
>
> == Chris Glur.
>
>