Sat, 01 Apr 2000 02:35:15 PST
>> 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
>> 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
>> 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
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
(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
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
>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:
>- "iepos" (Brent Kerby)
I will continue to look, but unfortunately one of my weaknesses
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
to anthropomorphize everything just makes it too tempting to try to
even did I not know of one or two promising variations. I think if one
pains, in the language, libraries and example code, to make a clear
distinction between type and implementation, a lot of the worst
are avoided. Multiple inheritance of type is a much smaller quagmire
MI of implementation. Java kinda, sorta, came within the neighborhood
getting the right idea, but then punted on the execution. Well, great.
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
front (many of these discussions boiled down to poor public perception
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
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
out of first place. If it's too different, everyone scratches their
"nice toy", and goes back to wallowing in their own filth. Of course,
only an extremely small number of data points to support that theory,
if it's true, that means if one wants to change the world, then they
'fix' Java, in some fashion akin to how C++ 'fixed' C. Which is what I
thinking about several years ago. But now I'm quite a bit distant from
original goal, having looked at TUNES, deciding it wasn't what I
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
the language and in the APIs as much as possible. In the end this
for the best because, for some odd reason, it's far, far easier to push
an API change than a language change. Maybe it's just that the
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