[Postmaster@STONY-BROOK.SCRC.Symbolics.COM: Unable to deliver letter]

[Reti@STONY-BROOK.SCRC.Symbolics.COM (Kalman Reti)]

Date: Wed, 28 Aug 1991 14:55 EDT
From: Postmaster@STONY-BROOK.SCRC.Symbolics.COM
Subject: Unable to deliver letter
To: Reti@STONY-BROOK.SCRC.Symbolics.COM

Unable to deliver letter to the following recipient:
  slug@warbucks.ai.sri:
    After contacting the relevant domain servers, the Mailer has been
    informed that there is no domain named "warbucks.ai.sri".

----- Text of letter follows -----
Received: from ZUGSPITZE.SRETI.SYMBOLICS.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 980203; 28 Aug 1991 14:45:06-0400
Date: Wed, 28 Aug 1991 14:52-0400
From: Kalman Reti <Reti@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Symbolics prices (not only in Europe)
To: baechler%liasun3.epfl.ch@Warbucks.AI.SRI.COM
cc: slug@warbucks.ai.sri
In-Reply-To: <m0kFTV9-0000dBC@liasun3.epfl.ch>
Message-ID: <19910828185200.1.RETI@Zugspitze.SRETI.Symbolics.COM>

    Date: Wed, 28 Aug 1991 14:16 EDT
    From: baechler%liasun3.epfl.ch@Warbucks.AI.SRI.COM (Emmanuel Baechler)
[This will, I fear, have to be my last set of comments on the topic (I have real,
customer-funded work to do) but I think this is an important enough concept
to take one more stab at getting it across.]

    >[...]
    >
    >Seriously, that is the reason we consultants who use Symbolics' machines to
    >deliver complex production software in a short time can still "clean up"
    >(and are).
    >
    > [...] (a lot of very good TECHNICAL reasons deleted)
    >

      I know that lisp machines can be impressibely efficient and flexible, and
    that people can do incredible things with them. However, the problem is not
    a technical problem, it is a problem of PRICE. For example, very few people
    are willing to pay $1000000 for a car, no matter how good it is. 
Because a $1000000 would only do basically the same job that a $10000 car does,
namely transport you from place to place at speeds of up to about 60 m.p.h.  People
routinely DO pay more than $1000000 for significantly greater functionality (e.g.
much higher speeds like Mach 3, or armor plating, or ability to go through water
or outer space).
								     I guess that
    there is a similar problem about workstations. In this case, the problem is
    even worse, because most vendors are dropping their prices impressively,
    while symbolic's ones remain fairly high. 
My point is that you can't compare a workstation where you can't do the types of
things you can do on a Lispm based only on the things that you can do on both,
i.e. the lowest common denominator isn't a valid basis of comparison.

By all means, if you have only projects which fit on simpler (and cheaper) system,
use those simpler and cheaper systems.

But the point is that unless you are only using a canned program and doing absolutely
NO development, program debugging, program understanding, the costs of using the
machine far outweigh the costs of buying the machine.  The trouble is that these
costs are much harder to measure (how much added salary goes towards doing things
inefficiently on the machine? What's the dollar value of lost opportunities that
a quicker development cycle would have prevented?) and so are generally ignored.

It is probably also partly due to the academic environment, where each person
usually doesn't have deliverables that bring in income, hence it is hard to
factor in the effect of productivity on one workstation compared to productivity
on another.
					      In the U.S. the problem is a little
    bit smaller for Universities: the have a 40% discount, while, in Europe,
    we only get 15%. However, I am don't consider that these discounts really
    solve the problem.

      Most adminstrators in universities (I guess that it's the same in
    compagnies) consider that the price of lisp machines is not an adequate price
    for a workstation, even if they are incredibly efficient. 
The workstation isn't the issue, the software produced is the issue.  If it costs
12 million to develop system X on a Sun, and 2 million to develop it faster on
a Lispm, and system X starts saving you millions of dollars a year, the price of
the workstation is barely considered in the equation (it is down in the noise).
There are literally thousands of such projects out there in the real world; these
number are not exaggerations.
							      Do not forget that
    most of these people are political or managment people who frequently don't
    even really understand the difference between a workstation and a high-end PC
    (when they understand what a PC is).
They understand the difference between development budgets; there is a customer of
Symbolics who routinely quotes consulting contracts on both Symbolics platforms
and on non-Symbolics platforms.  The cost differential is reputed to be 2-to-1,
i.e. he will develop the same thing on the other platform for twice the cost.
(I personally think this ratio doesn't reflect adequately the REAL costs, but
is set by market forces.)  Clearly, if the project only costs $10,000 to develop
on the Lispm and $20,000 to develop on a non-Lispm, the cost savings on that
one project alone doesn't pay back the difference in workstation cost, but not
many projects are that small.  However, even a politician or a management type
can't ignore a factor of 2 cost difference...

      The result of all of this, is that the potential market of Symbolics buyers
    is fairly small. 
If you are saying it is not a mass market, I agree with you.  The vast majority of
the world's computer users are still seeing computers for the first time, and are
still by and large trying to do simple things with them.  For simple projects, almost
any tool set and approach can be made to work.

However, in my opinion, there is a growing set of people who want to push the limits
of what is doable on computers; that set quickly realizes that software costs (both
development and support) rise exponentially with the complexity of the system, and 
that therefore only certain approaches will "work" in the sense that they will
deliver the goods with an acceptable cost.  This is currently the market I see for
Symbolics.  Over time (measured in decades), it will grow to become a sizable
fraction of all computer users (though perhaps never a mass market in the sense of
"a PC on every desk").
		     My fear is that, with the decrease of the prices of the other
    workstation (unix boxes) and their increase in performance, it will shrink 
    even more, unless lisp machine manufacturers change their price policy
    (and, maybe, their products).
Again, which performance are you measuring?  The cost to solve problem X includes
not only the hardware, but the training, documentation, development, support, etc.
The raw hardware box part of the cost is going down, but all the rest are going
up.  For a greater initial outlay for the box on a Symbolics, you get to have significant
savings on some of these other aspects (if you do things right).

And here is the crux of the issue; being a developer on a Lispm is a virtuoso
activity.  This means that it requires both the tools as well as training and practice
at effectively using those tools.  As in all human endeavors, one can inefficiently
use (or misuse) very powerful tools, which obscures their power and value.  Symbolics'
main failing (in my opinion) has been that we haven't managed to convey the skill of
using the Lispm the way we do to our customers.  This is one of the things we are
working on in the consulting group.

      I am convinced that lisp machines are *REALLY* valuable tools. However
    their prices are such that many people (especially administrators) refuse 
    to buy them, even if they admit that they are really good tools, because
    they consider that they are overpriced, as worksations.
I think the main issue is that there aren't usually measured deliverables for
accomplishments using the workstations in academia, so the goal becomes just
drop a tool on the person's desk for the cheapest cost and see what he accomplishes
with it.

In business, you don't just by a workstation to put on everyone's desk, you have
a project that justifies the use of the workstation.  If you don't save money by
buying the workstation, you generally don't buy it.

Projects which justify workstations come in two flavors (at the moment): ones
in which you just use some set of pre-written applications (delivery) and
ones in which you modify/write new applications (development).  Obviously,
the types of justifications I give above for using the Lisp machine don't
apply to purely delivery workstations.

However, I think this situation is not likely to be permanent either, since
many people in the "delivery" situation want to improve their use of the
machines/applications to be more efficient, and that requires customization
which is a form of "programming".  Hence the interest in things like macro
packages, visual programming tools, etc.

In my long-term view of computing, we are at a point where programming is
still too much intertwined with having a lot of detailed, arcane knowledge of
the computer system, which is why most people don't want to do it.  But,
in its most general sense, programming is just problem solving, which everyone
does every day of their lives.  As we progress towards languages and systems
where you can concentrate on solving a problem rather than on finicky details
of the computer system, the opprobrium attached to programming as we know it
today will fall away, and the features which make a Lispm a good development
environment will apply to delivery situations too.  The Lispm is only a small
step in that direction, but it is certainly farther along than anything else
I know about.

The bottom line for me, personally, is that, while I was considered and
excellent programmer on IBM 360 systems, on DEC timesharing systes and
on VAXes/PDP-11/PDP-8 (e.g. toy) computers, I can get about 10 times as much
working, quality functionality written per unit time on a Lispm as on
any other environment I've ever used.

      The situation is even worse in Europe, not only because of the much
    smaller academic discounts, but also because the service is much poorer.
Poor service is clearly a problem; I think you should take this up with
Symbolics management, either in Germany or, if that fails, in the US.
A machine is of no use and can provide none of the benefits I've mentioned
above if it doesn't work.  (That applies to bug fixes.  My personal philosophy
is that fixing bugs is the highest-priority software work; only in the gaps
beyond it should you develop new features.  However, sad to say, not many
people share that philosophy.)
    Just consider that the guy who installed our UXS1200 needed two days to
    do this. 
Well, I'm not sure that this is a good example; most of the problem UX installations
I've heard of had troubles on the Unix end, not on the Symbolics end.  You can't
expect Symbolics to be as expert about Unix and Suns as they are about their
own technology.  Moreover, I've had experiences where even Sun technicians
spent two days installing a Sun machine because something obscure was going
wrong.  Because of the nature of the system, it is much harder to isolate
and debug a problem on Unix than on the Lispm...
	     I also remeber a "course" on Joshua, several years ago, which
    was oversimplistic even for a secretary.
I'm not trying to say that Symbolics does everything right; in fact, I agree that
there are still many deficiencies in the Symbolics environment, as well as with
the company (which is still barely holding on financially).  If there were
more resources available there a lot of things we would change.
      I don't know how to communicate this to Symbolic's "official" people,
    but IMHO, this is an important reality that they do not consider.
If you really want to, you CAN send mail to Wurts@Riverside.scrc.symbolics.com. ;-> 

    Emmanuel Baechler.
    Laboratoire d'Intelligence Artificielle
    Ecole Polytechnique Federale de Lausanne
    MA-Ecublens
    CH-1015 Lausanne	Switzerland
    Tel.: ++41-21-693-2732
    e-mail: baechler@liasun6.epfl.ch
    Standard Disclaimer