Re: [stack] sweetening concatenative syntax

----- Original Message ----- 
From: "William Tanksley, Jr" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 06, 2008 12:22 PM
Subject: 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.

these are very useful and very deep insights.

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