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

chris glur 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 ?!

I know you're joking, but you've got to admit that this hardly
characterizes any discussion we've ever had. As far as I can tell,
you're saying that we've been rejoicing over the sheer _difference_
between concatenative languages and applicative languages, without
caring for what concrete benefits the differences bring us; and that's
just not true.

> What I've been hoping for is pointers to increased
> productivety, based on
> [...] psychology, not compt-science.

An excellent desire! But you're either desiring enormous luck, or
putting the cart before the horse.

I'd love to have a human-factors expert look at concatenative languages
to see what can come of it. Such an expert would, of course, FIRST have
to understand concatenativity, and that would require either an expert
who loved concatenative languages for some reason of their own, OR an
expert who is taught about concatenativity by people who'd made it their
own study.

In the first case, we'd be extremely lucky to find such an expert; such
a person would have to be an specialist in their own field, and yet
still find a completely different field interesting (most of the time
high skill in a specialty means you're more interested in the
specialty).

In the second case, we (the people interested in concatenativity) have
to "suffer" without expert human-factors help until we understand the
features of concatenativity well enough to explain them to a person
who's not innately interested in concatenativity.

So, we need to be either lucky in finding an expert who likes raw
concatenativity; or persevere in understanding enough until we can
justify ourselves to a human-factors specialist.

I don't see a shortcut.

On the other hand, I do see a huge benefit to what you're doing:
emphasizing the importance of human factors, so that we can direct our
efforts as a group. Surely if we make an effort to explore human factors
we'll at _least_ be able to attract a human factors expert more easily
(because we're _discussing_ that specialty, even if we don't
accidentally make a useful discovery).

> 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.

Mnemonic IDs are a great idea, but we have more power than that
available to us. Any language can have mnemonic IDs. Of course, this is
what you're telling us to look for -- what human-factors things can
concatenative languages do better?

Let me list a few things that concatenative languages do better because
of their concatenativity.

First, they need fewer IDs. Throwaway intermediates don't need to be
given names; they can just be placed on the stack and "flowed" to their
next user. This can be done wrong (by requiring too many stack shuffles)
or abused (even elegant code can, in theory, overdo deep stack use), but
anything worth doing can be done wrong :-).

Second, because concatenative languages don't depend on IDs to get data
from one place to another, they also can't teleport data from one place
to another; the data flows along in the same direction as you read the
program.

Third, concatenative languages are easier to compress in a
human-understandable way. The most natural way to compress data is to
extract commonly-appearing sequences, give them names, and substitute
the names for all the occurrences of the sequences (in computer science,
a common algorithm for this was charecterized by Lempel and Ziv, see
<http://en.wikipedia.org/wiki/LZ77_and_LZ78>). This process cannot
easily be done in a language that uses IDs for data.

With all that said, I have to hasten to contradict an easy error: I'm
not claiming that these advantages prove that concatenative languages
are better than applicative ones. Applicative languages also have
unique, distinctive advantages in human factors. Part of our job is to
look for ways in which concatenative languages are _worse_, and to see
if we can engineer a way to make up for that potential problem.

For example, applicative languages make it easy to implement a very
limited amount of parallel control flow: the parameters of a function
are evaluated independently, so in theory they could be evaluated in
parallel. One possible solution is to invent control structures that are
explicitly parallel; indeed, this has been done for at least one very
interesting language, Factor.

> 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.

Formal methods take a lot of work, but some of our natives are putting
that work in. You know about Cat, of course, and Nowak's old 5th project
has done even more for the static analysis of concatenative programs.
Meanwhile, Factor is an outstanding concatenative language that's built
for practical use -- and part of that practical use is built on
established formal methods. Factor's optimizer is extremely powerful and
flexible, and if you understand how to write code with static stack
effects, you can help it generate much closer to optimal native code.
This makes understanding formal methods really pay off even to
programmers who otherwise wouldn't be interested.

> To concretize my criticism with a real example,
> I recently investigated gforth > OOF, and
> reached the following 'feeling' [obviously it's
> subjective and fuzzy]:-

I'm not sure that gforth+OOF is a sensible place to start. GForth has
three OO extensions bundled with it, and none of them have a library. It
makes more sense to look at a language whose OO extensions have been
more developed and used. Factor is the obvious choice for this.

> * the gap between forth's syntax and natural
>   language [which we've been practicing all
>  our lives] reduces productivety.

What does this have to do with concatenative languages? Every precise
language has a gap between it and everyday language; that's inherent in
the different needs of precision use versus everyday use. Even legal
documents are hard to learn to read and write, and they're nowhere near
to being accurate enough for a machine to execute.

> * 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'.

I don't know what you're talking about by "especially the new
constructs". I suspect I know what you mean by "learning telephone
numbers" -- I think you might be saying that the OOF.fs package has too
many words that take a large number of parameters, and so you're stuck
memorizing the order of parameters. (I'm only guessing here, in case
you're alluding to the idea that human short-term memory can handle at
most 7 gestalts at a time.)

> * forth is good for bootstrapping a new make of
>   CPU, but not much else - ito productivety.

I don't know what "ito" means.

This observation cannot be accurately reached by someone who's merely
looked at a oof.fs packages. Either you've done a *lot* more work in
Forth, or you're just guessing. Care to specify which one?

> IMO forth is cute and fascinating but not
> productive.

There are actually a decent number of Forth programmers who'd disagree
with that. And to expand this out to more concatenative languages, I
think it's pretty clear that Factor proves that concatenative languages
are both fascinating *and* productive. Compare the growth and
development of any other language... Scala and Clojure don't even come
close; arc has some similarities, but took SO much longer to start up
and seems to have stalled now.

> 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".

The Joy website contributed immensely to the increase of formal
knowledge. Forth contributed probably the most of any language to the
increase of practical language. You're asking for someone who put the
two ideas together; right now only Factor comes closest to giving what
you seem to be looking for, but they don't emphasise very strongly
tracing back *every* practical improvement to its theoretical roots.

You're also overlooking the fact that theoretical roots are very complex
things to trace. You express them mathematically above, but math doesn't
express human factors, which are far more important. A full
understanding of human factors can only be seen by implementing a model
and seeing how real humans use it.

> Is there any useful contribution to increased
> productivety yet,  in knowing that language
> X can be viewed as a sequence of
> tranformations of stacks ?

Sure.

The interesting thing is that Forth achieved this without even trying --
Chuck Moore almost certainly never thought of Forth this way, but he and
Forth programmers benefit from how the theoretical purity and
referential transparency of concatenative languages can be mixed with
state mutation and other non-functional behavior without losing many of
the theoretical benefits.

Postscript also achieved this without trying -- it's almost certainly
the most-used programming language in the world, thanks to all the
millions of printer drivers automatically generating "custom" Postscript
programs to be run on PS laser printers, and that wouldn't be possible
without the way concatenative languages allow you to produce a valid
program simply by juxtaposing two valid programs. It makes automatic
program generation simple.

Is Factor benefiting from the fact that it's concatenative? That's hard
for me to answer; Factor has a superb development community, so perhaps
that's the real reason... But Factor is undeniably strongly
concatenative, so at least this proves that concatenativity isn't
actively hindering their work.

> == Chris Glur.

-Wm