Intent (was: Re: Lists, Tables, Psets)

[btanksley@hifn.com]

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

>> > > You say clutter, I say loss of intent.

>> > I'm still not sure what exactly you mean by "intent",
>> > or why you find it such a valuable thing to have?
>> > Does it make the system fast, small, or good in some other way?

>> Intent is the ease at which a program can be reverse engineered,
>> preferably by a machine.  The more intent stated in a program, the
>> easier it is to reverse engineer.
>> Comments do not count because they are not the code.  Comments,
>> technically, have nothing to do with code.

>Sometimes I wonder if Brent is on the same page as everyone else about
>what the core aspects of TUNES should be.

And who is this "everyone else" with whom you wish to associate yourself and
disassociate Brent?

Jump on the bandwagon!  Everybody's doing it!

>To me, these (named method
>arguments) are so obviously metadata as to negate the need to discuss
>it further.  But thanks for persisting :)

Excellent point -- you're right, there's no need to even consider them.

Okay, I'm kidding.

>I feel the need to reiterate your comments on intent.  This 
>has been the foundation on which I have been trying to build a 
>language of my own. 'Metadata' sounds more flowery, but down 
>here in the trenches, 'intent', gets nods of comprehension much 
>earlier in the conversation, in my limited experience.

Of course, you DO know that it's bull, right?  Just because you personally
don't understand the theory and practice of combinators doesn't mean that
combinators don't reveal intent.

The way for a programmer to reveal intent in a concatenative language is to
choose appropriate factorings (and function names) for his problem.  The way
to reveal intent in your language is to choose appropriate parameter names
for everyone who's ever going to use your function in their problems.  Of
the two of us, who's more likely to reveal the most intent?

I say the most intent is revealed when you're not constrained by having to
reveal information which will have to be appropriate to a context you don't
understand.

>Not only is the code more readable by a human

Balderdash.  You make that statement out of ignorance; you simply aren't
familiar with concatenative languages.

>(set aside arguments that
>25 wpm typists may not be able to cope with the verbosity, as these can
>be addressed by modelling tools and the like),

True, although not for that reason -- intent can't effectively be
communicated through a modelling tool, so using a modelling tool removes the
advantage of intent.  It's FAR better to use a language which doesn't
require a modelling tool (but still permits one, for when it's needed).

>but as you say, it's more
>readable by the code optimizer in the system.

Utter and sheer ignorance.

>If you for instance declare
>that you intend to visit every item in a list or container, and perform
>an action on it, this is easier for the optimizer to sort out than if
>you
>write 50 different minor variations on an iterator idiom by hand, some
>with unintentional out of bounds bugs that you didn't bump into (yet).
>And it's easier for the compiler to parrallelize it on the target
>hardware if the facilities are available (MPP, vector math, etc).

This is utterly true.  And completely and totally irrelevant.

>to painful mechanisms of inter-language communication. All the 
>code will exist within a single virtual machine, with a common 
>calling convention where possible, dynamically generated 
>wrappers where not.

So, in the final analysis, you have a virtual machine.  Our languages are
not so different -- except that you have a huge translation layer, and I
have a tiny one.

>Jason Marshall

-Billy