Intent

[btanksley@hifn.com]

From: Jason Marshall [mailto:jmarsh@serv.net]

>>There are a few thoughts I have relevant to this...

>>I do see how this could be a
>> bit of a problem... However, it seems to me like the "pset" approach
>>has a very similar problem: one programmer might use another 
>>programmer's
>>library and the _names_ of the parameters may not be what he'd prefer.

>But this issue can be resolved at compile time.  Ordering issues have 
>to be resolved at debug time, or are missed altogether.

This is a good point, and it's the reason why Forth (and other concatenative
languages) prefer to have small numbers of parameters per function.  The
standard in Forth is to have at most 3 parameters.

Applicative languages (for example, languages such as yours which have named
parameters) don't have that limitation; you can give them as many parameters
as you want, and the only obvious problem is that humans start having
problems remembering mappings of more than seven items.  (Humans can't
instantly recognise mappings of more than 3 items, which is the main reason
for Forth's limit being 3 instead of 4 or 7.)

But there's some less obvious problems with functions which have many
parameters: first, they have to be relatively large in order to use so many
parameters; and second, they place large demands on the limited resources of
the machine in order to make those parameters available to the function.

So using a large number of parameters is a bad idea in general; it not only
makes the function harder to "gestalt" (recognise in one flash), but it also
makes the function harder to optimise.  So although your language system has
the advantage at dealing with large numbers of parameters, any programmer
who actually uses that advantage is in trouble.

>>Just as in a Joy-like system one must choose an arbitrary order for
>>the parameters, in a pset system one must choose arbitrary names
>>for the parameters.

>All procedural, object, and most of the functional languages I know 
>name their parameters,

...which is one reason I was so interested in a language which doesn't
;-)...

>but outside of code assistance tools, these 
>names are generally only externally visible in the documentation, if 
>there.

...a problem for reflective systems...

>While appropriate tools can counter some of the arguments for 
>parameter sets, the core static evaluation issue still remains, and 
>that's the one I feel most strongly about.  And in fact, such a tool 
>can take away the added headache of setting up a well-known method 
>signature, as it can create a 'blank' call for you with the fields you 
>want, making it harder to forget the naming convention the original 
>developer used.

I'm at a loss -- what is a "core static evaluation issue"?  Are you saying
that a "core static evaluation" is a kind of tool, or are you just assuming
that I'll know that some kinds of tools use core static evaluations, and
that parameterless languages lack the ability to do these?

>>Anyhow, parameter-order is not the only seemingly-arbitrary thing
>>that one must decide when making libraries. Another thing one must
>>decide is the structure of how things are passed; will one pass
>>several parameters in unwrapped form, or will one instead make
>>a list ("object", "structure", or whatever) containing them and just 
>>pass
>>that? Again, the pset approach has the same type of problem here
>>as Joy.

>This is true.  I'm not sure how one would go about 'fixing' this.

A Joy programmer would prefer to wrap stuff, since that reduces the number
of parameters.

>>I'm guessing that this is the quality that you call the 
>>"intentfulness"
>>of a system, the quality of not having to make many arbitrary 
>>decisions
>>when programming in it. If so, then I'd agree that it's a noble goal;
>>it's closely related to the goal of having programs be small in size.
>>Anyhow, it seems me like Joy meets this goal just as well (perhaps 
>>better) than a pset approach would.

>It seems that several folk have accepted as truth that compactness is 
>optimal.

That's not at all what he said; he simply said that compactness is one of
the many virtues of good code.

>I don't agree.

We reach a problem, then; I do agree.  Not only do small programs run faster
(because they can use fewer of the computer's very limited "fast" resources,
such as registers), but they are also MUCH easier to understand, other
things being equal (that is, "hand optimised" programs are not a competitor
in this category).  A small program will require less memorization; there
will be less room for bugs to hide; it's all good.

Read what I posted about the ideal places to put functionality -- the best
way to get something done with a computer is to not ask the computer to do
it.

>Humans and computers do not, and for the 
>forseeable future will not, think alike.  So what is most concise for 
>the computer may not be the most elegant statement for Joe 
>Programmer.
>Maybe for you, maybe for me, but probably not for Joe.  And 
>Joe and his 
>boss make or break the language.  And some days, I don't particularly 
>care to show off my mental prowess just to get the basic aspects of my 
>job done.  I like to reserve the Extreme Brainpower (tm) for special 
>occasions, like architecture meetings or figuring out why my IDE is 
>crashing nonstop this week (okay, I don't enjoy the latter, but I get 
>to do it too often).

Perhaps the problem here is that you're worrying too much about maximal
elegance.  If you make it simpler he'll get it quicker.

>>Yes. In a Joy-like system, it is also possible for the system to
>>store parameters in an order other than the one literally given by
>>the programmer. 

>Okay, I'll buy that.  So, to sum up:  From an optimization standpoint, 
>the transformation effort is of equal magnitude.  Give a 
>constant here, and take one there.

Correct, except for the fact that the combinative language (in this
discussion, Joy) contains an explicit dataflow, whereas the parameterised
one does not.  Therefore, the optimiser will have to figure out what the
dataflow is; it wouldn't have to do that in Joy.

>>Again, a similar problem happens in your style of system. A person
>>who writes a library might go back and change the names of some of
>>the parameters, and woe be unto everyone else who was using the
>>old names.

>But here, if you change the names, you change the method 
>signature.  If 
>I add or remove an argument, have I not constructed a different 
>signature?  So we've replaced order with names as a defining aspect of 
>a method signature.  But how often do you change parameter names 
>without changing the intent of the method?  I've done this perhaps a 
>dozen times.  I'm always adding or removing parameters, or 
>running into 
>libraries where two developers (or one inattentive one) used a 
>particular ordering of arguments on one method, but on a logically 
>similar one, switched them.  And don't get me started with how X 
>coordinate is first in cartesian coordinates, but column index is 
>second in tabular forms.  I mess that up about every forth time I have 
>to create a table to view data.

When you add or remove a parameter, you ALWAYS have to follow the change
through all your code.  Nothing will ever change that.

And I suspect the main reason you think renaming parameters is rare is that
you've never worked with a language which exported its parameter names.
Most function parameters are chosen to be meaningful internally, not to
callers.  Once the names become meaningful to callers, choosing them will
take on a new importance.

>> But actually, I don't see the problem quite happening this
>>way; if I was "everyone else", then I would have made a local copy of 
>>the
>>library instead of relying on the writer not to change it; then I 
>>would
>>know that the parameter orders (or names) are not going to change.

>Local copies of libraries.  Now there's a whole other can of worms.

It's the only use of libraries I've ever seen.  It's the reason for version
numbers.

>-Jason

-Billy