do...until wisdom needed...

[Douglas Alan]

"Andrew Dalke" <dalke at acm.org> writes:

> As you yourself pointed out, its introduction [OO] into Lisp at the
> time doesn't mean anyone used it.  

That's not true.  Lisp programmers glommed onto OO right away.
Certainly long before Smalltalk 80 was released.  (This doesn't mean
that *all* Lisp programmers did.  Some were traditionalists who
resisted change, but it was certainly very prevalent among the
community.)

> For example, take a look at xemacs.org's history page where it
> mentiones the differences between emacs event message data structure
> and xemacs's OO interface.

I don't know what you can infer from Emacs Lisp.  Being used for a
particular constrained domain, it wasn't given many OO features.
General purpose Lisps were.

> So I take that to mean the infusion of OO programming into Lisp did
> not make strong headway until years after Smalltalk came out.

Being too young to have been paying attention at the time, I don't
know how widely used Smalltalk was in '72.  My impression is that it
didn't get much attention until Smalltalk '80, by which time the Lisps
being developed for general purpose programming had all been
thoroughly infused with OO features.  I fully agree that OO as we know
it today, began with Smalltalk.  But Smalltalk itself is significantly
derived from Lisp, and OO owes a lot to its Lisp heritage, just as it
does to its Simula heritage.

> >Just because some people were using OO, doesn't mean it had "caught
> >on" in any serious way.  I was doing OO in Lisp in 1980, but finding a
> >job doing that would have been something of a challenge.

> What does "caught on" mean, then?  I interpreted it as "people knew
> that that was the paradigm they had to learn, I had written some
> objects (in Pascal), people were graduating from school to start
> jobs doing OO programming, and text books were coming out targeted
> towards C++."  I bought the 2nd ed. of the C++ programming language
> book in 1991 and by 1993 I was working on OO code that was already
> several years old.  Perhaps I'm more cutting edge than I thought.

Yes, you are.  In the late 80's C was the orthodoxy for commercial
development -- cracks in the orthodoxy were starting to become
significant by 1990 or so and consequently C++ was just beginning to
catch on in any serious way by then.  It took a few more years for it
to become as popular as C, and then eventually to replace C as the
more mainstream language.  Object Pascal and the like were always just
tiny niches.

> Sill, that's a much stronger "caught on" compared to your statement
> that OO programming caught on in Lisp roughly two hours after
> Smalltalk-72 came out.

I was thinking more of Smalltalk-76.  I've never met anyone who ever
used Smalltalk-72.

> > Lisp *is* widely used for AI.  In fact, the vast majority of AI is
> > done in Lisp.  And Scheme *is* widely used for teaching Computer
> > Science.

> I never denied that.  I just regard AI and teaching languages as
> small domains compared compared to everything else which goes on in
> the world of programming.

That might be true -- but they are both extremely important domains.
A.I. researches, for instance, are working on the most ambitious
problem man will ever attempt to solve.  One might ask why they chose
Lisp for this task.

> > If you want to see how popular macros are, you need look no
> > farther than C.  I don't think many C programmers would want to
> > give up the macro mechanism.

> Okay, that's a good point.  But doesn't that then reflect more
> poorly on C?  I've created some heineous C macros but I've never
> felt the need to do the same tricks in Python, because I can
> getattr, I can define functions on the fly and I can even (in rare
> cases) do an eval of string.  I don't think I've ever bemoaned the
> lack of a cpp or m4 for Python.

No language can anticipate all the needs that programmers will have
for the language for all time into the future.  The future will always
speak poorly of older languages.  This can be mitigated to the degree
that the users can grow the language to meet their needs.  You don't
bemoan CPP for Python because Guido made sure that Python was powerful
enough to make CPP more or less redundant.  But he didn't make it so
powerful that a *real* macro mechanism would be redundant.

> Ahh!  Now I know why there was a mental block.  In my programming
> languages book ("Principles of Programming Languages" by Bruce
> MacLennam, (c) 1987) there's a section called "Return to
> Simplicity" where it talks about extensible languages.  (All
> typos mine.)

> [Interesting material on languages with extensible syntaxes
> snipped.]

I haven't heard of these other languages.  Thansk for the interesting
material -- I'll have to check into them.

> ]  Unfortunately, extensibility usually resulted in very
> ]  inefficient languages. ... compilers large and unreliable ...
> ]  minor inefficiencies in the kernsl implementation became
> ]  magnified at the application language level

I don't know about the flaws of these languages.  The macro mechanism
in Lisp or Dylan certainly doesn't make them "inefficient".  If
anything, they can allow you to write code that will run faster.
Perhaps he is refering only the time and space requirements of the
compiler itself?  Computers are fast these days.  I can't imagine that
this would even be more than barely noticeable today.

>  ...
> ] poor diagnostics ... most diagnostics were issued in terms
> ] of kernel language constructs.  This was, of course, confusing
> ] for a user working at the application language level.
> ]   These problems, and others, ultimately defeated extensible
> ] languages.  Although they were once the most active area of
> ] programming language research, they are now rarely discussed.
> ] This does not imply that all of their ideas have been
> ] abandonded; we will see that the idea of extensible data
> ] types has been incorporated into Pascal and its successors
> ] and that a limited form of operator extension is provided
> ] by Ada.

> (Huh, and Lisp not mentioned at all.)

Well, that's just wack then.  If you write about extensible syntaxes
and you don't mention Lisp, you are almost criminally negligent.

> It raises some strong points which you need to address - how
> complicated is the implementation, how fast is the resulting code,
> how easy is it to understand, how easy is it to debug?  Oh, and how
> well do support tools (editors, debuggers, pretty printers)
> integrate with syntax macros?

The implementation need not be complicated.  The resulting code speed
should be significantly faster than using most alternatives.
Debugging can be an issue.  Broken macros can be hard to debug.  A
person who implements a macro should test his code well.  Support for
macros in other tools is no more difficult than for features such as
OO and functions, but requires some amount of effort to do correctly.

> You assert it's not a problem.  In response I've given my
> judgement (that it is) the views of others (that it is) and
> references from the literature (that it is).

The references from the literature are from language that I've never
even heard of (and I've heard of *plenty*) by someone who doesn't even
mention Lisp.  Regarding whether it's a problem -- all tools are
solutions *and* problems.  Only experience can tell you how much of
each a particular tool is.

> Proving otherwise then becomes that much more complicated, which
> explains at least some of the resistance you've seen from me and
> others.

The proof of the pudding is in it's eating.  I've eaten from the macro
pudding and therein I found all the proof I need.

|>oug