Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp From: Erik Naggum <clerik@naggum.no> Date: 1997/11/12 Newsgroups: comp.lang.lisp Message-ID: <3088289335876823@naggum.no> * David Hanley | Static binding because none of the lisp windows compilers I'm aware of | have a seperate .dll for lisp. if they did, it would solve the problem | right off. I have talked to some people who profess to understand this DLL business, and although they went on and on about how good and new this was (I think the first time I used shared objects where high segments under TOPS-10 in 1980 or so), it never became clear to me exactly how much you pay for it. one grudgingly admitted to a cost of about 5% overhead in a call-heavy environment compared to static linking. some of the *huge* Windows applications appeared to run 20% _faster_ with static linking than with DLLs in a test but this was not even commented on. I guess DLLs are more politically correct than performance. | If it shortens your development cycle, it sure does have an effect on | earnings. I believe this is an unsubstantiated myth. the evidence that it is true is simply lacking. "first-to-market" is _not_ the guarantee of success that many (managers) believe it is. (those winners who were "first to market" were not really _first_, they were first to hit _big_.) nothing suggests that frequent releases is a guarantee of success, either. still, many (managers) believe this, too, like gospel. | I agree that it is generally easier to program in lisp, and that it's | betterfor many purposes, but I don't think you can really substantiate | this claim either way. You can always create a contrived enough test | case to get the results you want. if so, it would be very interesting indeed to look at the test cases. various strongly substantiated reports indicate from 30% sustained average (Richard P. Gabriel, on Lucid) to 10-fold peak advantage for Lisp/CLOS over C++. | > also note that Lisp was years _ahead_ of other languages for a long, | > long time, and that many of the ideas from the Lisp world have been | > adopted by the other world. | | And....??? I'm trying to point out to you that you criticize a snapshot of Lisp, while you are obviously willing to judge other languages in terms of a process of ongoing changes and improvements. this may be because you think that Lisp is a "finished" language in the sense that you don't expect further changes or development. again, this is _your_view_of_Lisp_, and has very little to do with Lisp itself. that you also limit what Lisp is so that it _cannot_ be whatever would have been a winner indicates that you either ignore or don't know the past. | You are stubbornly ignoring the issue. geez, first DLLs and now this. are you a member of the Martin Rodgers fan club, too? | This is particularly true for an obvious reason: people aren't going to | make big lisp apps unless they can do some small ones first. oh, I see, so this is "obvious", which means you won't even _attempt_ to elaborate and you will accuse people of "stubbornly ignoring foo", for suitable values of "foo" if they reject your "obvious" claim. great! FYI, this is _your_ view of Lisp and of applications. you may find people who agree with you, but the important thing with beliefs is to challenge them and find contrary views. your response to that is, of course, that I'm "stubbornly ignoring the issue", as if we had a government approved agenda and I was somehow in violation of it by bringing up ideas and angles that you are dead set against considering. | If people can't make small apps in lisp, they're not going to progress to | big ones. Very simple. it's actually amusing, in a sad and tragic sense, that you have already decided on this and is impervious to empirical evidence to the contrary. | By the way, can you exaplin how user productivity is tied to CPU power in | your model? FWIW, they are clearly unrelated. users are no more productive with 50 times faster CPU's with 100 times more memory if they use the latest and greatest software from Microsoft. an acute observation from at least 20 years ago was that every program grew to consume all available resources. this observation has been strongly reinforced on the Windows platform. as for productivity in real money terms: according to a report in the Economist earlier this year, the cost of producing any piece of business communication dropped along with advances in computers from 1950 through 1980. from 1985 through 1995, it rose sharply enough to consume all earnings made since 1950. it is significantly more expensive to produce a business letter in 1997 than it was in 1950. despite many technological advances with a very high price tag, a secretary does not produce any more measurable output now than in 1950 -- in fact, the evidence suggests that obtaining _half_ the productivity of a 1950's secretary in 1997 is a major feat. the fact that managers write their own reports at down to 1/10th of the speed of a secretary that used to be paid 1/10th of their salary also means that the time spent producing a letter or a report can cost as much as 100 times more than it did in 1950, when managers scribbled unreadable notes and very quick and efficient typists corrected their spelling, grammer, and language and adhered to "company style" effortlessly. there are other areas where computers have introduced major advances, such as communication, but this didn't happen until wide area networks began to be deployed in the mid-90's, and this was clearly _not_ due to massive increases in CPU and memory on the disconnected PC's, who _still_ are not very good at interchanging information. (they're _very_ good at being the same kind of propaganda and marketing reception equipment as TV's, though.) | To place lisp in the same context makes no sense at all--it's a general | purpose language that ought to be good for writing all sorts of | applications. If I make a handy-dandy program that I want to distribute | to a lot of users, (say a file compresion program) no one will use it if | they have to fire up a lisp enviornment first to run it. "you are stubbornly ignoring the issue." it's _your_view_ of Lisp that is at fault here, not Lisp. people _were_ willing to run Windows as a separate environment apart from their usual DOS commands to run "Windows software". people are willing to fire up various programming environments (except they aren't called that) to run useful programs _inside_ them already, many of them in your neighborhood (i.e., Windows), such as Excel or Word. | > in other words: it depends on what you consider your environment. when | > most users spend their entire working day in a single application, | | I've not notice this. that suggests to me that you may have neglected to notice other aspects of the users of which you speak so generally in such specific terms, as well. | > what good does it really do to complain about the size of a standalone | > program when a function call would have far smaller costs when run | > inside an application the user is already running than a standalone | > program could ever hope for? | | What you seem to be suggesting here is that the user works in alisp shell. uh, now I wonder if you have noticed much around you at all. how do people interact with their (Windows) environment today if it is _not_ that they work in what is effectively a C++ shell? would they have to type in C++ code for you to consider it a C++ environment? they fire up "apps" (what a godawful abbreviation) _inside_ that environment, and some of them may have to start up the whole environment first (remember the DOS command grossly misnamed "win"?). Unix users work in a shell that works hard to make it immaterial if a "command" is a builtin or a "function" residing on disk as a separate program. whether a program is a part of the "shell" or is fired up in a separate (operating system) process should not matter to the user. indeed, that it matters to _you_ is symptomatic of a strained relationship with environments, programming or otherwise. other Windows users seem to be equally tied up in their _particular_ environment, completely forgetting any semblance of conceptualization of "environment" or its purpose for a computer user. I wonder why this is. I wonder if this is a contributing cause to my strongly disliking the Microsoft "environments", too. | That's unrealistic in the basic sense, but a lisp OS will solve the | issue. How can users be induced to run a lisp OS? this, again, suggests that you have a _very_ narrow view of Lisp. it is apparent that you don't even think of Lisp as an environment, much less an environment-building language. I do. to you, Lisp is a language, and any application is built "with Lisp, on top of my existing environment", which is Windows, right? in a sense, Windows is a result of the way C++ builds environments, like Unix is a result of how C does it. if you had looked at the Lisp machines, you would have seen what kind of an environment Lisp can build. likewise, the Emacs programming and text processing environment (I'll bet you classify Emacs as an "editor") is a result of what it is easy and convenient to do in Emacs Lisp. also, users aren't induced to run operating systems or even applications -- they are induced to do whatever is necessary to continue to get paid. many programmers complain that even _they_ cannot choose their own tools, for fear of losing their jobs. (this appears, for some _odd_ reason, to apply mostly to Windows programmers.) #\Erik -- if you think this year is "97", _you_ are not "year 2000 compliant". see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.