So far, my pulling numbers out of air estimate is that the commercial Lisp
market is at least $10M/yr. (~4K unit sales/yr.), but not as large as
~$100M/yr.(~40K unit sales/yr.) and probably in the $15M-25M (6-10K unit
sales/yr.) range [All figures in USD and unit sales adjusted WRT average
unit price of $2500/unit including support and maintenance contracts and
auxillary software and services by the vendors]. If anyone with actual
data wishes to dispute (or confirm) these figures, I would be happy to hear
from them and I am still willing to hold individual vendor figures in
Larger unit "sales" come from open source Lisp systems, although they tend
to be for personal, small-scale use rather than for commercial deployments
[Before I get flamed by open source boosters - Yes, I know there are
internal corporate deployments out there. Their numbers are few.]
And of course, I don't want to discount the fact that this small market
leverages a much larger one that uses these tools to make many more
dollars. Some folks have even said that Lisp is too important to some
organizations to be allowed to die.
My take on Lisp is that it is a very good tool for doing things that nobody
knows how to do yet and for doing things quickly and that this is still a
very viable market niche for small entrepeneurs. Once you get to a point
where you do know how to do these things or are established in the
marketplace, most managements (or your competitors) are ready to transition
the newly found knowledge into a slower velocity but more efficient (and,
seemingly, less risky) environment.
There are some areas where this "not knowing how to do things" does not end
or our knowledge is still so limited that we won't for some time "know how
to do things" or that time to market is very critical (financial modeling
and bioinformatics come to mind immediately). So a lot of organizations
(like Yahoo!, who've been working on transitioning their store away from
Lisp) are quite content to see Lisp die. This doesn't mean that there
won't be new niches, but, like the language itself, Lisp's areas of
application will always be quite dynamic and its world will always be in
the juncture between creation and destruction.
You have an interesting problem, but I think it is necessary to point out
that the number of people who use Common Lisp is much smaller than the number
of people who _would_ use Common Lisp if given half a chance. Just like you,
they are the _unrealized_ market of Common Lisp. Very often, the realized
market is taken as a measure of the unrealized market, but this is what
marketing is all about. When you ask about the realized market, you will
unfortunately be somewhat disappointed, but think of how many people are in
your own position, struggling to find some reason to convince somebody to
(let them) use Common Lisp. In other words, what might happen if you start
to use Common Lisp is that your local Common Lisp market grows very quickly.
(This happened in Oslo.) You will most probably find good programmers and
more people who are willing to employ them, too, if you can just convince the
first one that the water is really not that cold, despite what it feels like
to the toe-dippers. Being the first one (locally) out is always difficult.
Your manager would probably not care about any "market size" if people he
knew (about) were already using it.
| My take on Lisp is that it is a very good tool for doing things that nobody
| knows how to do yet and for doing things quickly and that this is still a
| very viable market niche for small entrepeneurs. Once you get to a point
| where you do know how to do these things or are established in the
| marketplace, most managements (or your competitors) are ready to transition
| the newly found knowledge into a slower velocity but more efficient (and,
| seemingly, less risky) environment.
I concur. This will keep Common Lisp alive for the foreseeable future, but
the realization that Common Lisp can help solve a problem has to be founded
on experience from _not_ solving similar problems in other languages. This
is sometimes a very expensive experience to acquire. Some people will not
give you a second chance once you have realized that you could not solve the
problem you set out to solve, even though you probably know how to solve it
after you failed to solve it in time.
| This doesn't mean that there won't be new niches, but, like the language
| itself, Lisp's areas of application will always be quite dynamic and its
| world will always be in the juncture between creation and destruction.
Guide to non-spammers: If you want to send me a business proposal, please be
specific and do not put "business proposal" in the Subject header. If it is
urgent, do not use the word "urgent". If you need an immediate answer, give
me a reason, do not shout "for your immediate attention". Thank you.
Such as: write software that works. ;)
How did you arrive at these figures? Are they completely wild
guesses, or did you extrapolate somehow? I don't mean to sound
argumentative, and I don't have any figures to offer, but I'd like to
use these numbers and would like to know how they were derived.
Also, is this counting AutoCAD and other products that use Lisp as an
So a lot of organizations
> (like Yahoo!, who've been working on transitioning their store away from
> Lisp) are quite content to see Lisp die.
Isn't this example cut from the whole cloth?
Paul Graham answered questions about the continued use of Lisp in the
Y! Store at this past last LUGM. He mentioned that while an attempt
had been made to rewrite parts of the store in C++, that project had
not yielded even a working RTML interpreter and was shelved.
As I said - pulling numbers out of air. Please! Be argumentative. Maybe
someone will come up with actual numbers. My methodology was to figure out
about how many people would be working in the given Lisp companies, by
looking at the web sites and the services rendered and trying to compare
them with other "similar sized" types of concerns, as well as trying to
come up with believable figures for unit sales (does anyone believe that
there are 40,000 commercial Common Lisp systems sold in the world each
year? 6-10K seems a lot more reasonable). I bounded the bottom by what
would be enough to keep the current three vendors in business. So, it's a
guess, but one I'm willing to work with until I hear differently from
No - I'm not counting Autocad or anything else that uses Lisp as a
scripting language. I'm really only interested in commercial vendors'
Common Lisp systems.
I'd say you were in the ballpark.
$10M/yr. divided by about $100,000 per employee (salary and overhead)
gives you about 100 employees supported by vending Common Lisp,
and this seems to be about right, too.
> So far, my pulling numbers out of air estimate is that the
> commercial Lisp market is at least $10M/yr. (~4K unit sales/yr.),
> but not as large as ~$100M/yr.(~40K unit sales/yr.)
As you basically point out later, because of the open source market,
these numbers are probably conservative. For example, there are a lot
of services that are being performed such that numbers wouldn't count
toward a commercial market for Common Lisp.
Some more anecdotal evidence along these lines would be my firm's
forensic data analysis, security assessment, and privacy assurance
practices. We use Common Lisp for each of these, but not exclusively,
and the issue of what language(s) we've used to implement our
proprietary tools almost never arises. We're also using CMUCL and
CLISP, so you won't be able to pick up our activity by asking for
shipments from the commercial Common Lisp implementation vendors and
adding them together.
In the case of the forensic data analysis practice, the use of open
source tools actually works quite significantly to our advantage. If
results are challenged by the other side, we can show how we got those
results. If the tool is challenged, we can show how it's implemented.
If the construction of the tool is challenged, we can go back, etc.
Of course, there's always the bootstrapping problem, and what happens
if someone puts something funny in the compiler that bootstraps it
all but in practice, the court isn't likely to indulge an
attorney's attack all the way to boostrap without some reason other
than the client doesn't like the results.
 See Thompson's "Reflections on Trusting Trust".
Matt Curtin Interhack Corp +1 614 545 HACK http://web.interhack.com/
Author, Developing Trust: Online Privacy and Security (Apress, 2001)
Knight of the Lambda Calculus | Quod scripsi scripsi. --Pontius Pilate
Joe> I'd say you were in the ballpark.
Joe> $10M/yr. divided by about $100,000 per employee (salary and overhead)
Joe> gives you about 100 employees supported by vending Common Lisp,
Joe> and this seems to be about right, too.
Based on my previous employer, the overhead factor was something like
3-4. If this is true for software, does that mean the employees are
making $30K or less? While I haven't kept track of salaries, when I
graduated from college oh so many years ago, $30K was the starting
salary for a newly-minted EE major.
As an order of magnitude, I guess this is right, though.
>My take on Lisp is that it is a very good tool for doing things that nobody
>knows how to do yet
>"Frank A. Adrian" <fad...@ancar.org> wrote in message news:98IT8.email@example.com...
>I'd say you were in the ballpark.
>$10M/yr. divided by about $100,000 per employee (salary and overhead)
>gives you about 100 employees supported by vending Common Lisp,
>and this seems to be about right, too.
Average salary of good programmer is about $80K/year with
cost/benefits/ovehead factor about 2.2 to 2.5. What gives more than
I was doing an order of magnitude estimate.
I don't think a good programmer + overhead costs $1M a year
nor could you get a good programmer + overhead for $10K a year.
How about: write software that works. :)
and my webpage for it is at
The following are most of the very few papers I know of on this topic:
"Aesthetic Modes of Knowing" by Elliot Eisner, in "Learning and Teaching
the Ways of Knowing," edited by Elliot Eisner.
"Arts-based Educational Research," by Tom Barrone and Elliot Eisner in
"Complementary Methods in Educational Research," edited by Richard M.
"Voices Inside Schools: Notes from a Marine Biologist's Daughter: On the Art
and Science of Attention," by Anne McCrary Sullivan, in Harvard Educational
Review, Vol 70 No. 2, Summer 2000.
"Envisioning Science: The Design and Craft of the Science Image," by Felice
This will be a workshop where we explore ideas rather than one where we
present well-worked-out stuff. We are open to all sorts of proposals,
submissions, and ideas. Please forward this to anyone or any mailing list
you think would be interested in it, but please be tasteful and considerate
in doing so.