Re: [stack] function/object ambiguity + quotation alternative

let me register some dissenting opinions here (no surprise, right?)
these have been buzzing around in my head since billy's response to
my "anti-factoring" post.

i expect i'll meet with some resistance here, since i can't provide
an overwhelmingly persuasive argument (that's why they're opinions.)
if they spark some ideas, that's enough.

i can say the same thing in several ways:  compared to other languages
i know, k call-trees are smaller, there are fewer names in play, and
a greater proportion of the tokens in a k program are primitives.  (you
can see an example of this in the game-of-life function i posted a few
days ago.)

the question whether one should write long or short programs hardly
ever arises.  a program -- a function with a name -- should represent 
"a thought".  of course, x+y is a thought, and so is x+y*z, so this
maxim isn't precise enough to be useful.  perhaps we get into the 
habit of adjusting the way we think about problems to the language
we're used to, and therefore thinking in ways that experience has
taught us are "best" for that language.  probably this is true to
some extent.

in k, programs will call other programs, but there's not a whole lot
of complexity at that level.  when you look inside a program, mostly
what you see are primitives and the arguments to the program.  (i'm
not sure this is as true in j, especially the way masters of that
language like roger hui write code.)

the primitives are individually powerful and they fit together in ways
that allow for great expressiveness.  usually it's possible to express
"a thought" -- something you can give a name to, and use and remember
easily -- in a line or two or three.  short enough to be "surveyable",
not so short that you need to look at calling-context to understand
meaning.  another way of saying this is that the k programmer spends
most of his time *in primitives*.  

i think factoring becomes useful to the programmer when the primitives
are so weak that certain phrases, certain ways of combining them, 
appear repeatedly in different contexts.  so then you wind up abstracting
those phrases and giving them names.  and you wind up with lots and
lots of these things, and deep, complicated call-hierarchies.  it's
as though you didn't have + in the language, and you find it natural
to define different special cases of addition for different contexts.

since we are often called upon to work with aggregates of different
kinds -- sets, bags, lists, vectors, dictionaries, tables, &c. -- 
and our primitives are for the most part scalar (again, often of
different kinds) we wind up writing lots of code for different
special cases.  inevitably, this will result in situations where
subtle variations on a single idea will manifest as similar code-
fragments, and we'll go on to factor, combine, rename, &c.  that's
a lot of complexity to manage, and i think it arises just because
the primitives are too weak and their combinations are insufficiently
expressive.

this situation simply does not arise in k, or rather, it arises much
less frequently.  this is because certain mathematical relations
exist between different aggregate types, and the primitives are
designed to exploit those relations.  (e.g. the transpose of a 
dictionary of lists is a table, that is, a list of similar atomic
dictionaries.)  so x+y works predictably (and usefully!) on all 
(conformable) aggregates.  

i've had this suspicion for quite a while -- i don't know how to prove
it.  if you were enumerate all combinations of k primitives in 1, 2, and 3
variables (x, y, and z), you'd find a greater density of "useful"
and "interesting" programs in the set of combinations of length < 10.
an example i've used before is the remarkable function {x y z x}, which
can be used for both converging boolean selection on a table and multi-
column table sorting.  who would have thought?  this and other examples
had led me to think that programming k was like taking a botanical field
trip to the amazon in search of exotic new flora.

this is also why i think enchilada is an extremely promising language.
robbert has designed a handful of very powerful primitives, which
interact in ways which even he, the language designer, can't fully
predict.  hence the different proposals over the last two years, each
of which has made use of discoveries made in the course of solving
problems in the previous version.  i interpret this "fruitfulness",
where application of the language generates insights into the *set
of primitives*, as a sign that enchilada offers a new way of thinking
about problems.  i mean to contrast this with the way i've seen most
languages evolve, which is to add control structures, datatypes, "OO",
compiler technologies, &c., and to ignore the primitives.

anyway, these are just some thoughts off the top of my head.

----- Original Message ----- 
From: "William Tanksley" <[email protected]>
To: <[email protected]>
Sent: Tuesday, March 03, 2009 12:06 PM
Subject: Re: [stack] function/object ambiguity + quotation alternative


> John Nowak wrote:
>> Ideally, a language  
>> should make writing long definitions possible (which I often find  
>> useful in Scheme when prototyping and experimenting) and short  
>> definitions elegant (which concatenative languages do well).
> 
> That's certainly true. A long definition that's in a considerable state
> of flux _can_ be rather hard to juggle around in a concatenative
> language. That's one time when I'd personally forgive the use of local
> variables :-), although I'd rather see the programmer spend some time
> back at the drawing board (or experimenting with primitives) first.
> 
> Let's face it: if you don't know what you're doing yet, you're picking a
> poor time to commit to code. The overhead of stack manipulations is only
> a part of the problem you're going to face.
> 
> I admit that I've done a decent amount of exploratory programming in
> concatenative languages; and I don't think they're any more unpleasant
> in practice (although clearly in theory they're worse). You WILL wind up
> with some nasty stack shuffles, but I think that's part of the penalty
> of exploratory programming (leftover and/or misnamed temporary variables
> are essentially the same thing). If you're careful to think at every
> step you'll minimize the shuffling, and often by the end you'll
> understand the problem well enough to do a complete rewrite _correctly_.
> 
>> > I do agree that Forth is a system language, with poor facilities for  
>> > any
>> > higher-level work. I don't concede anything :-) about "Forth and
>> > friends", since I don't know what languages you're refering to.
> 
>> I was referring to stack-based languages in general; the average  
>> length of a function definition needs to be shorter than in a language  
>> like Scheme to achieve the same level of readability.
> 
> If your only measurement is how a syntax helps you see arities, then
> applicative languages win by acclamation. But there's more to reading a
> program than knowing the arities of the functions. Concatenative
> languages can reveal or conceal a lot more about dataflow, and that can
> help (or hinder) the reading as well. Depends on what tools the language
> has, and which ones the programmer uses.
> 
>> The nesting in  
>> Scheme helps visually and things remain mostly understandable even if  
>> you don't know the arities of all the functions involved. That's only  
>> my opinion of course; I've not launched a study to determine if this  
>> goes for most people, although I suspect it does.
> 
> Forth is the only concatenative language we've discussed that lacks
> nesting. Why would you list "nesting" as an advantage of associative
> languages?
> 
>> > Factor's EMACS mode, "Fuel", supports automated refactoring.
>> Aye, something like this likely helps by reducing the incentive to  
>> write large definitions in the first place. It's a shame I've never  
>> managed to convince myself to learn Emacs.
> 
> Heh. I'm a vim guy myself. But after so much time waiting for a C
> refactorer, it's amusing to see one pop up for Factor so quickly. It's
> actually becoming reasonably competent.
> 
>> - John
> 
> -Wm
> 
> 
>