Intent

[btanksley@hifn.com]

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

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

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

Unless you have some unusual insight into programmer's minds, I don't see
how you could come up with figures like that.  Surely even the stupidest
programmer writes better programs than a random text generator, even if the
types are truly the same!

The purpose here is to develop easily checkable conventions -- or, better
still, to ratify existing conventions -- which work with the programmer's
mind to make correct code easy to write.  The ultimate in ease of use, IMO,
is one parameter per function, with the name of the function entirely
determining the nature of the parameter; no need to expose a name for the
parameter when the function describes its own use.  Combinative functions,
though, need two parameters, and brevity dictates that we allow more -- but
the limitations of the human mind insist that four is just beyond
reasonability.

Oh, BTW, a side note: why not borrow Smalltalk's syntax for procedures and
such?  ST has a good, solid set of conventions for named parameters.  Of
course, you would want to remove ST's support for unnamed params (and no
doubt make other changes in the syntax and semantics), but that's to be
expected.

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

Sorry.  I thought we were on the same page.

If the "names" are important (as they are in lambda-based systems), a lack
of access to the "names" is a very bad thing for reflection.

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

Ah.  Okay.  But I still don't know what you mean -- you're talking about
this important issue, but you're not naming it, at least in this paragraph.
No doubt you named it earlier and I was just confused; what issue are you
talking about?

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

This would be especially difficult since I refuse to acknowledge that
anything's broken.  Conventions are the only "complete" solution to the
difficulty of programming.  Machine checkable conventions are the best sort.
Human checkable ones are the next best.  Everything we've discussed is
machine checkable.

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

Yes.

>Compact does not equal "concise", nor "readable"

Incorrect -- compact code is also concise.  It's not always readable,
though.  It's too easy to make code unreadable in an effort to make it
compact.

However, the converse is also not true: not all compact code is unreadable.

But this is not really relevant; a language which allows for compactness is
not the same as _code_ which is geared for compactness above readability.
Such code can be written in any language, and if you attempt to forbid it
you'll only make programmers write ugly code.  A language which is designed
to allow compact expressions is not the same as a language which encourages
unreadable code.

A language which requires bulky code, on the other hand, is outright bad.
Code bulk makes bug-free code into bug-prone code which is a pain to write
and a pain to debug.  Remember Perl one-liners?  I prefer Python for all
other use, but a Perl one-liner is the right solution when it's possible (of
course, anything more than one line is NOT a job for Perl).

>Concise and readable equals "concise" and "readable"

Undeniable.

>As does elegant.

Why would you make this statement?

>Assembly code is compact. 

I strongly disagree.  I've written too much assembly code.  It's not compact
by any definition I know of -- it's almost impossibly sparse.

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

What on earth does this mean?  Are you just trying to make fun of something
I said?  If I'm wrong, please rebut me.  If I'm confusing and stupid, please
rebuke me.

>Complexity is not an option.

Well, we haven't addressed complexity, but code size is statistically
related to complexity.  Larger code is more likely to be complex.  More
importantly, large code is capable of hiding more complexity, and when
reading large code it's natural to assume complexity.

Small code can also be dense, of course.  This is less true in stack-based
languages (like Joy and Forth), where you almost have to use related things
nearby to each other.

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

I'm assuming team programming -- when you make your API change, you and you
alone are responsible to make all the code using your API run its unit tests
as well as it did before you made your change.

If you don't have access to all of the code which depends on your API, you
have no business simply *changing* it.  (Making a new version is fine, but
you can't force an upgrade.)

Because otherwise, you DO have to force your change through everyone's
brain.  And that is painful for everyone involved, regardless of the
language involved.

>Jason

-Billy