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

[Jason Marshall]

> > > You say clutter, I say loss of intent.
> >
> > Hmm... I don't quite understand... are you saying that you also
think
> > that the "(", "=", ")", ",", and ";"s are obscuring the program?
> > Or, are you saying the opposite, that they are essential to
> > the "intent" of the program and that taking them away destroys
intent.
>
> The latter: the "(", "=", ")", ",", and ";" increase readability.
>
> > 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.
>
> Intent is good because of the reverse engineer aspect.  There must be
a
> reason why people prefer higher level languages.  The average human
> being is not a memory machine.  I know a couple of people that have
> incredible memories, and maybe Joy is for them.  But I would never
> remember parameter order, especially if that order is dependent on
> implementation.  Most of my time will be spent looking up parameter
> order in the help file, again and again.  In C or Java, the parameters

> have order, but at least a fairly consistent and logical order.  I
> propose the next step, remove order, and use parameter names.  When I
> call a function I find it much easier to remember the parameters
> required than recalling order too.
>
> Maybe I am making a point on human interfacing.  Our memories are
> associative; given a trigger, the associated thought is easy to
recall.
> The association between parameter name and the parameter concept is
very
> easy to recall.  Communication with a human can be more efficient of
> there is redundancy in the communication.
>
> Why then, may you ask, should this redundancy be modeled in the
> machine?  I propose that it is not.  Like I said before, once you have

> all the data structures in place that describe the structure of a Joy
> program you will see that it is no better off than what I propose.  We

> both have the same amount of information in a particular program.  I
> have normalized the database containing these structures, so there is
no
> redundancy; my code is as small as it can get, for the information it
> contains.

Sometimes I wonder if Brent is on the same page as everyone else about
what the core aspects of TUNES should be.  To me, these (named method
arguments) are so obviously metadata as to negate the need to discuss
it further.  But thanks for persisting :)

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.

Not only is the code more readable by a human (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), but as you say, it's more

readable by the code optimizer in the system.  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).

Some of these issues can be handled at the language level, and some at
the API level.  The important thing when designing is not to ask, 'how
do I?' but 'Why do I?'.  Why do I create a file?  Because I want to
keep some persistent information.  Why do I have locks?  To perform
atomic operations on data that is seen by multiple threads of execution.

Why do I need explicit resource allocation/deallocation?  I dunno.
Why do you?  Are the builtin facilities failing in some serious way?

If your only defense of a design decision is "because it's more
compact",
then maybe you're barking up the wrong tree.  If the defense is "because

the programmer can just remember that detail", then you're definitely
barking up the wrong tree.  You're just writing yet another programming
language, not a metaprogramming language.

In Dot (the name of my embrionic language project), one of the strengths

of the system is that it plans to make heavy use of metadata for code
optimization.  The hardware landscape is getting so diverse as to make
optimization a nearly herculean task.  Mainframes, desktops, palmtops,
your fridge.  PPC chips, 31 flavors of x86 chips.  6 flavors of Sparc.
Transmeta.  ARM.  Merced.  Multiproc-on-a-chip.  The whisper of
self-modifying processors on the horizon.  It's going to be a great
huge mess, and no one really wants to talk too much about it.  What's
important optimization information for one is totally irrelevant for
another,
but people want to run the same programs in all these places, because
they intend to get work done.

The plan is that the HLL has a great deal of programmer intent
information
present, but the compiler augments this with an extensive number of
optimization directives in the LLL.  Each object and each method exists
as a small amount of actual code (if any) and a large amount of
attributional
data explaining in painful detail the intent of the method or code
block.
Some of the attributes are required fields, necessary to ensure correct
code
execution, but many are optional, allowing a constrained host
environment
to throw away the optional data that doesn't match its operational or
feature constraints (size vs speed, or parallelism, etc), add or
subtract
entries based on information gained from previous runs, or even request
optimization commentary from peer machines in ways that don't
presuppose a strong trust relationship (namely, asking for
success/failure
histories for applying certain optimizations to various blocks of code),

allowing for more involved code analysis with fewer heuristic cut-offs
through cooperative brute-force optimization.

I also plan to write a cross-compiler backend for GCC to hoist a subset
of C programs from the OSS libraries (for instance, data compression)
to make use of existing code without having to do a full rewrite, or
resort
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.

Regards,
Jason Marshall