Intent

[Jason Marshall]

>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.
[good practice examples snipped for conciseness]

This is true, but totally irrelevant.
Three arguments of the same data type are still going to compile fine, 
and have only a 1 in 6 chance that an arbitrary ordering will be the 
correct one.
Two arguments have a 50/50 chance of being in the right order.

x, y
row, column

area code, prefix, suffix
prefix, suffix, extension

oldname, newname
newname, oldname

first name, middle initial, last name
last name, first name, middle initial

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

Care to elaborate?

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

Core, static evaluation issue.
ie, main issue regarding compile-time checking.

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

Preference != fix, of course.
But I somehow doubt we'll solve this one in this language iteration.

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

You've split the statement from the defense, and addressed them 
separately.
The fact remains that several folk have repeatedly ended statements 
with verbiage to the effect "and besides, it's more compact".  

Compact does not equal "concise", nor "readable"
Concise and readable equals "concise" and "readable"
As does elegant.

Assembly code is compact. 

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

All other things ceased being equal about fifteen years ago.
Complexity is not an option.

>>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 through everyone else's brain.

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

Chalk that one up to a mis-read.  Yes, that does work.

Jason