Subject: Re: superior(?) programming languages From: Erik Naggum <news@naggum.no> Date: 1996/12/21 Newsgroups: comp.lang.lisp Message-ID: <3060170155406784@naggum.no> * 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 "distinction"? 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. #\Erik -- "He didn't care." "They never do."