Re: [stack] sweetening concatenative syntax

John Nowak <[email protected]> wrote:
>  Daniel Ehrenberg wrote:
>  > Sure, there are lots of translations that we could make efficiently
>  > and accurately with concatenative languages, but I'm not sure if all
>  > of these are essential or beneficial to the nature of the languages.
>  > They make things more complicated and they remove all of the nice
>  > properties of concatenativity, which is useful in building software
>  > because it helps you factor code.

>  I'm not convinced concatenativity offers a huge advantage in
>  factoring.

Sure it does! The referential transparency alone is worth the price of
admission -- the famous "extract method" refactoring (considered by
many to be the first indication of "true" refactoring support in a
tool) is merely a cut-and-paste in any editor.

> It's easy to write code in such a way that useful chunks
>  can't be pulled out. It's also difficult to find useful abstractions
>  unless you have some experience. For example, I'd guess the novice
>  programmer looking to add two lists together wouldn't accidently write
>  zip-with.

You're totally right, but you're talking about a different subject.
The experienced programmer isn't going to implement zip-with either;
the experienced programmer knows it's already implemented. The
experienced programmer is going to implement something that hasn't
been done before, and notice that there's some redundancy, and if the
language allows, will factor it out. If the language makes it hard,
he'll tolerate a lot more redundancy.

An really good programmer will also notice *almost* redundancies --
places where the code would be the same if only things were a little
bit different. _That_ is the point that leads to the creation of truly
reusable tools like zip-with -- not a magic knowledge of what sort of
things will be reusable, but rather a repeated creation of the same
sort of thing, and progressive refinement of that thing until it can
actually be used in all of those cases.

A good library is rarely produced directly from pure theory. Usually
it's produced by painstaking experiments -- although if it's not
backed by a good clean conceptual model it's a bad library, and
experience won't save it.

>  I think how factorable a language is primarily depends on its
>  usefulness in building abstractions rather than any particular syntax.
>  Languages with first class functions offer factorability that language
>  like Forth don't offer.

100% agree, by the way. The problem of factoring can be addressed in
many dimensions.

>  If a syntax that is non-concatenative makes it any easier to use any
>  of the other means of factoring, then it seems to me it's worth
>  considering.

At this point in our understanding of concatenative languages, this is
a pure cop-out. Yes, we don't have a concatenative Haskell yet -- but
give us time.

>  - John

-Wm