Inten

[Jason Marshall]

>From: Jason Marshall [mailto:jmarsh@serv.net]
>>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!

I'll simply cite Finagle's law.

As an aside, I take it you've never passed arguments in column, row 
order and wondered why your code doesn't work?

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

The ultimate ease of use is the minimal set of information necessary to 
perform a narrow task.  Reducing argument count below that threshold 
introduces all sorts of nasty concurrency issues, which are, in my 
experience, far harder for even senior level programmers to deal with 
than anything I've seen discussed on the list to date.

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

I'll have to look at this issue again.  Try to hunt up some use cases, 
similar to the ones Bertrand Meyer has done for design contracts.  I'm 
sure such must exist.

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

I mean that named parameters gives compile-time assurance of 
appropriate argument alignment, much as many compilers (C is a notable 
exception) give assurances of argument count and type compatibility at 
compile time.

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

Well, you've just illustrated a human check, and I took exception, 
hoping for a machine check.

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

Which was the main point I was trying to make.  If you mean 'concise' 
when you say 'compact', then please do say 'concise'.  It's less likely 
to lead someone with only peripheral knowledge of your ideology to 
think you're advocating using 1 letter variable names and 4 letter 
function names in the name of 'compactness', much the way clever little 
sayings like Knuth's "premature optimization is the root of all evil" 
lead to people designing horrible interface contracts because they 
can't be bothered with such trivial "optimizations", which are, 
donchaknow, evil anyway.

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

On the one hand, this goes back to the compactness vs readability 
issue, on the other, it plays into Moore's Law, where the number of 
calculations per second our code is being asked to execute is doubling 
every 18 months.  So, really, all things are not equal, because we are 
being asked to write code of such complexity that our forebears would 
have laughed at the notion of ever doing such a thing.  Any program 
that is sufficiently simple has insufficient functionality to be 
'interesting' to more that 10% of your userbase.

Now, I don't want you to get the impression that I'm against elegant, 
concise code.  I'm playing devil's advocate here as much as anything 
else.  But toy code should never be the measure of a general purpose 
language.  It's the big projects that have to be big that will make or 
break you.  Sometimes, you just can't get around having a 100,000 line 
program.  Usually that means you've already reduced the problem from 
150,000 lines, but you're still stuck with what's left.

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

Users want complex logic.  So there is a fundamental amount of 
complexity to everything we do, and that is irreducible.

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

I am, in fact, always talking about team programming, because, as I 
just stated above, non-trivial projects serve to judge a general 
purpose language.  Perl is not a general purpose language, and hence 
doesn't fit the profile (ie, all bets are off).
But I had the impression Tunes was supposed to be such a beast.

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

Would that we could always have access to all our dependent code.  
Remember, we're trying to design a language here.  That means standard 
libraries, that will morph over time.  And every company has (or should 
have) a library of reusable code, that is being used on multiple 
projects.  I'm currently the curator for the library at my company, and 
I only have control over the client side of one of the projects that 
uses this code, everything else is in others' hands.

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

Every so often it's a big ol' barrel of laughs, lemme tell ya.

-Jason