Re: Is Lisp a Blub?

Pascal Costanza <pc@xxxxxxxxx> writes:

Duane Rettig wrote:
Pascal Costanza <pc@xxxxxxxxx> writes:
It seems to be the case that for ultra-large-scale programs, garbage
collection is not feasible anymore. (That was also the message in Jans
Aasman's talk at ILC'07.)
It's unfortunate that that is what his talk appeard to emphasize.

My statement was obviously too dense. Sorry for that. If I understand
correctly, what seems to be feasible is to divide storage into
different regions which are handled differently. Some regions can be
nicely garbage collected, while others need a more manual approach,
due to the size and longevity of the data to be stored.

Yes. When it comes down to it, memory has always been (and will
likely be for a long time, barring some inventions) a linear resource,
and dividing that linear resource into "the right size" segments for a
task is always going to be an issue. Right now, we have a new
breathing space, having expanded into the world of 64-bit addresses,
and thus the segments of memory allocation are less likely to run into
each other like they were starting to do for 32-bits, but that will
not last forever, and truly scalable programs will quickly use up this
memory space which will still have to be managed carefully.

My
understanding was that Jans's talk was about similar ideas. I have
never understood it as saying that we should get rid of garbage
collection altogether.

That's a relief, but it's not surprising. My comment was not made to
you, per se, but to your statement, which you have now retracted but
which I have heard others say as well (and perhaps meant it when they
said it).

I think the subtext of Gregor's article is important here: It
basically tries to suggest that annotations + AOP are good
enough. (While they in fact only provide a fraction of what macros can
do. At least that's how I understand his article. It's also
interesting to read his follow-up article in that regard - see
http://www.ddj.com/dept/architect/184415205 - to quote: "In April, I
summarized attributes, explaining that they introduce into C# the
basic syntactic hook required to enable Lisp-style macros.")

Well, doesn't this suggest to you then that either he was wrong in his
implication that annotation + AOP are good enough, or that he changed
his mind, or that your understanding of his emphasis was not quite
right? Why would he be looking toward providing Lisp-style macros
unless he thought what was available was _not_ good enough? I don't
personally know what he is thinking, so I don't know which of the
three are true. And it doesn't matter much, but I have a gut feeling
that in his career as language-improvement researcher, he would tend
to _never_ call something good enough, unless it is only for the
moment.

It was then and there that I learned to _balance_ use of
macrology and out-of-line code, and, as with any other great concept,
to use it in moderation, where it was necessary, rather than where it
was possible.

Yes, these are very wise insights, but not good reasons to drop macros
altogether and replace them with something much weaker, IMHO.

Since I never advocated dropping macros, I am assuming that you are
referring to Gregor's move out of Lisp and into other languages with
AOP. It is interesting that many old Lispers move away from Lisp and
try their hand at something else - many of the Dylan inventors were
ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
turned out not to be a problem at all) - others try to invent new
ways of programming altogether. Gregor seems to have moved into
an area that is more productive; taking existing languages and
retrofitting them with Lisp-like qualities. It is clear that these
retrofits will be weaker; the moment someone discovers a hybrid that
is better than Lisp, we'll probably all start moving toward that
next-generation language... But the retrofits clearly make the other
language stronger, if not as strong as Lisp.

--
Duane Rettig duane@xxxxxxxxx Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
.

Relevant Pages

  • Re: "Unified model" for beginners
    ... What insult would it be to say "hey, it can do something like what LISP ... languages and implementations, reduce it to that "essential essence" only ... Molecules and atoms (okay, we don't actually "see" atoms, this is a ... "subtraction" and then lots of "HLLism macros" to create all the other ...
    (alt.lang.asm)
  • Re: a LISP raytracer
    ... > None of the free Lisp compilers come close to the capabilities of Stalin. ... > OCaml does has camlp4 macros. ... My languages professor right now is a huge fan ... on OCaML, and not so much with LISP. ...
    (comp.graphics.rendering.raytracing)
  • Re: Paul Grahams teaching style is bad
    ... > remaining distinctive features of lisp are a good thing. ... > languages have been picking up from lisp for so long was the big deal, ... > and that macros are only marginally important by comparison, ...
    (comp.lang.lisp)
  • Re: Very poor Lisp performance
    ... What practical problems are easier to write in Lisp than in other languages? ... Lisp's macros are more powerful than OCaml's and Lisp programs are likely to be faster than Mathematica programs. ... The essence is that Lisp allows you to embed any kind of language, and mix Lisp and the various embedded languages in your programs. ...
    (comp.lang.lisp)
  • Re: Is Lisp a Blub?
    ... collection is not feasible anymore. ... not get the power of macros. ... Lispers will latch onto a concept - "X is the greatest thing in Lisp" ... it was an exercise in extreme macrology. ...
    (comp.lang.lisp)