[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Standardization (ugh)
Basically, I think people are going overboard with regard to standardization.
There are only two good reasons to standardize: so that people on different
machines can run the same code (as fast as reasonably possible on a given
architecture), and so that you don't waste space with 100 functions or programs
that all do the same thing. I think that the first is the only thing we really
have to worry about; the more complicated the thing, the fewer people are going
to invent their own way of doing it. If the number of object systems does get
to be a problem, THEN we should sit down and standardize on one, NOT BEFORE
[there will probably only be about two or three major systems in use].
Hey, why don't we standardize on silicon as the material that CL machines
should be made with? It's certainly used a lot...
On the flip side, a REAL programming system makes it easy for you to do REAL
THINGS. One such thing is writing your own object system if you need to,
rather than trying to force your neat abstraction into some inappropriate
scheme. There's always the chance that a programmer will do something silly,
but all you can do is give him the best tools and examples you can and hope he
learns. An object kernel (such as mine) satisfies reason 1 for standardization
(machine compatibility) without prematurely standardizing.
Of course, there can (and should be) a "standard Flavors" that programs can
use, so that if an implementation has the hooks (and, for worst case, I believe
the hooks can be implemented entirely in CL), then you just see that Flavors is
loaded (which sees that the hooks are?), and your program works fine.
De facto standards are different from standards frozen into the language; at
best, losing standards are ignored - at worst, they are used. I partially feel
that programs written with losing tools probably deserve to lose, although if
nothing better is available, I suppose the authors have no choice. I intend to
give them a choice.
What I've put into the kernel is all the basic stuff that I think a GOOD object
system will have in common with Flavors. The difference is mainly in how types
are "mixed" - I have no idea what the "correct" way of doing this is, but I'd
sure like to see it. Again, my current proposal for the kernel is in
[cmu-cs-c]<handerson.public>flavors-kernel.txt
Maybe this should start being considered as a proposal for a standard.