From: Stan Shebs
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <xdn2qto3gd.fsf@andros.cygnus.com>
······@netcom.com (Henry Baker) writes:
> In article <··········@engnews2.Eng.Sun.COM>, ······@tcl.eng.sun.com (John
> Ousterhout) wrote:
>
> > One of the most common criticisms of my white paper has been that the
> > distinction between scripting and system programming is artificial, and
> > that it is possible for a single language to be good at both tasks.
> > Lisp-like languages such as Scheme were suggested as living proof. I
> > can't prove that it's impossible for a single language to be good at
> > both scripting and system programming, but I don't know of a good example
> > and I doubt that it will ever happen.
>
> Two words: 'Lisp Machine'.
Uh Henry, that's not a very strong support for your position. If it
were really true that Lisp Machines were as hot as they were claimed
to be, and the Lisp implementation in it was good for all purposes,
then it should have been possible for Symbolics et al to do laps
around Sun, Microsoft, etc, and to have ground them all into the dirt.
Lisp Machines should have been able to add a C compiler during the
week and X support over the weekend, both client and server. It
should have been possible to build cross-compilers and retarget Lisp
code to any hardware in the following week.
These claims sound pretty hyped, but that was the kind of stuff that
Lisp promoters were saying back then. Of course, the real truth was
less exciting - Lisp is good for certain kinds of things, and not so
good for others, and Lisp programmers are not some kind of superior
intelligences who are the only ones that *really* know how to program.
I too was one of those who was sure that C would be swept away by
superior Lisp technology. And yet it proved that the Lisp technology
was not enough better to compensate for its drawbacks, the promoters
did not have solutions for those drawbacks, and that the conventional
language world was able to borrow individual techniques that proved
worthwhile, and thereby reduce the productivity and quality gaps.
> > In fact I suspect that
> > this may be why Lisp hasn't been used much for practical programming.
> > Lisp isn't a good system programming language because it's too hard to
> > write efficient programs in it and it doesn't provide good low-level
> > access to machine facilities.
>
> Utter claptrap. I've written many Lisp programs on the PDP-10 and the
> 68K (Mac) that run as fast as any hand-crafted assembler program.
Ah, but note that he said "*too hard* to write efficient programs".
It is possible to write efficient Lisp code, but you really have to
work at it. My observation of programming students is that they
usually wrote C programs of satisfactory performance on their first
try, and Lisp programs that were too slow, and after that it was very
hard to convince them that they should write their system programs in
Lisp.
> The Symbolics Lisp Machine also supported the C language, and an excellent
> C language it was. C on this machine wasn't particularly fast, but that was
> because the Lisp Machine had better things to do than to twiddle bits.
It took a very long time for the C compiler to appear, and at a time
when it was clear that Symbolics' survival depended on being able to
support mixed-language programs. So either Symbolics was lacking in
the ability to solve customer problems, or was not interested in doing
so. In any case, customers and prospects got the message, and went
elsewhere.
> > Many of the best minds in Computer
> > Science have worked on Lisp over the last 30 years, and they haven't
> > been able to fix the language so that it could be widely used either
> > for system programming or scripting tasks. This says to me that there
> > is something fundamentally wrong with the language, at least for these
> > tasks.
>
> I suppose that all of the excellent work in Lisp on scheduling space probe
> operations, scheduling factory operations, handling your American Express
> card credit ratings (in real-time, 7x24), scheduling Gulf War supplies,
> demonstrating the next generation of fighter pilot cockpit aids, etc., was all
> a mirage? I guess you see what you want to see.
Those are all big hairy applications, not system programs or scripts.
The applications you mention just show that Lisp can do what Ada and
Cobol and Fortran can do.
I'm afraid I have to agree with John O. Lisp had its shot at general
acceptance, and blew it. I spent 8 years of my own life trying to
solve its technical problems, and was unable to do so, and while I was
not one of the "best minds in computer science", I could see that the
many folks smarter than myself weren't making much progress either.
Perhaps it will fall to the next generation to rediscover Lisp.
Stan Shebs
Cygnus Solutions
·····@cygnus.com
From: Erik Naggum
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <3070619584848494@naggum.no>
* Stan Shebs
| If it were really true that Lisp Machines were as hot as they were
| claimed to be, and the Lisp implementation in it was good for all
| purposes, then it should have been possible for Symbolics et al to do
| laps around Sun, Microsoft, etc, and to have ground them all into the
| dirt.
why do you believe that businesses only need technical superiority to win?
if there is only one mistake that computer geeks make, it is to believe
that "good" is rewarded simply for being there. it isn't. never was.
the Lisp Machine industry died for lack of business savvy compared to their
competitors. Microsoft wins only because they have more business savvy
than their competitors. technical quality doesn't even enter the picture
as an argument until _after_ you are have become successful business.
#\Erik
--
Bastard Sex Therapist from Hell: "Read the F*cking Manual!"
From: Stan Shebs
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <xd67xeq509.fsf@andros.cygnus.com>
Erik Naggum <····@naggum.no> writes:
> * Stan Shebs
> | If it were really true that Lisp Machines were as hot as they were
> | claimed to be, and the Lisp implementation in it was good for all
> | purposes, then it should have been possible for Symbolics et al to do
> | laps around Sun, Microsoft, etc, and to have ground them all into the
> | dirt.
>
> why do you believe that businesses only need technical superiority to win?
> if there is only one mistake that computer geeks make, it is to believe
> that "good" is rewarded simply for being there. it isn't. never was.
If I had a computer system that gave me 20 times the productivity of
ordinary programmers, I wouldn't even have to bother with marketing; I
would simply produce 20 times as much software as my competition, sell
it for big bucks, then use that money to hire more programmers and
produce even more software. 20 times productivity would have such a
powerful effect on the marketplace that the merest whispers would
suffice to sell in huge numbers - every application developer that
used the more productive system would be swamping their competition,
and the competition would do research and eventually find out how that
was happening, then come to buy your product also.
If my productivity increase was more like 1.2 times, or if the
productivity increase comes with drawbacks, such as the need to buy 20
times as much hardware, then it's a more difficult sell, and marketing
becomes more important. That was the reality that Lisp machines ran
into; the improvements were there, but the effect on the bottom line
was awfully small for the investment you had to make. Microsoft
understands that well; instead of making revolutionary hardware
designs, they build software that runs on old machines that are
already out there.
It *is* possible to succeed without any marketing organization at all;
consider that GNU has become ubiquitous without anybody marketing it
at all.
Stan Shebs
Cygnus Solutions
·····@cygnus.com
From: D J Clark
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <335d4ee0.4279426@news>
On 22 Apr 1997 11:36:22 -0700, Stan Shebs <·····@andros.cygnus.com>
wrote:
>If I had a computer system that gave me 20 times the productivity of
>ordinary programmers, I wouldn't even have to bother with marketing; I
>would simply produce 20 times as much software as my competition
But what sort of machine will your customers need to run that
software? Unless the cost of software + hardware (not to mention
support, training etc) is competive
_from_the_viewpoint_of_the_Customer there is no financial inducement
to buy your software.
~~~~~
David Clark
·····@citizen.org.uk
From: Kelly Murray
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <5jjoad$47a$1@sparky.franz.com>
In article <················@news>, ·····@citizen.org.uk (D J Clark) writes:
>> On 22 Apr 1997 11:36:22 -0700, Stan Shebs <·····@andros.cygnus.com>
>> wrote:
>>
>>
>> >If I had a computer system that gave me 20 times the productivity of
>> >ordinary programmers, I wouldn't even have to bother with marketing; I
>> >would simply produce 20 times as much software as my competition
>> But what sort of machine will your customers need to run that
>> software? Unless the cost of software + hardware (not to mention
>> support, training etc) is competive
>> _from_the_viewpoint_of_the_Customer there is no financial inducement
>> to buy your software.
Certainly, but if you haven't noticed, one can buy a pentium class
machine with 16mb of ram and 1gb of disk cheaper than the cost of about
one day of consulting fees, or a couple extra days spent debugging.
And if that application is web-based, that hardware can be running a web server
which can serve a lot of customers, and so it can actually be a LOT of hardware
and STILL be relatively cheap.
In 1997, computing hardware is really almost free when compared to salaries,
and the lack of software to take advantage of the changing world
is becoming pretty obvious, even more so than before when it was also true.
That's why in today's interconnected Web world,
programmer productivity is everything, and all those mired in C++
and trying to see if JAVA can work,
will be left behind IF Lisp can realize its productivity potential
for real world applications.
-kelly murray (speaking for myself)
From: Frank A. Adrian
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <01bc5002$3d3e6ff0$6571df26@truth>
Kelly Murray <···@franz.com> wrote in article
<············@sparky.franz.com>...
> In 1997, computing hardware is really almost free when compared to
salaries,
Although this statement is true, it is often risky for people to base
business
plans on this fact. Because hardware, software, full-time personnel, and
con-
tract personnel are expensed differently, there may be
organizational/accounting
pressure to prefer one over the other. More importantly, remember that
tasks can
(in many manager's heads, at least) continue to be piled upon an existing
program-
ming staff almost limitlessly, so productivity can be gained simply by
giving
existing personnel more to do. This mindset obviates any need for capital
im-
provement or more staff.
> That's why in today's interconnected Web world,
> programmer productivity is everything, and all those mired in C++
> and trying to see if JAVA can work,
> will be left behind IF Lisp can realize its productivity potential
> for real world applications.
See above...
Frank A. Adrian
············@firstdatabank.com
P.S. The views expressed above are my own and do not necessarily reflect
those of my employer, its parent company, or any of either's subsidiaries.
* Frank A Adrian wrote:
> Kelly Murray <···@franz.com> wrote in article
> <············@sparky.franz.com>...
>> In 1997, computing hardware is really almost free when compared to
> salaries,
> Although this statement is true, it is often risky for people to
> base business plans on this fact. Because hardware, software,
> full-time personnel, and con- tract personnel are expensed
> differently, there may be organizational/accounting pressure to
> prefer one over the other. More importantly, remember that tasks
> can (in many manager's heads, at least) continue to be piled upon an
> existing program- ming staff almost limitlessly, so productivity can
> be gained simply by giving existing personnel more to do. This
> mindset obviates any need for capital im- provement or more staff.
I would hope that companies that do faulty accounting like this would
run into financial trouble sooner or later: unfortunately it seems
that they can avoid doing so somehow. I think a lot of it does come
down to the compatibility thing -- as people often say in c.l.l, you
can't use a highly productive language if it doesn't interact well
with <microsoft-pseudo-standard-of-the-week>. So somehow the huge
programmer-time expense is ignorable because you have to write in
visual assembler in any case. It's all rather sad.
--tim
From: David B. Lamkins
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <AF9BDFD7-7D704@206.163.124.179>
On Tue, Apr 22, 1997 6:36 PM, Stan Shebs <············@andros.cygnus.com>
wrote:
[large snip]
[c.l.l.tcl removed from crosspost]
>Microsoft
>understands that well; instead of making revolutionary hardware
>designs, they build software that runs on old machines that are
>already out there.
Have you installed a Microsoft product lately? It's been a very
consistent pattern that each new release of microsoftware is hungrier
for RAM, disk, and CPU than the previous release.
Ridiculous case in point: install Outlook (email) from Office 97.
Say goodbye to 27MB of disk space. For an email client!
No, if anything, Microsoft is keeping the hardware manufacturers in
business...
Dave
From: Brian Denheyer
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <m2lo5k2j3r.fsf@soggy.SeitzAssoc.com>
"David B. Lamkins" <········@teleport.com> writes:
> No, if anything, Microsoft is keeping the hardware manufacturers in
> business...
Well, they don't call it wintel for nothing.
--
Brian Denheyer
······@northwest.com
From: David Thornley
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <5jfv9r$8n7$1@darla.visi.com>
In article <··············@andros.cygnus.com>,
Stan Shebs <·····@andros.cygnus.com> wrote:
>
>Ah, but note that he said "*too hard* to write efficient programs".
>It is possible to write efficient Lisp code, but you really have to
>work at it. My observation of programming students is that they
>usually wrote C programs of satisfactory performance on their first
>try, and Lisp programs that were too slow, and after that it was very
>hard to convince them that they should write their system programs in
>Lisp.
>
My observation is that the first try of new C students simply doesn't
work, and what you call "their first try" is the result of a lot of
study and work. The comparable Lisp programs are easier to do.
To put this another way, consider a function in isolation, both in
C and in Lisp. In C, all variables are declared with a static type,
and the size of intermediate results has to be known (at least
roughly) for the function to be reliable. In Lisp, all the variables
can be declared with a static type, and if the size of the intermediate
results is known, that information can be used to optimize the code.
We can get further optimization by -O3 (or whatever) or using a
visual dialog or a (declare) or whatever.
Now, if you remove all of this type checking from the C program,
it doesn't run. If you remove all of it from the Lisp program, it
gets slower.
Now for some opinions. Most people are not good software engineers,
and Lisp gives them the option to be lazy up front. It is possible
to write Lisp just as efficiently as C, and with comparable effort,
but it isn't necessary. Further, there are situations, such as integer
overflow, that are handled accurately in Lisp (unless the programmer
specifies otherwise), and are simply glossed over in most C
implementations. Since most people aren't good engineers, they don't
notice this or allow for it. Therefore, most Lisp programs will
be written without the type specifications of C, and will further
sacrifice speed for correctness. Further, it is usually not necessary
to be efficient, so most people will not be familiar with how to
write efficient Lisp. Heck, most textbooks I've seen, with the
exception of Norvig's book, do not emphasize how to write efficient
Lisp, while many C textbooks do emphasize efficiency. (It's a
cultural thing, I think.)
Therefore, most people will write more efficient C code than Lisp
code, because they have to. Many people will see inefficiency as
a Lisp problem, partly because much Lisp is badly written and partly
because people pay too much attention to run-time efficiency.
David Thornley
From: Chris Bitmead uid(x22068)
Subject: Re: Lisp is neither (was Re: Ousterhout and Tcl lost the plot)
Date:
Message-ID: <s6ypvvklwiu.fsf@aalh02.alcatel.com.au>
Stan Shebs <·····@andros.cygnus.com> writes:
> Ah, but note that he said "*too hard* to write efficient programs".
> It is possible to write efficient Lisp code, but you really have to
> work at it. My observation of programming students is that they
> usually wrote C programs of satisfactory performance on their first
> try, and Lisp programs that were too slow, and after that it was very
> hard to convince them that they should write their system programs in
> Lisp.
For simple programs that students write, sure C will win in
performance every time. The real question is what happens when you
build a significant sized project. What tends to happen is that the C
programmer spends so much of the project finding silly bugs that he
doesn't have time to reorganise things to take advantage of a new
insight or algorithm. The Lisp programmer has got more abstractions
available to him from the beginning, and can redo things to find
faster algorithms more readily.