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.