Subject: Re: superior(?) programming languages
From: Erik Naggum <>
Date: 1996/12/21
Newsgroups: comp.lang.lisp
Message-ID: <>

* Cyber Surfer
| Is it needed at runtime?  I think not.  You may insist that EVAL
| is needed at development time, but I don't think that's what Tim
| is talking about.  I know that _I'm_ concerned about runtime.

loading code or reading data into an application may require facilities not
normally associated with "runtime", such as the #. reader macro.  such
forms may even be generated by `print' (unless you bind *read-eval* to nil,
in which case some data cannot be printed at all if you also have
*print-readable* bound to t).

| Great, but not all of us need to read symbolic expressions _at runtime_.

now, what does this argument mean?  is your real argument that Common Lisp
should not have EVAL because "not all of us" need it?  why don't you also
mention hundred other functions in Common Lisp that "not all of us" need?
can you imagine that "not all of us" actually need _computers_ in the first
place and that this argument can be used for _anything_, and thus has no
defined range of validity, i.e., should be discarded as a priori invalid.

I can think of nothing that addresses what "all of us" need or want if it
is taken literally, and if we limit "us" to programmers in only _some_
domains, we must be very explicit about who the "us" are before the
argument can become valid.  since this is not normally done, it is much
easier to name the "us" of whom "all of us" _can_ or _do_ need something,
and that's the point in having a programming language _community_ instead
of each of us sitting down to write our own languages and compilers for
them from scratch.  (incidentally, my first inclination was also to write
my own Lisp tools.  fortunately, I got over this delusion -- I have time to
write _either_ tools or something useful, just like Larry Wall had the time
to write Perl, while all the system administrators around the world only
had time to do their job.  I quickly realized that building a Lisp system
is not something I could do on my own.  once you start to use a commercial
Lisp system, you also quickly realize how much more there is to a Lisp
system than just a compiler.)

| Can you understand the distinction between development and runtime?

the real question is whether you can understand the difference between what
you can think of and what others can think of.  your asking such idiotic
questions only goes to show that you are unable to understand how others
think, and isntead relate everything to your own deficient understanding.

moreover, that distinction is not as hard and fast a distinction as you
seem to believe it is, or indeed necessarily _where_ you think it is.  in
static languages, such as C and C++, development and runtime are of
necessity hard distinctions, and they can be in only one place.  in Lisp,
development and runtime form endpoints of a wide range, and the distinction
can be in a wide subrange of places within that range.  e.g., if you
dynamically load patches into a running system, are you "developing" or
"maintaining a runtime system"?  if you make it possible for patches to
dynamically deinstall themselves if they contain programming errors, so as
to keep a running system running even if your patches are broken, are you
developing, or just maintaining a 100%-duty cycle system that cannot ever
go down or stop working?  the latter is possible if and only if you aren't
anal about the distinction between development and runtime.

some real-life examples of where this distinction is intentionally blurred:
on an oil rig, "development" and "deployment" overlap with at least 5
years.  an airplane has so much maintenance work done on it during its
lifetime that after about 10 years, no single part of the delivered machine
can be expected still to be in place.  Lisp systems don't always need to be
grounded to undergo maintainance.  C systems do.  what does this do to your

I conclude that you do not even _want_ to understand how others are using
Lisp, but insist upon your own world view as the only valid one.  this is
like how many Europeans view Americans.  somehow, the popularized version
of "American" in Europe is that of a member of a largely homogenic group of
people, at least in important aspects.  but once you actually live there
for a while, you start to appreciate the much _wider_ range of people in
the U.S. than you find in Europe.  thinking in stereotypes may be useful in
saving time and effort, but one also needs to know when to stop doing it.
this EVAL discussion is one of arguments against stereotypical uses of EVAL
without EVAL-bashers wanting or even trying to understand non-stereotypical
uses of EVAL.  it is as if a European tourist would walk up to an American
that didn't fit his prejudices and say "according to my tourist guide and
my baggage of cultural stereotypes, you don't exist", except, of course,
that everything up to the comma is usually omitted for brevity and effect.

I'm still hoping that you would take a more interested view of a community
and a language that you are trying to communicate with than you do.  and,
no, I'm not a long-time resident or anything, I'm just new enough in this
neighborhood that I haven't tired of defending it from prejudices, yet.  I
defended Unix and C and SGML for a number of years, too, if that is any
comfort to you.  that I'm defending something does not mean that I can't
make mistakes in doing so, it only means that the mistakes you make are
much bigger than the ones I may be making.

"He didn't care."
"They never do."