No subject

[Jason Marshall]

>> 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?
>
>It is generally understood that my project, at least, is only
>for a "TUNES--" ... Thus, I'm not now considering _all_ the
>goals of TUNES. My main focus now has been to achieve efficient
>storage management. 

My current focus is on a GC framework (rather than a one-size-fits-all
GC), and after the groundwork is in place, I'm going to attack the
problem from the top, down.  I figure for security, and certain size &
latency optimizations, that being able to prove something immutable
would be a fairly useful thing.  While the trivial case is fairly 
simple
(no mutators, and no shared data with mutators, recursively), some 
other cases where the sharing time extends only as far as the end
of the call, will be harder to construct proof systems for.  The 
difference between immutability and almost-immutability is a race
condition.

I still haven't decided what precisely the code is going to look like,
only the shape of the vessel into which it will fit.  Coding around a
void in order to determine its shape is only going to get me so far.
Alas, at the rate I am currently progressing, I have plenty of time
before I run into that hurdle.

>But, you may say that reflection is quite an important feature, and
>that it should not just be swept under the rug. The terminology
>associated with reflection always seems to get very confusing,
>but you might say that Joy _is_ reflective, in that programs
>themselves can be pushed onto the stack and manipulated as
>first-class citizens, and in fact this is quite a common
>practice in Joy programs.
>
>Anyhow, this is probably not the only kind of reflection you want...
>However, I suspect that a Joy-like system would make a nice
>base for a system that was reflective in other ways. One of the
>author's goals was that Joy programs be easy to reason about by
>other programs.
>
>Joy is different from other systems in ways that may seem unnatural;
>however, I suspect that if you looked seriously at it, you would find
>its approach very useful.
>
> (The system and its documentation can be found at:
>  http://www.latrobe.edu.au/www/philosophy/phimvt/j00syn.html)
>
>- "iepos" (Brent Kerby)

I will continue to look, but unfortunately one of my weaknesses 
(strengths?)
is that I am incredibly stubborn about some things on occasion, and one
of those is OOP, as broken as all known instances are.  The human 
tendency
to anthropomorphize everything just makes it too tempting to try to 
salvage,
even did I not know of one or two promising variations.  I think if one 
takes
pains, in the language, libraries and example code, to make a clear 
distinction between type and implementation, a lot of the worst 
problems 
are avoided.  Multiple inheritance of type is a much smaller quagmire 
than is
MI of implementation.  Java kinda, sorta, came within the neighborhood 
of
getting the right idea, but then punted on the execution.  Well, great.  
You
have MI of type, but you hardly used it, because your implementation of
method dispatch is so biased, and you made a bunch of speed related
implementation decisions long before you had a mature VM.  Would you
like a prize for that?

You know, some days you'd never guess that I make a good living writing
code in the thing, and have spent a lot of effort defending it on the 
technical
front (many of these discussions boiled down to poor public perception 
of
VMs and GCed systems).  

Throw some Aspect Oriented Programming, better method dispatch, 
closure-equivalent entities ('unbreak' inner classes), distributed code
optimization, multi-language support (hopefully including things like
functional programming) and a partridge in a pear tree, and you have
something you (well, I) can get commercial projects done in.

The reason I persist despite all the flak I catch from functional or 
other
alternative discipline programmers is that I have this pet theory that
states that in order to be a popular language, you have to have an
evolutionary (NOT revolutionary) language design, and a better library
(this is allowed to be revolutionary, I think) than the person you're 
knocking
out of first place.  If it's too different, everyone scratches their 
head, says 
"nice toy", and goes back to wallowing in their own filth.  Of course, 
I have
only an extremely small number of data points to support that theory, 
but
if it's true, that means if one wants to change the world, then they 
have to
'fix' Java, in some fashion akin to how C++ 'fixed' C.  Which is what I 
started
thinking about several years ago.  But now I'm quite a bit distant from 
that
original goal, having looked at TUNES, deciding it wasn't what I 
wanted, and
then subsequently evolving a set of requirements that eventually turned 
into a lot of the same ones that TUNES has.  Unfortunately, 'm not even 
sure what I'm working on now falls within a standard deviation of that
'sweet spot' I feel/imagine is there.  

One way to 'soften the blow' is by keeping the really big changes out 
of
the language and in the APIs as much as possible.  In the end this 
works out
for the best because, for some odd reason, it's far, far easier to push 
through
an API change than a language change.  Maybe it's just that the 
development
tools deal with that sort of morph a lot better.  I'm really not sure.

Anyway, that's probably enough from this wing of the peanut gallery for 
one day.

-Jason