Intent

[Jason Marshall]

Recently, btanksley@hifn.com wrote:

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

Some days I wonder.

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

What I 'know' is that other than Fare, I'm not picking up on any
meaningful
discussion of metadata going on in this list, which is the main reason
I don't participate more in the discussions.  I can see plenty of
evidence
of incidental or inferential metadata, but I can get that out of any
language, no matter how advanced, or how obtuse.  Talk of whiz-bang ways

of implementing yet-another-language-with-some-induction-logic is, while

interesting, old hat, and does nothing for readability before I've had
my
morning coffee, which is exactly when I'm going to botch the code.

No one talks of formalized metadata, which is what I am after, and what
I
thought/think Fare is after.  Why?

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

This does zero to address unintentional misordering of function
parameters
on the part of client code.

> Of the two of us, who's more likely to reveal the most intent?

By sheer volume of citations of intent?  Your users. You wrote the code
once, and now everyone else is having to live with your mistakes (and
you
are human, so don't imagine you haven't made any, because you have).

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

I am familliar with the classes of mistakes programmers in team an API
settings make, in real development environments.  I am familiar with the
problems
that crop up when one wants to modify an interface to their code, and
there
arises an argument number and type collision with an existing part of
the
interface that can not be mitigated in any more useful fashion than by
sorting
the arguments in some arbitrarily different order so as to make them
unique,
or by inferring/overspecifying parameters, or by giving up and trying
something
else.

I understand that Kyle has grasped this, and that you see it as a
non-issue.

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

Oh, both utter AND sheer.  Well, then I'm ready for an evening out at
the
opera.

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

Not in the least.  People want flexibility in a language in case
the environment isn't subtle enough for their tastes.  Then they turn
around and complain because everyone comes up with a 'clever' synonym
for the code they would have written, sometimes correctly, sometimes
totally wrong, but either way, totally greek to their peers.  Formalism
takes the edge off such concerns over abuse of power.  Here is your
rope sir, but you have to justify any requests to tie it into a knot.

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

Being a virtual machine-based language provides little similarity.

> -- except that you have a huge translation layer, and I have a tiny
one.

I have a segmented translation layer, which is an important distinction.

You have a tiny translation layer, or you're falling victim to the
incomplete implementation fallacy?

How big is your standard library going to be?  What fraction of that is
your minimal interpreter?  How big is a mature implementation of your
interpreter going to be?  How many things is it going to do internally,
how many will be pushed into required standard functionality to perform
the same task?

Concerns over how big an 'unabridged' edition of the machine would be
have some merit, but not as much as you're attributing to the issue.
There is no requirement that a compiler issue, or the interpreter honor,

any optional data.  If the optional data represents 80% of the
dictionary,
and 90% of the implementation complexity, who really cares?  All I've
done
is provide a formal vessel into which optional tools can place their
data, in an attempt to avoid ad hoc formats.  What does that hurt?
Nothing, according to the industry examples I can find.

Different environments will contain a different subset of the content
handlers for the language.  My deployment environments won't care about
debug data.  My dev environment will.  My palm pilot doesn't care about
MPP or high precision math or vector math, or advanced speed-for-space
tradeoffs.  My workstation doesn't care about space-for-speed tradeoffs,

but when I'm downloading a new multiplayer game off the net, I'd much
appreciate if it was usable the first time I ran it.  No VM I know of
is giving me that.

-Jason