Re: s-exprs + prototypes

[Matt Hellige <address@hidden>]

[Anton van Straaten <anton@appsolutions.com>]
> Matt Hellige wrote:
> > [Anton van Straaten <anton@appsolutions.com>]
> >
> > Well, rhetorically speaking, is it really better to go the other way?
> > Would you rather implement an SUV by first building a really tough,
> > heavy-duty scooter, then strapping 5000 pounds of steel and a
> > big-ass engine to the top?
> >
> > When it comes to language design, I guess I feel like that's actually
> > the right approach, more or less (but better make that scooter really
> > bulletproof and low-friction)... But the analogy makes it sound
> > awfully silly...
> 
> Hey, you turned my analogy upside down and broke it!  OK, bad analogy.  When
> it comes to functions vs. objects, I see functions as atoms and objects from
> any given object model as a particular class of molecules, i.e. not all
> possible molecules.  I want to be able to use atoms to build other kinds of
> molecules, and I don't want to have to resort to some low-level language to
> have to do that, nor do I want to have to use an excessively high-level
> language which may entail a design approach or other assumptions that aren't
> appropriate.
> 
> Of course, the one-object-model fans think of their particular kind of
> objects as atoms, but I find that doesn't work for me, because of the
> paradigm and associated restrictions it imposes.
> 

I've tried to mostly stay out of this, but I think that this is really
the central point. I think that there are at least two arguments that
can be had here (and I think various people in this thread are having
both, which confuses things).

Argument One:
 A: Programming languages should be based on the smallest reasonable
    set of semantic primitives, on which everything else is built.
    These primitives must be theoretically well-understood and
    fast enough to support everything else.
 B: Programming languages should have built in support for the
    problems they're intended to solve. Orthogonality and simplicity
    of these primitives is secondary. Sometimes even theoretical
    soundness is secondary.

Argument Two:
  X: Position A above, with the stipulation that the lambda calculus
     (with its primacy of the function) is the only suitable such
     basis. It, with *minimal* necessary extensions to support
     practical programming, is optimal in every sense, and more
     importantly, is IN AN ABSOLUTE SENSE the most neutral, most
     agnostic, most impartial foundation for programming.
  Y: Position X above, but replacing lambda calculus with some other
     foundational system du jour. I.e., "Those Lisp people are crazy,
     their formalisms suck, in fact the only way to go is
     such-and-such an object calculus from such-and-such a page of
     Cardelli and Abadi's _A_Theory_of_Objects_."
  Z: Position A above, but with the firm belief that there are
     multiple more-or-less equally reasonable and more-or-less equally
     small bases for programming, and that among these, all are just
     about equally restrictive, equally impartial, and equally likely
     to taint the primeval blank page with which a programmer
     approaches a new problem (if such a thing really exists).
     Typically, it is then argued that it is, at the very least,
     fruitful to explore these other possibilities, in the hope that
     one may be found that is within acceptable parameters of elegance
     and orthogonality, but which programmers are quicker to adopt, or
     more productive, or whatever.

I feel like the majority of people on this list, or at least in this
thread, adopt position A, although it seems that sometimes proponents
of position X seem to impute to their adversaries position B,
presumably because they either misunderstand, don't admit the possibilities
of position Y and Z, or because they simply find it a convenient and
persuasive rhetorical device. After all, who would sympathize with
someone arguing for position B? ;)

For full disclosure, I should now say that I am a proponent of
position Z, with some Xward leanings. I'm sure this is probably pretty
obvious from the many clues in the above.

What I object to in position X is the blindness that this has to the
ways in which Lisp shapes and restricts program design, emphasizing
some things and de-emphasizing others, making some approaches seem
reasonable and others, in your own word, "baroque." 

If it's not a case of noticing the splinter in the OO eye while
neglecting the beam in the Lisp eye, I argue that we've at least all
got splinters.

Futher, I think the dialog betrays something of the social facts of
language theory. The primacy of the function is largely secured, and
proponents of position X speak from this relatively unassailable high
ground, making questions like "Is there really more than one way to
call a function?" mainly rhetorical. This is aggravated by the fact
that the primacy of the function is secured only within the confines
of "academic" programming, lending a general sense of the beseiged but
righteous crusaders defending against the barbarian horde.

If the basic assertion is that OO languages should have a more
elegant, smaller formal basis than they often do, I'd agree. In fact,
so would many others: the majority of OO proponents here advocate a
move toward semantically (and often syntactically) small and elegant
prototype-based languages over the heavy class-based languages of
yore.

If, on the other hand, the assertion is that any such basis must be
Lisp, I disagree. In fact, a stronger statement is often made: any
such basis _will_, de facto, be Lisp, whether the benighted OO people
know it or not. This is the final major armament in the hands of
position X, and it guarantees X's final unassailability (or so some
believe): "Whatever you THINK you're doing, you're REALLY doing Lisp."
Arguments of this form are enormously powerful and subversive, and at
times they can serve to preserve power, and at times to undermine it.
Their effectiveness, however, often hinges on a sleight of hand, in
which a two-way equivalence is made to appear as a one-way reduction.
I believe that's what happens here. If it's true that, in the right
context, we'll realize that my formalism was really always already
your formalism, then in some other context, it'll be clear that your
formalism was really always already mind. The question then becomes,
who gets to name the context?

Whether, in the end, these alternative formalisms will have anything
to offer us, or on which levels, remains to be seen.

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net