>Andreas Eder cited *EVIDENCE* that Haskell and Lisp are more
productive (and clearer) than C++ and Ada.
Sin-Yaw Wang wibbled in response (cyber surfer, what _does_ "wibble" mean?)
>If Lisp is more productive, as the studies proved, why, then, did it
>fail in the marketplace?
(a) It is not clear that it _has_ failed in the marketplace.
The last time I looked, there were more Lisps available for the Mac
than Pascals (one of the major Pascals having died) or Cs. How
many Jovial or PL/I compilers can you get for the Mac? (PL/I is
still alive, even growing, by the way.)
(b) For many years, people talked of Smalltalk as a toy that had failed
in the marketplace. The bookshop across the street has more Smalltalk
books than Fortran or COBOL books, if that's any measure. Smalltalk
has now found some of the people who needed to find Smalltalk. (And I
would count Smalltalk and Lisp as close cousins.)
(c) Lisp was tarred with the "AI" brush. Over the last 5 years, enrollment
in our AI graduate diploma has dropped by about a factor of 5. (But
"data mining" is up. Seems that nobody has noticed that data mining is
a species of AI.)
(d) There's a technique known as "The Big Lie". You tell a thumping great
lie over and over to a lot of people, and eventually it beomes "Received
Truth". Some people, like a certain S-Y W, seem to enjoy telling
Big Lies about Lisp. Success in the marketplace has NOTHING to do with
what IS and everything to do with what people BELIEVE. (Of course if
your product is very bad, eventually people will believe it is bad.
But if your product is very good, and people believe it is bad, they
will never discover that they were wrong.)
(e) Productivity depends far more on who the programmer is than on what the
programming language is like. People who are productive in Lisp are
productive because they are capable of thinking in unnatural ways.
Having learned Lisp skills, they can then apply them in other contexts.
Perhaps the languages in the Lisp "phylum" (Lisp, Scheme, Smalltalk,
ML, Haskell, SELF, NESL, ...) have already nearly saturated that
segment of "the marketplace" that is willing to try novel ways of
thinking about programming. I wonder how many programmers in the
Lisp phylum are also interested in Literate Programming, meta-
programming, &c?
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
[1] Re: "Why lisp failed in the marketplace"
In reality, Lisp has been a phenominal success.
It's one of the earliest computer languages that is still around and viable.
It's elders, Fortran and Cobol, have largely hung on due to the inertial of
a large base of existing and installed code. Lisp is still a viable choice
for
a new project with no existing code base. There have been hundreds of
other computer languages invented since that have had less of a presence
than Lisp.
Lisp has been a successful choice for the many people who have used it.
So how is it a "failure" ?
Well -- it's been a failure at making the Lisp Machine vendors or the Lisp
compiler & tools vendors rich.
Except as embedded in products like AutoCad, it's been a failure in being
a large presence in the PC world, which is where the mass market is.
Although it's been successful, considering all of it's advantages,
perhaps it ought
to have been a much larger success.
So it might be valid do say that Lisp failed in the mass market, but it's a
distortion to say it failed in the marketplace.
-- Steve Majewski <·····@Virginia.EDU>
From: William Clodius
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <331B6E19.2F1C@lanl.gov>
·····@Virginia.EDU wrote:
>
> <snip>
> In reality, Lisp has been a phenominal success.
> It's one of the earliest computer languages that is still around and viable.
> It's elders, Fortran and Cobol, have largely hung on due to the inertial of
> a large base of existing and installed code. <snip>
Minor correction. While younger than Fortran, Lisp is older than Cobol.
Lisp 1.5 appeared in 1959. Cobol's definition appeared in April 1960.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
From: Randy Crawford
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <332676CE.7E565B54@mrj.com>
·····@Virginia.EDU wrote:
>
> [1] Re: "Why lisp failed in the marketplace"
I've come late to this old saw, but what the heck...
>
> In reality, Lisp has been a phenominal success.
Your definition of "phenomenal" must differ from mine.
> It's one of the earliest computer languages that is still around
> and viable. It's elders, Fortran and Cobol, have largely hung on
> due to the inertial of a large base of existing and installed code.
This is at least as true of Lisp as it is FORTRAN. In fact, I think
it's probably accurate to say there's a GREAT deal more new development
taking place in FORTRAN and COBOL than in Lisp. The active evolution
of both languages indicates their popularity. Alas, by the same
measure,
Lisp is not faring well outside of academia (even inside, the academic
research market has moved onto better typed functional languages).
> Lisp is still a viable choice for a new project with no existing code
> base. There have been hundreds of other computer languages invented
> since that have had less of a presence than Lisp.
Certainly those languages were failures in the marketplace. Simply
because Lisp has done better does not say much for Lisp.
And *I* certainly wouldn't want to be the one to defend Lisp as the
language of choice for just about any new system. The advantages
that Lisp brought to software development have been superceded by
better prototyping tools or libraries of objects.
>
> Lisp has been a successful choice for the many people who have used it.
This is true to some degree. But I have no doubt that numerous Lisp
apps
should never have been written in Lisp. I can name several of personal
acquaintance that were indubitable failures or at best, qualified
successes. Those relatively few cases of clear excellence do not
indicate
that Lisp has fared well uniformly in the larger marketplace. Lisp has
always been a niche player. As AI went, so followed Lisp. To wit,
right
off the radar. That may not be Lisp's fault -- at least not *mostly*
its fault -- but the problems endemic to Lisp apps did no favor for the
success of AI apps outside of academic/R&D/ or military prototypes.
Lisp
had successes there, but again, these fell outside the "marketplace".
>
> So how is it a "failure" ?
> Well -- it's been a failure at making the Lisp Machine vendors or the Lisp
> compiler & tools vendors rich.
And those who believed to the contrary, like Lucid and Symbolics, are
dead, dead, dead.
> Except as embedded in products like AutoCad, it's been a failure in being
> a large presence in the PC world, which is where the mass market is.
This invites the question of whether Autocad scripts are really Lisp, or
whether scheme, T, flavors, etc are really Lisp. If they ALL are, then
it might be claimed that Lisp *had* a little success in the narrow
market
related to AI apps, but certainly less so than the Lotus 1-2-3 scripting
language, and certainly less than the venerable GW Basic.
> Although it's been successful, considering all of it's advantages,
> perhaps it ought to have been a much larger success.
I think the reasons why Lisp never did well were obvious -- *large*
syntax, slow in most incarnations, large memory usage, poor interface
to GUIs and external resources (like databases), and most of all, the
inability if the Lisp afficianados to realize that any language asked
to perform outside of its strengths (rapid prototyping and rich data
types) will not succeed when pitted against other tools better suited
to that 99% of programming that focuses on the mundane -- input and
output. Lisp was simply overkill for most of the tasks at hand.
>
> So it might be valid do say that Lisp failed in the mass market,
> but it's a distortion to say it failed in the marketplace.
I can't agree. If Lisp is to be considered a success, it was in
academia and the early explorative years of AI. By any standard,
Lisp's successes did not extend to the general marketplace.
If every Lisp-based business has eventually crashed and burned (or
else left Lisp behind), then a commercial "success" like that of
Lisp is one I would not wish on any friend.
>
> -- Steve Majewski <·····@Virginia.EDU>
--
Randy
········@mrj.com
On the menu of a Polish hotel: "Salad a firm's own make; limpid red
beet soup with cheesy dumplings in the form of a finger; roasted
duck
let loose; beef rashers beaten up in country people's fashion."
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3067164676389733@naggum.no>
* Randy Crawford
| I've come late to this old saw, but what the heck...
it seems you are several years out of date, too.
| And those who believed to the contrary, like Lucid and Symbolics, are
| dead, dead, dead.
where do you consider Franz, Harlequin, and Digitool to be today?
| If every Lisp-based business has eventually crashed and burned (or else
| left Lisp behind), then a commercial "success" like that of Lisp is one I
| would not wish on any friend.
perhaps you might want to consider a few facts, too, preferably first-hand,
recent ones? thank you for sharing your prejudices, though.
#\Erik
--
how to beat Microsoft, death, and poverty: in July 1994, there were more
references to my name (3039) in gopherspace than to Microsoft (2557), death
(2530), and poverty (2410). (http://veronica.sonoma.edu:8001/top1000.html)
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> | And those who believed to the contrary, like Lucid and Symbolics, are
> | dead, dead, dead.
>
> where do you consider Franz, Harlequin, and Digitool to be today?
Lucid had no problems with their Lisp, they died because of their
C++ development system. Lucid CL nowadays is called Liquid CL and
you can get it from Harlequin.
Symbolics is still around. You can get their Virtual Lisp Machine
for DEC Alpha systems.
>
> | If every Lisp-based business has eventually crashed and burned (or else
> | left Lisp behind), then a commercial "success" like that of Lisp is one I
> | would not wish on any friend.
>
> perhaps you might want to consider a few facts, too, preferably first-hand,
> recent ones? thank you for sharing your prejudices, though.
He might ask companies like Gensym, Interleaf, Concentra, PTC, Nichimen
BBTECH, BBN, AT&T, Motorola, ... about the failure of Lisp. He might
get a few good laughs.
--
http://www.lavielle.com/~joswig/
Erik Naggum <····@naggum.no> writes:
>where do you consider Franz, Harlequin, and Digitool to be today?
>| If every Lisp-based business has eventually crashed and burned (or else
>| left Lisp behind), then a commercial "success" like that of Lisp is one I
>| would not wish on any friend.
While Harlequin is successful, and makes a Lisp, it is a stretch to
say that they are financially successful because they make a Lisp.
I believe their software for printers is what brings in the money.
Note that their Electronic Publishing products get top billing on
their product page:
http://www.harlequin.com/full/products/Welcome.html
--Pat
Randy Crawford <········@mrj.com> writes:
>·····@Virginia.EDU wrote:
>>
>> [1] Re: "Why lisp failed in the marketplace"
>I've come late to this old saw, but what the heck...
>>
>> In reality, Lisp has been a phenominal success.
>Your definition of "phenomenal" must differ from mine.
>> It's one of the earliest computer languages that is still around
>> and viable. It's elders, Fortran and Cobol, have largely hung on
>> due to the inertial of a large base of existing and installed code.
>This is at least as true of Lisp as it is FORTRAN. In fact, I think
>it's probably accurate to say there's a GREAT deal more new development
>taking place in FORTRAN and COBOL than in Lisp. The active evolution
>of both languages indicates their popularity. Alas, by the same
>measure,
>Lisp is not faring well outside of academia (even inside, the academic
>research market has moved onto better typed functional languages).
Mostly of those researches wouldn't call *differently* typed langugae
*better*. Static or string typing is a trade-off and a matter of
taste.
[...]
>> So how is it a "failure" ?
>> Well -- it's been a failure at making the Lisp Machine vendors or the Lisp
>> compiler & tools vendors rich.
>And those who believed to the contrary, like Lucid and Symbolics, are
>dead, dead, dead.
Lucid is dead because their C++ projects failed and wasted so much
money that the Lisp business (which was profitable) couldn't save
them.
>> Except as embedded in products like AutoCad, it's been a failure in being
>> a large presence in the PC world, which is where the mass market is.
>This invites the question of whether Autocad scripts are really Lisp, or
>whether scheme, T, flavors, etc are really Lisp. If they ALL are, then
>it might be claimed that Lisp *had* a little success in the narrow
>market
>related to AI apps, but certainly less so than the Lotus 1-2-3 scripting
>language, and certainly less than the venerable GW Basic.
>> Although it's been successful, considering all of it's advantages,
>> perhaps it ought to have been a much larger success.
>I think the reasons why Lisp never did well were obvious -- *large*
>syntax, slow in most incarnations, large memory usage, poor interface
>to GUIs and external resources (like databases), and most of all, the
>inability if the Lisp afficianados to realize that any language asked
>to perform outside of its strengths (rapid prototyping and rich data
>types) will not succeed when pitted against other tools better suited
>to that 99% of programming that focuses on the mundane -- input and
>output. Lisp was simply overkill for most of the tasks at hand.
I think you miss the point about Lisp. I can have as much data types
in C++ as I like. And I don't understand this rapid-prototyping
business anyway (if defined different from "efficient" programming).
For me, Lisp is about code desity, the ability to concentrate program
code in a way that the needed information is so well-structured that I
don't have to take ballast around when working on that code. Lisp
syntax and macros, reflectivity, the compiler at runtime and other
things like this help a lot and Common Lisp is quite unique in that
area.
And for most readers of the group Lisp's one of Lisp's greates
strengths is its flexibilty, its ability to be used for *very*
different tasks. Operations on simple data types and arrays of those
can be implemented overhead-free in Common Lisp. The language alllows
that by its definitions (while Java, for example doesn't) and
compilers like CMUCL are pretty good is using this potential.
And Lisp's flexibilty and code abtraction ability clearly show off in
CLIM. While it may be true that Lisp has not many bindings to
other-language GUI toolskits, it has show that it is a decent GUI
language by itself. Look at CLIM and Garnet. Likewise is its abilty to
use relational and OO database. Look at the toolkits Harlequin and
Franz provide and at statice. Lisp can be used to work with external
database data in a very transparent way, it can mimic operations on
external data so that it looks not different from working with
language-native constructs like classes and structs. And it does
without precompilers, syntax extensions and such.
>> So it might be valid do say that Lisp failed in the mass market,
>> but it's a distortion to say it failed in the marketplace.
>I can't agree. If Lisp is to be considered a success, it was in
>academia and the early explorative years of AI. By any standard,
>Lisp's successes did not extend to the general marketplace.
>If every Lisp-based business has eventually crashed and burned (or
>else left Lisp behind), then a commercial "success" like that of
>Lisp is one I would not wish on any friend.
Computer businesses mostly don't fail because of the technical
abilities. If your goal is to use software where technical excellence
domainates usage and survival, use free (not cost-nothing) software.
As long as Common Lisp doesn't loose its adaptabilty (Dylan looses
some flexibilty, code desity and syntaxtical variance, Scheme looses
the ability to go down to memory locations and data layout) and free
implementations like CMUCL are available, Lisp is hard to kill.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
Beating this dead horse yet again, I see... don't we have better things
to do with our time??
In article <·················@mrj.com>,
Randy Crawford <········@mrj.com> wrote:
>·····@Virginia.EDU wrote:
>> So how is it a "failure" ?
>> Well -- it's been a failure at making the Lisp Machine vendors or the Lisp
>> compiler & tools vendors rich.
>
>And those who believed to the contrary, like Lucid and Symbolics, are
>dead, dead, dead.
Bullshit. Lucid's failure IMHO was due to their venture capitalists
betting the company on producing a C++ development environment, against
the better judgment of their technical staff. Their Lisp business was
the cash cow that allowed them to do the C++ work at all.
Symbolics's failure (again IMHO) was due to stupid business decisions
that would have driven any company into bankruptcy (e.g. idiotic real
estate deals for their factory and headquarters), a failure to market
their products effectively (often touting next-generation products
before they were able to manufacture them, resulting in deferred sales),
and an arrogance that the R&D staff knew better than their customers
what the customers needed. It didn't help that Texas Instruments was
practically giving away machines in a cut-throat battle for market share
reminiscent of the one that drove US companies out of the calculator
business in the '70s.
Note that Symbolics is still in business, supplying a software-only
version of their Genera development environment and servicing their old
computers, though they are no longer in the manufacturing business.
As a former Symbolics employee, this constant misrepresentation of the
company's problems really galls me. Their failure can be laid to bad
business decisions and really shitty marketing; the technology or its
acceptance by the marketplace was not the issue. I firmly believe that
if Symbolics had had a clue about marketing and real estate, they would
be where Sun is today.
Now can we quit re-fighting the battles of the past?? What's done is
done, and it's well past time for the Lisp community to move on.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled)
This space for rent... NOT.
The "problem" with Lisp syntax isn't the prefix notation or the parenthesis,
it's the fact that the syntax is so thin. Lisp has the same problem that
Forth
displays to an even larger degree -- Forth has essentially NO syntax. It has
lexing into space separated tokens. Each work or token has it's own
semantics.
You can't read and understand Forth code unless you understand esentially
every word. The solution to this in forth is to heavily comment the source
code with notes about how each word changes the state of the virtual
machine.
It's all semantics, and any token can temporarily change the few global
syntax
rules.
Lisp at least has parenthesis and some grammar, but there is very little
global
syntax that can't be suspended by a macro or reader-macro. There is nothing
in the syntax to indicate which words are control-structures or macros and
which are functions. Position does help differentiate between
functions/macros
and data/parameters, but as with Forth, you can write powerful reader macros
that essentially suspend all of the normal rules.
In practice, programmers rarely use all of these features to write the most
obfuscated
code possible. But, as in Forth, you are still dependent on the discipline
of the (other)
programmer, who has to choose names wisely to produce readable code.
Compared to this, code formatting, parenthesis, pretty-printing, etc. is all
a trivial problem.
However, I use the word "problem" above in quotes.
This feature is a disadvantage for producing readable and reusable code, but
it is
an advantage in other contexts. It's the source of much of the flexibility
of Lisp -
the ability to easily produce a sub-language very close to the problem
domain.
Also, the syntax is so simple, there is not much room for wrong choices --
languages
with a more complex syntax often have problems with interaction of language
syntax
features. Firmer global syntax rules help readability, but reduce
flexibility. Lisp and
Forth are both great languages to WRITE code in, but difficult to read in
the large.
Lisp / Forth / Natural Language all get power from:
[1] relatively small syntax/grammar.
[2] relatively large vocabulary.
[3] combinatory rules to
[1] define new vocabulary.
[2] suspend or change the grammar within a defined context.
P.S. I like and use Lisp. It's not perfect. But if we're going to have a
critique, lets
not waste time on false issues like whether parenthesis or prefix notation
is "natural".
-- Steve Majewski <·····@Virginia.EDU>
programming language critiques page is at
http://galen.med.virginia.edu/~sdm7g/LangCrit/
but it hasn't been updated for some time. There are loads of new Java
critiques that I
ought to get posted there. I'm too busy Lisp programming right now!
In article <······················@bootp-17-17.bootp.virginia.edu>, ""
<·····@Virginia.EDU> wrote:
> Lisp at least has parenthesis and some grammar, but there is very little
> global
> syntax that can't be suspended by a macro or reader-macro. There is nothing
> in the syntax to indicate which words are control-structures or macros and
> which are functions. Position does help differentiate between
> functions/macros
> and data/parameters, but as with Forth, you can write powerful reader macros
> that essentially suspend all of the normal rules.
Depends on what you are doing with Lisp. In normal
Common Lisp there are some conventions for naming things.
WITH- starts the name of a macro that introduces a binding.
DEF starts the name of a macro that introduces a definition
F ends a name of a macro that can take part in the place abstraction.
* starts and end a global
% starts the name of an internal or implementation dependent function
etc.
> In practice, programmers rarely use all of these features to write the most
> obfuscated
> code possible. But, as in Forth, you are still dependent on the discipline
> of the (other)
> programmer, who has to choose names wisely to produce readable code.
In Common Lisp it is good practice to use fully descriptive names.
If you have to type them in a good IDE, then you might want to
change your editor. There are a lot of tools available to reduce
typing, yet have long names. Macintosh Common Lisp has a mouse
copy tool (like Genera) in "ccl:examples;mouse-copy.lisp".
> Forth are both great languages to WRITE code in, but difficult to read in
> the large.
Some people have made quite the opposite experience with Lisp.
Once you get familiar with the basics, it is very easy
to read Lisp code. What makes it sometimes more difficult
are complex control abstractions which makes it
not obvious what the code does. Well, if you use these things
no syntax will help the uninitiated.
> P.S. I like and use Lisp. It's not perfect. But if we're going to have a
> critique, lets
> not waste time on false issues like whether parenthesis or prefix notation
> is "natural".
Personally I think the prefix/infix/postfix discussion is quite useless.
If you spend some hours experimenting with prefix notation, it
should be usable.
More important are tools which help you navigate in your source code
while not using to much valuable screen space. How can
you make a software package understandable to a programmer? You need
tools which automatically generate documentation, records call
trees, shows you the interfaces and how to use them, ...
--
http://www.lavielle.com/~joswig/
From: Luca Pisati
Subject: Re: Thin syntax, not parenthesis or prefix
Date:
Message-ID: <3321B083.74E3@ix.netcom.com>
Rainer Joswig wrote:
>
> In article <······················@bootp-17-17.bootp.virginia.edu>, ""
> <·····@Virginia.EDU> wrote:
> WITH- starts the name of a macro that introduces a binding.
> DEF starts the name of a macro that introduces a definition
> F ends a name of a macro that can take part in the place abstraction.
Never heard about this ... could you make some example ?
> * starts and end a global
> % starts the name of an internal or implementation dependent function
>
> etc.
> --
> http://www.lavielle.com/~joswig/