Hey guys,
I'm studying a wide variety of computer languages for purely academic
reasons. I've currently been toying with several functional languages such
as LISP and SCHEME. I was wondering if someone could answer a REALLY dumb
question for me. :-). What kinds of programs are these languages, LISP and
SCHEME particularly, commonly used for? I'm talking in a real-world sense
here. What companies can I go to and what products can I buy that are based
on these languages? What are their best applications?
To clarify what I mean. I associate C with systems programming first and
foremost, but it 's also a general programming language. I associate PROLOG
with AI. I associate PERL with text processing. What about LISP/SCHEME?
Thanks for any help you can give me,
Justin Dubs
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
"Justin Dubs" <······@eos.ncsu.edu> writes:
> I'm studying a wide variety of computer languages for purely academic
> reasons.
Hmm. Academic reasons come in two kinds that come immediately to mind:
The first is the idiom "having no purpose", as in "It's all academic;
I didn't have an application for it anyway." The second, and more
literal sense, would be "carefully researched, referenced,
well-founded in fact, and appropriately documented for the purpose of
proving or disproving a particular thesis". If this latter is the
kind of thing you're out to do, then I suggest that the phrase "purely
academic reasons" is incomplete.
> I've currently been toying with several functional languages such
> as LISP and SCHEME.
Although Scheme can be characterized as a functional language, I think
it is a mistake to characterize Lisp as one. Lisp is, by explicit
design choice, a multi-paradigm language, supporting functional,
imperative, symbolic, object-oriented, and other approaches flexibly
according to the needs of the programmer. Scheme is, also by explicit
design choice, I believe, more of a single paradigm language. As
such, any attempt to use these two in the same breath as if they were
out for the same thing is misguided.
See also my article on viewing languages as political parties:
http://world.std.com/~pitman/PS/Lambda.html
> I was wondering if someone could answer a REALLY dumb
> question for me. :-).
I think you're going to find this was really dumb not for the reasons you
suspect but for the firestorm you bring on yourself for this. If you want
a good general rule: do not go into something you know nothing about by
flaunting your ability to mischaracterize and oversimplify related topics.
> What kinds of programs are these languages, LISP and
> SCHEME particularly, commonly used for? I'm talking in a real-world sense
> here. What companies can I go to and what products can I buy that are based
> on these languages? What are their best applications?
>
> To clarify what I mean. I associate C with systems programming first and
> foremost, but it 's also a general programming language. I associate PROLOG
> with AI. I associate PERL with text processing. What about LISP/SCHEME?
These are gross oversimplifications of all of these languages. Don't be
surprised if you rouse incredible ire in people by asking them to help you
mischaracterize Lisp to a similar extent.
You might as well have said: "What are people who wear glasses for? I
know I associate thin people with modeling, tall people with
basketball, muscular people with ditch digging?" You have not created
a "credential" for yourself by displaying your additional "knowledge"
of these other programming langauges in trying to sum up hundreds of
man years of design and use into a single statement like this, and
have not improved your chances of getting a civil answer to your
question because few people with the knowledge you seek will aspire to
be similarly mischaracterized by supporting your endeavor. It might
BE that tall people are more correlated with basketball, but it's as
wrong to assert that this is a meaningful and useful "defining
characteristic" of them as it is to assert the contrary.
I recommend a lot of serious introspection about the differences
between myth, prejudice, correlation, and causality before you proceed
on your quest.
> Thanks for any help you can give me,
I hope you take this message in the constructive spirit in which it is
intended.
- - - - -
Lisp is useful for a great many kinds of problems. It has been used
for system programming (whole operating systems are written in it), is
used heavily in AI, is quite good for text processing (it is one of
the most common languages for implementing text editors).
Furthermore, C is also used in systems programming, AI, and text processing.
If you found that statistically the uses were otherwise, you'd want to
separate out myth / prejudice / fear that keep people from using certain
langauges for certain purposes before claiming anything about the stats.
For example, statistics might show that women are more often
secretaries than men. That would not be any proof that they are
"better" at this. It might be that men would be better at it if men
were more often hired into this role, and women into executive roles.
But more likely it's a wash and a misguided issue to be measuring in
the first place except for gathering statistics about injustice.
Then again, if your "academic" reason is to collect statistics about
injustices done to various languages through well-meaning but
misguided oversimplified mischaracterizations of the sphere of
usefulness of those languages, you are likely to find a lot of data
here.
Just my opinion. I've tried to keep it civil and constructive. Please
do the same in any replies.
Kent M Pitman <······@world.std.com> wrote:
[...]
> Lisp is, by explicit
> design choice, a multi-paradigm language, supporting functional,
> imperative, symbolic, object-oriented, and other approaches flexibly
> according to the needs of the programmer.
Well, that seems to be the reason, why I'm reading this
newsgroup (at least sometimes).
I'm now often reading comp.lang.functional, because I want
to learn functional programming. When I learned it, the
time is come to complete my C/Perl-learnings and the
functional stuff and merge it on higher level into Lisp-
knowledge.
Books are ordered, but some are out of print, others will
need weeks or month to get them (4..5 weeks waiting time
is normal, additional "wait until new edition" must be added).
In this time I will learn Ocaml and Haskell.
If they are really to narrow focused, last way of freedom
seems to be Lisp then.
I hope I can read your above quoted paragraph literally.
Regards,
Oliver Bandel
--
Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best.
(Frank Zappa)
I really don't use Lisp for any "special" or "exotic" purpose. I use it
as a general programming language to do things like analyze data,
interact with and maintain databases, make user interfaces, and any
number of other run-of-the-mill things.
--
Howard Ding
······@worldnet.att.net
http://math.sunysb.edu/~hading http://thunder.prohosting.com/~hading
Thank you very much. This is exactly what I was looking for. I appreciate
the response,
Justin Dubs
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * Justin Dubs
> > I've currently been toying with several functional languages such
> > as LISP ...
>
> It won't be very productive research or study if you limit your view of
> Lisp to be a functional language. Common Lisp is the singularly most
> general-purpose programming language I know, and like most other Lisp
> programmers, I know too many programming languages.
>
> > What kinds of programs are these languages, LISP and SCHEME
particularly,
> > commonly used for?
>
> Lisp and Scheme are used for very different purposes. It is not at all
> useful to group them together. Grouping languages based on syntactic
> superficialities like parentheses or semicolons does not yield groups
> than have any predictive power.
>
> For Common Lisp, the only good answer is "difficult problems", possibly
> modified "without established solutions".
>
> > I'm talking in a real-world sense here. What companies can I go to and
> > what products can I buy that are based on these languages? What are
> > their best applications?
>
> I have come to believe that the reason we don't find many products based
> on Common Lisp is that you don't use Common Lisp for consumer products.
> It is almost strictly a professional's choice, when other tools have
> proven to be inadequate for the remaining problems. For the already-
> solved problems, you can use just about any language, and commodity
> disasters like C++ will do, because it costs less to hire enough people
> off the street to code the known solution in C++ than it costs to deploy
> in Common Lisp, especially including maintenance and training. But you
> would never want to do your research in C++ if you have the brains to
use
> Common Lisp. The closer you get to deployment, however, the more solid
> your code gets, the better documented the algorithms, etc, and then any
> language will do. If you use Common Lisp at this time, it's a luxury,
> instead of a necessity.
>
> > To clarify what I mean. I associate C with systems programming first
and
> > foremost, but it 's also a general programming language. I associate
PROLOG
> > with AI. I associate PERL with text processing. What about
LISP/SCHEME?
>
> Common Lisp is so different from Scheme that you should regard Scheme as
> an Algol. If you stick with the semicolons, you end up with Ada 95, but
> if you stick with the parens you end up with Common Lisp. It is, again,
> not productive to group Common Lisp and Scheme, and the Lisp that Scheme
> is a dialect of is irrelevant at this time. Scheme was left behind in
> the evolution of programming ideas, while almost every other language
> learned from each other and developed needful things both together and
> separately. Scheme today is primarily used for teaching, like Pascal
was
> a few years ago, also a notable Algol descendant.
>
> I associate Common Lisp with _real_ programming. Other languages are
> only used to tinker with already solved problems or patching up broken
> solutions.
>
> #:Erik
> --
> Foot-in-mouth disease is spreading. Help stop the epidemic!
> Know what you're talking about before you post, or shut up.
[Since I discuss Lisp, my followup is to comp.lang.lisp only - Paolo]
On Sun, 25 Mar 2001 02:10:53 -0500, "Justin Dubs" <······@eos.ncsu.edu>
wrote:
> question for me. :-). What kinds of programs are these languages, LISP and
> SCHEME particularly, commonly used for? I'm talking in a real-world sense
A good starting point is the industrial applications section of the ALU
site:
ALU - Association of Lisp Users
http://www.alu.org/
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Justin Dubs" <······@eos.ncsu.edu> writes:
> question for me. :-). What kinds of programs are these languages, LISP and
> SCHEME particularly, commonly used for? I'm talking in a real-world sense
> here. What companies can I go to and what products can I buy that are based
> on these languages? What are their best applications?
OK, let's go for the best known products:
Emacs, XEmacs, AutoCAD, Interleaf, Yahoo! Shop editor, CL-HTTP,
Watson...
Check
http://www.xanalys.com/software_tools/products/myths_and_legends.html
for these and other examples.
What about Scheme though?
--
Oleg Goldshmidt | ···········@NOSPAM.computer.org
"I'd rather write programs to write programs than write programs."
Oleg Goldshmidt <···········@NOSPAM.computer.org> writes:
> "Justin Dubs" <······@eos.ncsu.edu> writes:
>
> > question for me. :-). What kinds of programs are these languages, LISP and
> > SCHEME particularly, commonly used for? I'm talking in a real-world sense
> > here. What companies can I go to and what products can I buy that are based
> > on these languages? What are their best applications?
>
> OK, let's go for the best known products:
>
> Emacs, XEmacs, AutoCAD, Interleaf, Yahoo! Shop editor, CL-HTTP,
> Watson...
>
> Check
>
> http://www.xanalys.com/software_tools/products/myths_and_legends.html
>
> for these and other examples.
>
> What about Scheme though?
- DSSSL: http://www.prescod.net/dsssl/
- The GIMP Script-Fu: http://www.xcf.berkeley.edu/~gimp/script-fu/script-fu.html
- AL (the Animation Language): http://web.cgrg.ohio-state.edu/~smay/AL/
- scsh: http://www.swiss.ai.mit.edu/ftpdir/scsh/
- scwm for X: http://scwm.sourceforge.net
- BRL: http://brl.sourceforge.net
These are just the examples that come to my mind instantly.
BTW, Emacs and XEmacs use Emacs Lisp, AutoCAD uses AutoLisp, Interleaf
uses InterleafLisp and the other three applications you mentioned use
CL [substitute more appropriate verbs for "use", if you like]. So you
could just incorporate my examples into your list, because they also
use a dialect of Lisp, because that's what Scheme is, eventually. Why
the discrimination?
Oh, another striking example I recall: one of the largest headline
displays on Time Square in New York City is powered by Emacs Lisp. The
guy who implemented it told me.
Regards,
-BSm.
In article <··············@rome.bhasha.com>, Boris Smilga
<·····@bhasha.com> wrote:
> Oh, another striking example I recall: one of the largest headline
> displays on Time Square in New York City is powered by Emacs Lisp. The
> guy who implemented it told me.
Don't forget Harlequin's RAX (Remote Agent Experiment) software for
NASA's "Deep Space 1" spacecraft.
http://rax.arc.nasa.gov/
http://www.hq.nasa.gov/office/codei/swy99win.html
Perhaps that isn't a product?
On the other hand, I've been programming professionally (and
productively) for seventeen years, at a number of organizations, and
I've never yet produced anything you can buy in shrinkwrap on a shelf.
-- Bruce
[Followup posted to comp.lang.lisp only - Paolo]
On Sun, 25 Mar 2001 02:10:53 -0500, "Justin Dubs" <······@eos.ncsu.edu>
wrote:
> To clarify what I mean. I associate C with systems programming first and
> foremost, but it 's also a general programming language. I associate PROLOG
> with AI. I associate PERL with text processing. What about LISP/SCHEME?
Here are some possibly relevant remakrs by Paul Graham (from his book "On
Lisp", Prentice Hall, 1994, page 398):
"The lack of a distinct name for the concepts underlying Lisp may be a
serious barrier to the language's acceptance. Somehow one can say ``We
need to use C++ because we want to do object-oriented programming,'' but
it doesn't sound nearly as convincing to say ``We need to use Lisp
because we want to do Lisp programming''.
[...]
Efforts to sum up Lisp in a single phrase are probably doomed to failure,
because the power of Lisp arises from the combination of at least five or
six features. Perhaps we should resign ourselves to the fact that the
only accurate name for what Lisp offers is _Lisp_."
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Justin Dubs" <······@eos.ncsu.edu> writes:
> To clarify what I mean. I associate C with systems programming first and
> foremost, but it 's also a general programming language. I associate PROLOG
> with AI. I associate PERL with text processing. What about LISP/SCHEME?
I'm sure you'll get different answers from different people. I
associate Scheme with the use of procedures as data (a.k.a. higher-order
functions). I programmed in C for 12 years and rarely used procedures
as data. The functionality is there, but not nearly as convenient as
with Scheme.
If I were to go back to C now, I imagine I'd use procedures as data a
lot more, now that Scheme has let me explore the benefits.
Erik Naggum wrote:
>
> For Common Lisp, the only good answer is "difficult problems", possibly
> modified "without established solutions".
If the problems are "programming problems". But as we know, most
problems in software development are not really about "programming".
> > I'm talking in a real-world sense here. What companies can I go to and
> > what products can I buy that are based on these languages? What are
> > their best applications?
>
> I have come to believe that the reason we don't find many products based
> on Common Lisp is that you don't use Common Lisp for consumer products.
> It is almost strictly a professional's choice, when other tools have
> proven to be inadequate for the remaining problems. For the already-
> solved problems, you can use just about any language, and commodity
> disasters like C++ will do, because it costs less to hire enough people
> off the street to code the known solution in C++ than it costs to deploy
> in Common Lisp, especially including maintenance and training. But you
> would never want to do your research in C++ if you have the brains to use
> Common Lisp. The closer you get to deployment, however, the more solid
> your code gets, the better documented the algorithms, etc, and then any
> language will do. If you use Common Lisp at this time, it's a luxury,
> instead of a necessity.
Ahh, I used to say that too, at a time when I was oriented towards the
technical aspects of the "difficult problems". Solve them, and then
reimplement in low-level languages as needed. But it did not get to
happen that way then, and I am not convinced it happens now. There are
perhaps domain islands where a software company or -group (or
individuals - you at least :-) actually do this.
The irony here is that Common Lisp _should_ probably be used, since a
product's life cycle becomes shorter, as does the time available for
development.
>
> I associate Common Lisp with _real_ programming. Other languages are
> only used to tinker with already solved problems or patching up broken
> solutions.
Well, other languages are used to construct software modules that can be
used by a larger programmer community, since the real problems are
mostly related to non-programming issues. As you say, it is easier to
find ordinary C-programmers than Lisp-heroes, also a company must make
money before it can pay employees. The kind of professionals mostly
needed is the 9-5 kind that will fill in program templates correctly,
and in time. I am _not_sarcastic. Without that, you don't have a
positive cash flow, and without _that_ you have Real Problems. It's the
business case again.
I associate Common Lisp with attitudes, more than with programming
techniques or algorithms. These attitudes are very visible is this n.g.
A Common Lisper is a Philosopher and an Artist. He does not mind that
there are essentially only two Common Lisp vendors in this world. (There
is of course Corman Lisp, which does not seem to count since it is based
on MS-Windows, and a few others which must be extended to fit the actual
needs, but so what?).
I also associate Common Lisp with an almost complete lack of useful
every-day applications. There is not even a decent editor written in
Common Lisp, apart from the two commercial vendor's .? What about
source code management? Document management? Intelligent ( hmm )
user-system interaction? Logistics? Salary systems are notoriously
difficult, etcetera.
/Lars
>>>>> Lars Lundback writes:
Lars> I associate Common Lisp with attitudes, more than with programming
Lars> techniques or algorithms. These attitudes are very visible is this n.g.
Lars> A Common Lisper is a Philosopher and an Artist.
Ouch.
I suspect this was meant with (slightly) derogatory intent. However,
I think the statement itself is actually true. However, I'm not sure
it's a bad thing. You add:
Lars> The kind of professionals mostly needed is the 9-5 kind that
Lars> will fill in program templates correctly, and in time.
Are you sure? It's been observed that productivity, in the software
field, can vary by two orders of magnitude. Are you sure the kind of
professionals needed are those at the bottom of that scale? It seems
to me that those who think of themselves as `Philosophers and Artists'
are precisely those with the introspection skills required to analyze
their process, understand the hidden underlying requirements, and
deliver high quality software.
I've worked in two environments. One was part of a team of 30 C++
programmers. One is part of 6 Lisp programmers. The latter team has
delivered software of a complexity and quality which I *know* the
former team could *never* have achieved. Is business better off
paying 30 guys $50,000, or 6 guys $100,000 and getting a better product?
I'll tell you the simple, bottom line business answer: the latter.
I now get to hire people, and I hire the second category. And I'm not
seduced by the "bums on seats" approach. Done that once, hopeless
outcome.
Of course, if by
Lars> A Common Lisper is a Philosopher and an Artist.
you mean that often times, it won't be possible to "coerce" the lisper
to do something he doesn't want to (or think is "wrong", in some way),
then I have sympathy for you, but perhaps you should listen to him.
Sure, some people, especially those from a highly academic background
are immature and don't like to get their hands dirty, or do "impure"
things. Lisp is strong in academia, so those traits might be higher
in the population of lispers than 9-to-5 programmers, who know darn
well that they're interchangeable. Eventually, though, even the most
brilliant programmer learns that no one is indispensible, and either
learns teamwork and a good working attitude or quickly ends up at a
dead end.
I'm a CL programmer and a pragmatist, and I consider myself
responsible to business, and I have their best interest at heart.
Lars> He [the CL programmer] does not mind that there are essentially
Lars> only two Common Lisp vendors in this world.
Of course [the CL programmer] minds. Of course *I* mind. But so
what? Should we not use it for that reason, thus ensuring that there
will shortly be zero vendors? I mind about a lot of things. I mind
that there is no industrial strength open source CL (so I'm not
hostage to *any* vendor). I mind that the CL standard isn't as
complete as I'd like (e.g. threads). I mind that the toolkits for CL
aren't as nearly as good as they are for Perl/Python/Java/etc. I
_mind_, trust me. So do the business people who take my advice and
decide to let us use Lisp anyway. We're not blind, we know we're
taking risks. Why do we do it?
Business reasons. I'm a CL programmer and a pragmatist. We chose CL
because we could deliver the most bang for the buck. We chose it so
we can stay ahead of the competition, which will try to duplicate our
stuff with Perl/Java/C++/Whatever.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
>>>>>> Lars Lundback writes:
>Lars> He [the CL programmer] does not mind that there are essentially
>Lars> only two Common Lisp vendors in this world.
digitool and who else? :-)
sashank
·············@vanderbilt.edu (Sashank Varma) writes:
> >>>>>> Lars Lundback writes:
>
> >Lars> He [the CL programmer] does not mind that there are essentially
> >Lars> only two Common Lisp vendors in this world.
>
> digitool and who else? :-)
Proprietary: Digitool, Corman, Allegro, Xanalys
Free: CMUCL, CLISP (and several others I have not used myself)
So, it's a bit of a stretch to say "only two Common Lisp Vendors".
Lars was prolly trolling anyways.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
Alain Picard <·······@optushome.nospam.com.au> writes:
> I've worked in two environments. One was part of a team of 30 C++
> programmers. One is part of 6 Lisp programmers. The latter team has
> delivered software of a complexity and quality which I *know* the
> former team could *never* have achieved. Is business better off
> paying 30 guys $50,000, or 6 guys $100,000 and getting a better product?
> I'll tell you the simple, bottom line business answer: the latter.
> I now get to hire people, and I hire the second category. And I'm not
> seduced by the "bums on seats" approach. Done that once, hopeless
> outcome.
The interesting thing is that the two approaches is reflected in two
popular theories among "trend researchers" (or whatever they like to
call themselves). One popular theory is that programmers will become
the new working class (*). The almost opposite theory is that of "gold
collars" and "knowledge nomades" and whatever expressions they use,
and they obviously put at least some of the programmers into that
category.
(*) but, the optimist adds: communism will finally be implemented ;-).
--
(espen)
Alain Picard <·······@optushome.nospam.com.au> writes:
> I mind that there is no industrial strength open source CL (so I'm not
> hostage to *any* vendor).
What are your objections to CMUCL? It's open source, nearly ANSI compatible,
and produces running code that is often much faster than that created by
many commercial Lisps.
I would say that CMUCL is easily "industrial strength" enough to use in
production for mission-critical business needs.
_______________________________________________________________________________
Don Geddis http://shop.goto.com ······@goto.com
VP of Technology, GoTo Shopping Phone 650-403-2220
1820 Gateway Drive, Suite 300, San Mateo, CA 94404 Fax 650-403-2201
Mankind faces a crossroads. One path leads to despair and utter hopelessness,
the other to extinction. Let us pray we choose correctly. -- Woody Allen
Don Geddis <······@goto.com> writes:
> Alain Picard <·······@optushome.nospam.com.au> writes:
> > I mind that there is no industrial strength open source CL (so I'm not
> > hostage to *any* vendor).
>
> What are your objections to CMUCL? It's open source, nearly ANSI
> compatible, and produces running code that is often much faster than
> that created by many commercial Lisps.
This is not first-hand experience, but many people seem to mention the
following deficiencies:
Inefficient garbage collector, ancient backends for popular processors
such as sparc, lack of support for many Unix OS'es, big memory
requirements for the image... There were other complaints, but they
escape me at the moment.
Some of these things are worked on, but some haven't changed in years
and make the picture a bit depressing.
>>>>> "Hrvoje" == Hrvoje Niksic <·······@arsdigita.com> writes:
Hrvoje> Inefficient garbage collector,
The x86 version has a generational GC. The others still have the
original stop and copy GC.
Hrvoje> ancient backends for popular processors such as sparc,
What does ancient mean? The sparc backend has been updated to use
some of the new instructions available on an Sparc v9 (Ultra)
processor. Don't know if really makes a difference though. It ought
to be a 64-bit version, but no one has done that.
Hrvoje> lack of support for many Unix OS'es,
Yes, this is a problem, but obviously not a big enough problem that
people are willing to step up and do the difficult porting job. In
any case, the most popular ones (Linux, FreeBSD, Solaris) are well
covered.
Hrvoje> Some of these things are worked on, but some haven't
Hrvoje> changed in years and make the picture a bit depressing.
As you well know, like all free software, it depends on volunteers
with access to the appropriate platforms to make things happen. Are
you volunteering?
Ray
Hrvoje Niksic <·······@arsdigita.com> writes:
>
> Inefficient garbage collector, ancient backends for popular processors
> such as sparc, lack of support for many Unix OS'es, big memory
> requirements for the image... There were other complaints, but they
> escape me at the moment.
>
If you are willing to play with it the CMUCl GC can perform just fine
in pretty demanding Circumstances. I don't know how old the sparc
backend is - I use it on Ultras and it performs pretty well for me.
Memory requirements are minute cf Java.
I think you're repeating myth and lore here.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> I think you're repeating myth and lore here.
Quite possible. In fact, I made it clear that these were not
first-hand experiences. I would love to see all those items debunked
by people who actually use CMU CL.
Hrvoje Niksic <·······@arsdigita.com> writes:
> Quite possible. In fact, I made it clear that these were not
> first-hand experiences. I would love to see all those items debunked
> by people who actually use CMU CL.
Well, OK: I use CMUCL on Sun/Solaris, and it's generally fine. It
performs pretty well -- comparably with commercial implementations.
GC isn't a huge problem -- perhaps it is a bit slower than the
commercial generational GCs. For my applications (which have working
sets of several hundred Mb) the image size isn't a big deal - I can
see it might be for things that need to fit onto a floppy.
Things I miss are multithreading and 64bitness.
--tim.
Alain Picard <·······@optushome.nospam.com.au> writes:
> I mind that there is no industrial strength open source CL (so I'm
> not hostage to *any* vendor).
For certain definitions of "industrial strength", I think CMUCL is a
viable platform.
My gripes with it are limited to lack of pre-emptive threading, very
minor PCL integration issues, and the way it handles it's allocation
of memory. None of these were sufficient to stop us from building and
supporting a rather complex resource scheduling web application
dealing with a moderately large dataset on stock PC hardware, with all
Free Software tools.
We are starting to run into issues with the threading which may prompt
us to make a port to LispWorks, but we'll always support CMUCL. I
regretably am not skilled enough at the time to work with other CMUCL
maintainers to add pre-emptive threading, and we don't have sufficient
resources to help fund that either.
Recently when we do some operations on very large datasets and have
lots of objects hanging around, we run into memory shortages on our
PCs (64-128M of RAM) and CMUCL's overcommitment of memory can be
problematic then. We've not had that happen on prodution systems with
an appropriate amount of RAM tho.
We have several installations of the application in production, all on
CMUCL. Peter Van Eynde's magnificent Debian packaging of CMUCL and
it's supporting tools, the ILISP debian package (I'm the package
maintainer), the HyperSpec, Emacs, and Debian itself are a very
powerful combination. My "upbringing" being primarily in Free
Software, I find myself more comfortable in this realm than in any of
the commercial systems. Mind you that's purely opinion and I don't
begrudge anyone else their preferences.
> I mind that the toolkits for CL aren't as nearly as good as they are
> for Perl/Python/Java/etc.
I am most certainly biased, but I've yet to see an equal to USQL and
IMHO for web development in any other language. Mind you I have a
particular bent that is not well reflected in the commercial
"application server" market, and I'm more interested in the tools
ability to support my solutions to complex problems than it's
integration with existing mediocre toolkits. I've used WebObjects,
Zope, Perl and lots of other DB interfaces.
Of course, since I got to design and build those tools, they have a
good chance of satisfying my needs 8)
> Business reasons. I'm a CL programmer and a pragmatist. We chose CL
> because we could deliver the most bang for the buck. We chose it so
> we can stay ahead of the competition, which will try to duplicate our
> stuff with Perl/Java/C++/Whatever.
We moved to CL for the same reasons. We had done applications in
WebObjects, which is IMO the best commercial platform for web app
development, but it's still was much too slow and costly, and buggy
even, to meet our needs for the development of our existing product.
Well, that and the fact that if I didn't get to work in CL I was
planning on changing my profession.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
>>>>> Craig Brozefsky writes:
Craig> Alain Picard <·······@optushome.nospam.com.au> writes:
>> I mind that there is no industrial strength open source CL (so I'm
>> not hostage to *any* vendor).
Craig> For certain definitions of "industrial strength", I think CMUCL is a
Craig> viable platform.
I hope nobody thinks I'm pooh-poohing CMUCL. It's a fine lisp, and I
use it at home. But I could not recommend using it professionally (to
my company). As far as I know (and I'd *love* to be told I'm wrong
here) it doesn't run on Windows/NT (multiplatform is important to us)
and there's no CORBA orb for it. (Is ILU even ported to it?)
Also, as you mentioned, the threading models vary across
architectures, so that would limit the one-code base across platforms
which is one of our goals.
Craig> I am most certainly biased, but I've yet to see an equal to USQL and
Craig> IMHO for web development in any other language.
Xanaly's SQL package is excellent, but yes, USQL is an exciting
development on CMUCL. Being able to plug it in to an arbitrary ODBC
source would be the next step, I think.
Anyway, maybe my definition of "industrial strength" isn't yours.
Consider gcc -- it's so good that you have to make a serious business
case to use another C compiler. I don't think any open source lisps
are in that ballpark. And I fear the user community is too small to
ever reach that point, but I'd love to be proven wrong.
Craig> Well, that and the fact that if I didn't get to work in CL I was
Craig> planning on changing my profession.
Boy, I hear you there.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
In article <··············@gondolin.local.net> on Fri, 30 Mar 2001
19:22:28 -0600, "Alain Picard" <·······@optushome.com.au> wrote:
> Anyway, maybe my definition of "industrial strength" isn't yours.
> Consider gcc -- it's so good that you have to make a serious business
> case to use another C compiler. I don't think any open source lisps are
> in that ballpark. And I fear the user community is too small to ever
> reach that point, but I'd love to be proven wrong.
Hmm... gcc is good if you want a portable C compiler that can be assumed
to work the same on multiple platforms. I wouldn't use it if I cared
about speed. Supposedly MS Visual C++ compiles a faster gcc than gcc
does.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@rice.edu> writes:
> In article <··············@gondolin.local.net> on Fri, 30 Mar 2001
> 19:22:28 -0600, "Alain Picard" <·······@optushome.com.au> wrote:
>
> > Anyway, maybe my definition of "industrial strength" isn't yours.
> > Consider gcc -- it's so good that you have to make a serious business
> > case to use another C compiler. I don't think any open source lisps are
> > in that ballpark. And I fear the user community is too small to ever
> > reach that point, but I'd love to be proven wrong.
>
> Hmm... gcc is good if you want a portable C compiler that can be assumed
> to work the same on multiple platforms. I wouldn't use it if I cared
> about speed. Supposedly MS Visual C++ compiles a faster gcc than gcc
> does.
You're really talking small constant factors here. I think Lisp can
come close to the speed of other languages, but I don't think the
reason to use Lisp is that you are looking for an alternative to gcc.
Sure, there are applications where speed matters, but long ago most
lispers I know learned to value the speed of the whole edit-compile-debug
cycle. And a lot of lispy applications end up being ones that people long
ago gave up on writing in another language, so what good is benching
against that?
I just think people waste far too much time worrying about speed. It should
be the very last thing one considers in building an application, IMO.
In article <···············@world.std.com> on Sat, 31 Mar 2001 14:51:04
-0600, "Kent M Pitman" <······@world.std.com> wrote:
> You're really talking small constant factors here.
<snip>
> I just think people waste far too much time worrying about speed. It
> should be the very last thing one considers in building an application,
> IMO.
>
I think the problem here is that I would only use C for code that needed
to be fast (or needed to interact tightly with a C-based OS).
But your main point is very true. This kind of concern should not even be
raised while you're developing the application, but only in the
optimization stage.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
> I just think people waste far too much time worrying about speed. It should
> be the very last thing one considers in building an application, IMO.
I don't think thats true for all cases, though I'd agree it is for
many. At the moment, I'm working on some satellite flight code that
depends very heavily on the predictability of execution times of
application code- it doesn't depend equally heavily in all areas, but
some are critical. Its not exactly the same as speed, but it is
related, and required detailed, systematic requirements & design to
achieve it.
On the other hand, belaboring performance issues in parts of the
system where it isn't all that important does waste time & energy...
Gregm
"Rahul Jain" <·····@rice.edu> writes:
> Hmm... gcc is good if you want a portable C compiler that can be assumed
> to work the same on multiple platforms. I wouldn't use it if I cared
> about speed. Supposedly MS Visual C++ compiles a faster gcc than gcc
> does.
Are you talking compilation speed or the performance of the resulting
code?
Compilation speed has never been an issue for me. I haven't seen too
many C projects become so big that recompiling from scratch is a
serious time sink, yet still be so monolithic that separate
compilation and linking is not feasible.
Runtime performance, while it can be a problem if it is poor, is not
necessarily a commercial benefit if it is good (it just has to be
`good enough'). In my experience, MSVC++ produces code that is
inferior to gcc.
Here is an example that made me laugh. In C, it is tricky to
correctly write multi-statement macros. You need to enclose the
statements within a block, but ensure the resulting macro expansion is
a single statement. The standard trick is this:
do {statement1; statement2} while (0)
For those who haven't seen this trick, note that this expansion `eats'
a semi-colon. So if you have a macro of the form:
#define FOO(x,y) do { complicated series of statements } while (0)
This will work `correctly' in expressions like:
if (x > y)
FOO(x,y);
else
return 0;
While debugging some code with these sort of expansions in MSVC++, I
noticed frequent occurrances of
xor eax,eax
jnz ...
This was what the while(0) compiled into.
This raises doubts in my mind whether MSVC++ produces good code.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall <···@content-integrity.com> writes:
> While debugging some code with these sort of expansions in MSVC++, I
> noticed frequent occurrances of
>
> xor eax,eax
> jnz ...
>
> This was what the while(0) compiled into.
>
> This raises doubts in my mind whether MSVC++ produces good code.
Not to defend MSVC in general, but if debugging was turned on, could
it be that no optimization was performed, and the code was compiled
literally? With all optimization turned off, I wouldn't be surprised
to see "do ... while (0)" or "if (1)" compiled as such.
Alain Picard wrote:
>>>>>> Craig Brozefsky writes:
>
> Craig> Alain Picard <·······@optushome.nospam.com.au> writes:
>>> I mind that there is no industrial strength open source CL (so I'm
>>> not hostage to *any* vendor).
>
> Craig> For certain definitions of "industrial strength", I think CMUCL is
> a Craig> viable platform.
>
> I hope nobody thinks I'm pooh-poohing CMUCL. It's a fine lisp, and I
> use it at home. But I could not recommend using it professionally (to
> my company). As far as I know (and I'd *love* to be told I'm wrong
> here) it doesn't run on Windows/NT (multiplatform is important to us)
> and there's no CORBA orb for it. (Is ILU even ported to it?)
>
> Also, as you mentioned, the threading models vary across
> architectures, so that would limit the one-code base across platforms
> which is one of our goals.
>
> Craig> I am most certainly biased, but I've yet to see an equal to USQL
> and Craig> IMHO for web development in any other language.
>
> Xanaly's SQL package is excellent, but yes, USQL is an exciting
> development on CMUCL. Being able to plug it in to an arbitrary ODBC
> source would be the next step, I think.
Little Update:
I've talked with Paul Meurer (Maintainer of SQL-ODBC) and we resolved the
license issues with it. I'am very pleased to announce that it will be no
problem in future to release USQL with an SQL-ODBC based ODBC backend and
being able to develop commercial Applications with it.
But the much more amazing news is that Paul Meurer is working on a CMUCL
port of SQL-ODBC so we will see USQL with ODBC for CMUCL soon :-)
Regards,
Jochen
Jochen Schmidt wrote:
> Little Update:
> I've talked with Paul Meurer (Maintainer of SQL-ODBC) and we resolved the
> license issues with it.
Ahhh Sorry - this sounds like I would talk of Paul Meurer as "it" I meant
SQL-ODBC with "it".
Regards,
Jochen
In article <··············@gondolin.local.net>, "Alain Picard"
<·······@optushome.com.au> wrote:
> I hope nobody thinks I'm pooh-poohing CMUCL. It's a fine lisp, and I use it
> at home. But I could not recommend using it professionally (to my company).
> As far as I know (and I'd *love* to be told I'm wrong here) it doesn't run on
> Windows/NT (multiplatform is important to us) and there's no CORBA orb for it.
> (Is ILU even ported to it?)
Well, I have used clorb with CMUCL, so I don't think it is correct to say that
there is no orb for CMUCL. I don't anyone would call clorb an
industrial-strength orb, however. It may be correct to say that there is no
industrial-strength * orb * for CMUCL.
--Jim Amundson
On Thu, 29 Mar 2001 10:46:34 GMT, Alain Picard
<·······@optushome.nospam.com.au> wrote:
>Lars> I associate Common Lisp with attitudes, more than with programming
>Lars> techniques or algorithms. These attitudes are very visible is this n.g.
>Lars> A Common Lisper is a Philosopher and an Artist.
>
>Ouch.
>
>I suspect this was meant with (slightly) derogatory intent.
Webster's 1913 Dictionary (Hypertext):
Derogatory, Tending to derogate, or lessen in value
WordNet (r) 1.6:
derogative, derogatory, disparaging -- (expressive of low opinion;
"derogatory comments"; "disparaging remarks about the new house")
=> uncomplimentary (vs. complimentary)
Does this mean I should watch my step now? In one of his books,
Trevanian remarks that "Generalization is flawed thinking only when
applied to individuals". I'm not taking cover yet.
>I think the statement itself is actually true.
It has been said by several others over the years, so it probably is.
>Are you sure? It's been observed that productivity, in the software
>field, can vary by two orders of magnitude. Are you sure the kind of
>professionals needed are those at the bottom of that scale? It seems
>to me that those who think of themselves as `Philosophers and Artists'
>are precisely those with the introspection skills required to analyze
>their process, understand the hidden underlying requirements, and
>deliver high quality software.
If only this was generally true! But to continue this, you don't send
Rembrandt to milk the cow, since you might find him in trance over the
shaft of light coming in from the dust-speckled window of the shed,
wondering how to capture and immortalize it.
It seems to me that _you_ my friend, may have a slightly romantic view
of what professionality is. Try a next step and make `Philosophers
and Artists' to be good Businessmen as well? <grin>
>I've worked in two environments. One was part of a team of 30 C++
>programmers. One is part of 6 Lisp programmers. The latter team has
>delivered software of a complexity and quality which I *know* the
>former team could *never* have achieved. Is business better off
>paying 30 guys $50,000, or 6 guys $100,000 and getting a better product?
>I'll tell you the simple, bottom line business answer: the latter.
>I now get to hire people, and I hire the second category. And I'm not
>seduced by the "bums on seats" approach. Done that once, hopeless
>outcome.
My very best wishes of success to you. I will wave a flag any time I
hear about a new CL-based product, especially if it addresses a, shall
we say larger user category, can be run standalone on a major
platform, or requires a minimum of hardware/vendor considerations. The
portability issues taken care of, but not carried to any excesses.
Snipping away the rest, I certainly applaud your efforts. My response
was actually triggered by Erik Naggum's remark about "Real
Programming' and then others suggesting other-Lisp based applications,
notably Emacs and Autocad. That is old stuff, where is the new?
Good science fiction has been described as literature giving you 'a
sense of wonder'. Common Lisp, on a smaller scale, gives you a sense
of 'wow'. It's just that this is not enough, and the shortcomings are
probably not to be found in the language or the standard that
describes it. If it is not the CL language (which is not *that*
difficult), or the CL implementations, then what other possibly
derogatory assumptions about Common Lispers, including myself, could
explain the shortage I see when traversing Internet?
Raising my cup of coffee to your success,
Lars
·············@era.ericsson.se (Lars Lundback) writes:
> ... In one of his books,
> Trevanian remarks that "Generalization is flawed thinking only when
> applied to individuals". I'm not taking cover yet.
I wasn't clear on the relevance of this quote, but I liked it anyway.
> ... Good science fiction has been described as literature giving you 'a
> sense of wonder'. Common Lisp, on a smaller scale, gives you a sense
> of 'wow'. It's just that this is not enough, and the shortcomings are
> probably not to be found in the language or the standard that
> describes it. If it is not the CL language (which is not *that*
> difficult), or the CL implementations, then what other possibly
> derogatory assumptions about Common Lispers, including myself, could
> explain the shortage I see when traversing Internet?
Actually, CL has been (I think sometimes legitimately) criticized for
offering lots of implementational freedom. There are often several
ways to do what some languages would give you only one way to do. And
this has sometimes led to people creating problems for themselves.
The usual "solutions" in other languages to this kind of thing are:
- training classes
- style guides
- rigorous methodologies
Our community is often filled with inidividuals who are not followers
but leaders. Were they followers, they'd be programming in Java or
VB. As leaders, they are often puzzled by the need of others in the
community to want guidance because, to them, guidance is servitude.
Without guidance, some people get lost or don't do as well as they
would in a restricted language. The question is whether that makes the
more restricted language better.
If my analysis is right (and that's always an open question), Lars has
here turned the situation upside down to effectively (and not without
good intent) make "freedom" a villain. He is effectively saying,
perhaps without intending to, that people would be better off without
freedom. I'm not so sure that's wrong. But then again, I think
that's a choice they have to elect voluntarily. I don't think the
right solution is to kill off freedom for those who can make good use
of it. Nor is it to tell people that freedom is not the way. It may
just be that we're doomed to have a small community of very empowered
people. Making the cash flow work for that is tricky, but that
doesn't mean it's a bad business.
Just kind of thinking aloud here.
On Mon, 2 Apr 2001 13:45:50 GMT, Kent M Pitman <······@world.std.com>
wrote:
>·············@era.ericsson.se (Lars Lundback) writes:
>
>> ... In one of his books,
>> Trevanian remarks that "Generalization is flawed thinking only when
>> applied to individuals". I'm not taking cover yet.
>
>I wasn't clear on the relevance of this quote, but I liked it anyway.
Alain Picard suspected "a (slightly) derogatory intent", and I admit
there was some of it, although not directed towards anyone in
particular.
>Actually, CL has been (I think sometimes legitimately) criticized for
>offering lots of implementational freedom. There are often several
>ways to do what some languages would give you only one way to do. And
>this has sometimes led to people creating problems for themselves.
The implementational freedom is absolutely essential, no question
about that. About standards and fwiw, I was on a committee for a robot
programming language standard long ago, representing a "research"
viewpoint. Inexperience made me assume that the True Objective ought
to be some standard for an advanced future robot language. The
vendor/user representatives of course knew that they had to reconcile
many different demands starting at the current state of affairs.
We could put various new items on the wishing list, but I think the
CL standard is nevertheless very good. No problemo.
>The usual "solutions" in other languages to this kind of thing are:
> - training classes
> - style guides
> - rigorous methodologies
No need for that among CL programmers then? I think you are
bellittling you own efforts to bring good style and methodologies to
this community :-)
>Our community is often filled with inidividuals who are not followers
>but leaders. Were they followers, they'd be programming in Java or
>VB. As leaders, they are often puzzled by the need of others in the
>community to want guidance because, to them, guidance is servitude.
>Without guidance, some people get lost or don't do as well as they
>would in a restricted language. The question is whether that makes the
>more restricted language better.
This question does not make sense to me. How could a more restricted
language be better? I prefer to put it this way:
Few complex projects undertaken by man have ever been accomplished
without guidance and sometimes even coercion. It becomes more apparent
when team members lack experience of the phenomena they are dealing
with and the goal is not clearly visible and accepted.
Now, I have been saying all the time that CL is probably the best
language for a wide range of applications, great and small. One does
not _have_ to use the most esoteric language constructs. Appropriate
training can always be arranged, and most companies do so. To make it
short, the usual "technical" objections to using CL do not hold.
Aren't we all saying that?
>If my analysis is right (and that's always an open question), Lars has
>here turned the situation upside down to effectively (and not without
>good intent) make "freedom" a villain. He is effectively saying,
>perhaps without intending to, that people would be better off without
>freedom. I'm not so sure that's wrong. But then again, I think
>that's a choice they have to elect voluntarily. I don't think the
>right solution is to kill off freedom for those who can make good use
>of it. Nor is it to tell people that freedom is not the way. It may
>just be that we're doomed to have a small community of very empowered
>people. Making the cash flow work for that is tricky, but that
>doesn't mean it's a bad business.
I painted the picture in black and white on purpose. Being the devil's
advocate is fun, but I won't make more of it than I have already. CL
is the mother church, and it's believers sometimes need to be
corrected, lest they become too saintly.
>Just kind of thinking aloud here.
So did I, by observing that " ...These attitudes are very visible is
this n.g. A Common Lisper is a Philosopher and an Artist.". But
leader, judging from observable publishings and software that are used
by many followers? I must have missed a lot in spite of my very
frequent visits on the "web". Please enlighten me more :)
Regards, Lars
·············@era.ericsson.se (Lars Lundback) writes:
> So did I, by observing that " ...These attitudes are very visible is
> this n.g. A Common Lisper is a Philosopher and an Artist.". But
> leader, judging from observable publishings and software that are used
> by many followers? I must have missed a lot in spite of my very
> frequent visits on the "web". Please enlighten me more :)
I don't think it's an essential characteristic of a leader that they have
followers. Rather, I think it's an essential characteristic of a leader
that they not lead. At least in this context. The point is that most
CL programmers I know are not lemmings.
I've been in discussions with Lisp people in the past where I've
suggested selling training in style, methodology, etc. where I've had
the person respond blankly, "why would anyone want to be told what to
do, much less pay for it...?" Yet the observable truth is that they want
just exactly that. Not just to be told what to do but to pay richly for
such service if it's packaged and promoted right (not always simple tasks).
I've often felt it ironic that one of the big missing things in the
Lisp community has been education--something that you can actually
charge for directly. It's not like people asking for a better compiler
where if you do the work, customers mostly don't want to pay extra for
your trouble--people really do budget "extra" for training even if they
don't budget extra for "improved compilers" or "two more active-x controls".
Kent M Pitman <······@world.std.com> writes:
> ·············@era.ericsson.se (Lars Lundback) writes:
>
> > So did I, by observing that " ...These attitudes are very visible is
> > this n.g. A Common Lisper is a Philosopher and an Artist.". But
> > leader, judging from observable publishings and software that are used
> > by many followers? I must have missed a lot in spite of my very
> > frequent visits on the "web". Please enlighten me more :)
>
> I don't think it's an essential characteristic of a leader that they have
> followers.
I disagree with this statement. One who does not follow and who
also does not lead is an individualist.
> Rather, I think it's an essential characteristic of a leader
> that they not lead.
A contradiction in definition. Again, I offer the alternative of
"individulalist" for what you seem to be describing.
Perhaps what you are alluding to is related to the fact that when
most people think of leadership, they think of coercion. But it is
not necessary to coerce in order to lead. As a once and sometimes
manager, I was well-trained by a previous employer in concepts of
leadership. One concept that I learned was "Situational Leadership",
(there are various books out which are now newer than the one I
learned from). Part of that philosophy is that there are different
maturity levels in "followers", and there are various kinds of power
that a leader exerts over those followers, based on their maturity.
Coercion is only one of many, and is in fact the lowest - from
memory, I'll see if I can get them straight in ascending order:
coercion: "if you don't do this you'll be punished"
connection: "you'd better do this because I know the boss"
reward: "do this and I'll reward you"
legitimate: "do this because I'm the boss"
charismatic: "do this because I'm such a likeable person"
knowledge: "do this because I know what's going on"
expert: "do this because I am the expert in this field"
I may have missed one or two, but I know that those that are
present are in the right order.
> At least in this context. The point is that most
> CL programmers I know are not lemmings.
I agree completely with this. I just don't agree with the
follower/leader dichotomy. Common Lispers tend to be
Individualists, which doesn't fit the dichotomy.
> I've been in discussions with Lisp people in the past where I've
> suggested selling training in style, methodology, etc. where I've had
> the person respond blankly, "why would anyone want to be told what to
> do, much less pay for it...?" Yet the observable truth is that they want
> just exactly that. Not just to be told what to do but to pay richly for
> such service if it's packaged and promoted right (not always simple tasks).
This describes an Individualist precisely. The Bad Thing about
individualists is that they aren't shackled by leaders or tied
down by followers. The Good Thing about individualists is that
they aren't shackled by leaders or tied down by followers.
> I've often felt it ironic that one of the big missing things in the
> Lisp community has been education--something that you can actually
> charge for directly. It's not like people asking for a better compiler
> where if you do the work, customers mostly don't want to pay extra for
> your trouble--people really do budget "extra" for training even if they
> don't budget extra for "improved compilers" or "two more active-x controls".
This doesn't happen without trainees. Take a look at our website,
click on "Services" and then "Classes". The number of classes offered
at any time tends to directly correspond to how many are willing to sign
up for them.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
On Tue, 3 Apr 2001 12:15:48 GMT, Kent M Pitman <······@world.std.com>
wrote:
>·············@era.ericsson.se (Lars Lundback) writes:
>
>> So did I, by observing that " ...These attitudes are very visible is
>> this n.g. A Common Lisper is a Philosopher and an Artist.". But
>> leader, judging from observable publishings and software that are used
>> by many followers? I must have missed a lot in spite of my very
>> frequent visits on the "web". Please enlighten me more :)
>
>I don't think it's an essential characteristic of a leader that they have
>followers. Rather, I think it's an essential characteristic of a leader
>that they not lead. At least in this context. The point is that most
>CL programmers I know are not lemmings.
Ok, they are Daniel Boone walking in front of them. But lemmings are
reputed for hurling themselves into the sea and drowning. Maybe Boone
ought to look at the terrain as well as his own map?
(Unable to resist that. Wonderful day, and spring is on it's way too)
>I've been in discussions with Lisp people in the past where I've
>suggested selling training in style, methodology, etc. where I've had
>the person respond blankly, "why would anyone want to be told what to
>do, much less pay for it...?" Yet the observable truth is that they want
>just exactly that. Not just to be told what to do but to pay richly for
>such service if it's packaged and promoted right (not always simple tasks).
>
>I've often felt it ironic that one of the big missing things in the
>Lisp community has been education--something that you can actually
>charge for directly. It's not like people asking for a better compiler
>where if you do the work, customers mostly don't want to pay extra for
>your trouble--people really do budget "extra" for training even if they
>don't budget extra for "improved compilers" or "two more active-x controls".
Most companies know they cannot expect much useful work getting done
by students fresh from their graduations (in many disciplines). For
eg. masters of science, it has been said that one needs a year to
really get the speed up.
And yes, a lot of companies will pay for education, easily, if the
gains are there, and visible.
Kindly, Lars
Lars Lundback <·············@era.ericsson.se> writes:
>
> I associate Common Lisp with attitudes, more than with programming
> techniques or algorithms. These attitudes are very visible is this n.g.
> A Common Lisper is a Philosopher and an Artist. He does not mind that
> there are essentially only two Common Lisp vendors in this world. (There
> is of course Corman Lisp, which does not seem to count since it is based
> on MS-Windows, and a few others which must be extended to fit the actual
> needs, but so what?).
>
A more interesting question for most people is `how many plausible
vendors are there on my platform'. For me, that's probably 2 + some
free ones for Lisp, and, erm, 1 + some free ones for C/C++. I don't
really care, for instance, how many vendors there are for DEC alphas
running OS/9 or something.
--tim
On 29 Mar 2001 19:26:59 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>A more interesting question for most people is `how many plausible
>vendors are there on my platform'. For me, that's probably 2 + some
>free ones for Lisp, and, erm, 1 + some free ones for C/C++. I don't
>really care, for instance, how many vendors there are for DEC alphas
>running OS/9 or something.
You are right, but I was looking more at the general situation, which
has been discussed often before.
I regard all attempts at building new CL implementations with favour.
Such exercises indicate discomfort with the existing ones, or a
healthy need to learn and better the underlying machinery, often made
in an effort to extend functionality beyond the standard.
Commercial implementations indicate a healthy whish to make money
based on the needs of a large and demanding programming community.
Whenever there is one ..., well maybe you get my drift now.
The same goes for publicly available contributions, free or not. Your
own is noted with gratitude, along with others. Things will look
better when there are lots of goodies on the shelves, free, for rent,
or to buy. In short, a variety of applications (I consider libraries
as one kind of application), and they don't have to be that grand
either.
Is it true that the solution of a CL-based application must be
complex, thus reflecting the Common Lisper's brilliance, and less it's
usability at large? >:->
Regards, Lars
* Lars Lundback wrote:
> I regard all attempts at building new CL implementations with
> favour. Such exercises indicate discomfort with the existing ones,
> or a healthy need to learn and better the underlying machinery,
> often made in an effort to extend functionality beyond the standard.
> Commercial implementations indicate a healthy whish to make money
> based on the needs of a large and demanding programming community.
> Whenever there is one ..., well maybe you get my drift now.
Well, I'm not really sure about this. I think it's clear, for
instance, that C is a language in which a lot of important
applications are written -- Unix for instance. And yet I'm not sure
that a huge number of people are working on new commercial C
implementations. This may be because I'm unfamiliar with the market
other than as a user of course, but some apocryphal evidence seems to
back me up. This evidence is that, in many cases when people really
*need* a new C implementation, such as when they're building a new
processor, they often port gcc rather than writing a new compiler. I
believe this has been true for a lot of recent embedded processor
designs - new embedded designs being far more common than new
`workstation' processors which typically arrive only once every few
years. C is a language for which you'd expect a much simpler
implementation than CL, and yet people prefer to add a new backend to
an existing system rather than produce a new implementation.
My inference from this, and from some thought about the economics of
implementing a language, is that it is fairly hard to make money doing
this. In fact, I think that many well-known language implementations
do not make money at all - they lose it, probably in large quantities.
The reason they are done is because the company doing them needs the
language for some other reason: to support some other product
- Sun clearly need a C compiler to support Solaris, and they need
Solaris to support the big machines where they make their money - to
try and win some war against another company - Java is a good example,
the war being Sun vs Microsoft - or to tie people to a product - C#,
or virtually any MS language being a good example, and Java possibly
being an attempt too (though I think it was not: Sun probably think
they can win a fair fight with the other Unix vendors, so they simply
needed to provide people with a way out of the MS lock-in).
If this is right, it explains a couple of things - firstly why
commercial Lisp systems are expensive: they have to be because they
are intended as profit centres and not cost centres for the companies
producing them. Secondly why there are not a plethora of new
commercial Lisp systems out there - it's commercially better to buy a
system than write it, unless there is some compelling other reason you
need it. Indeed I think that if I really wanted control over a Lisp
implementation for one of the reasons above, my first move would be to
try and buy one of the existing vendors!
--tim
Tim,
Perhaps I should not have snippet your posting. Since I did, here it
goes:
On 02 Apr 2001 13:52:14 +0100, Tim Bradshaw <···@cley.com> wrote:
>Well, I'm not really sure about this. I think it's clear, for
>instance, that C is a language in which a lot of important
>applications are written -- Unix for instance.
Absolutely. Like Superman's father said in the (first) movie, when
addressing the jury: "It is an undeniable fact of evidence..."
> .. And yet I'm not sure
>that a huge number of people are working on new commercial C
>implementations. This may be because I'm unfamiliar with the market
>other than as a user of course, but some apocryphal evidence seems to
>back me up.
I'm not very conversant with the various C compiler projects and
-vendors myself. So I threw 'C', 'compiler' and 'vendor' at
google.com and immediately got:
... development for the NAPA C compiler (DARPA project)
... the Keil 8051 C Compiler
... MMC Networks Unveils C/C++ Compiler ...
... VTune(tm) Performance Analyzer and the Intel(r) C/C++ Compiler
and that on the first hit page. When you take into account C++ and all
the modules, add-ons etc sourrounding it, you even have vendors
offering to sell you CD disks with information on that. Goodness, the
place is full of C compiler/module info.
Then I remind you that an 'implementation' can take many forms, from a
basic CL compiler to a vendor's commercial Common Lisp with everything
on the menu. WRT your remark below about gcc, the gcc success story
was built on numerous people's willingness to put their individual
straws on a collective stack, and it was not built overnight. Common
Lisp has had about the same time to get rolling. I am now trying to
find the corresponding thing here.
> This evidence is that, in many cases when people really
>*need* a new C implementation, such as when they're building a new
>processor, they often port gcc rather than writing a new compiler. I
>believe this has been true for a lot of recent embedded processor
>designs - new embedded designs being far more common than new
>`workstation' processors which typically arrive only once every few
>years. C is a language for which you'd expect a much simpler
>implementation than CL, and yet people prefer to add a new backend to
>an existing system rather than produce a new implementation.
Then I suggest reverence in front of those (seemingly) few that
actually undertake that task. One new implementation that comes to
mind immediately is the Corman CL. A few others work on variations
using CMU CL, Kyoto CL, perhaps CLISP. Hats off, the rest of us.
Although it does seem plausible that a lot can be achived if one has
the inclination and the persistence. That, I think, is the primary
bottleneck.
>My inference from this, and from some thought about the economics of
>implementing a language, is that it is fairly hard to make money doing
>this. In fact, I think that many well-known language implementations
>do not make money at all - they lose it, probably in large quantities.
>The reason they are done is because the company doing them needs the
>language for some other reason:
I snipped here. You said it yourself, there must be a need as the
driving force, and that need is not the language in itself. _Of
course_ it must be used. We are on a carousel.
>If this is right, it explains a couple of things - firstly why
>commercial Lisp systems are expensive: they have to be because they
>are intended as profit centres and not cost centres for the companies
>producing them. Secondly why there are not a plethora of new
>commercial Lisp systems out there - it's commercially better to buy a
>system than write it, unless there is some compelling other reason you
>need it. Indeed I think that if I really wanted control over a Lisp
>implementation for one of the reasons above, my first move would be to
>try and buy one of the existing vendors!
With what money? The profit you made when using his product? If by
systems you mean the combination of language, compiler and
programmer's support tools, then explain why there is a plethora of
commercial systems outside the Common Lisp world? Few of them, if any,
started as profit centres. Commercial Lisp systems may seem expensive.
If they are the only basic reason is the very small customer base.
What I am doing is putting needles in a collective CL community that
keeps boasting of this Lisp standard that I have been enthusiastic
about since it was presented. I observe that references to Lisp
applications are often those not based on Common Lisp. That the use of
Common Lisp would increase if yet more of complete CL programming
environments appear, not only the Emacs-oriented, and one does not
need new core implementations to accomplish that...
Regards, Lars
* Lars Lundback wrote:
> ... development for the NAPA C compiler (DARPA project)
> ... the Keil 8051 C Compiler
> ... MMC Networks Unveils C/C++ Compiler ...
It's significant that all of these are for special processors - the
NAPA compiler is for some family of FPGAs, the 8051 compiler is, well,
for the 8051, the MMC compiler is for some weird network processor.
> ... VTune(tm) Performance Analyzer and the Intel(r) C/C++ Compiler
And this is not a compiler. However Intel clearly are in the category
of people who produce a compiler to support their main product.
Indeed Intel are probably struggling right now to produce a compiler
which will generate reasonable code for ia64...
> and that on the first hit page. When you take into account C++ and all
> the modules, add-ons etc sourrounding it, you even have vendors
> offering to sell you CD disks with information on that. Goodness, the
> place is full of C compiler/module info.
I'm not denying that the C/C++ world is churning out more
implementations than the Lisp world. However I really doubt there are
a huge number of pure-play compiler vendors out there. I repeat my
(guessed, obviously) assertion that almost everyone is either selling
the compiler to support some other product that they sell. *Or* they
are selling libraries of some kind, or they're selling things like
Purify which help you escape from the problems of writing in C/C++
(this is a second, new, claim).
Considering how many more people writing C/C++ professionally than
there are writing Lisp, I would even venture to claim that there are
*less* serious compilers-per-professional-programmer for C/C++ than
there are for Lisp. Of course I don't have evidence for this (this is
usenet, evidence is disallowed), but in the general-purpose-computer
world I doubt there are a huge number of implementations, and I
suspect that almost all of them are not pure-play vendors but people
trying to sell something else which needs a compiler to support it.
In any case, I want to claim that the number of implementations is
simply irrelevant to a language's popularity. How many VB
implementations are there, how many Perl, how many tcl? Do you think
it would be a good way to spend your time to write a Perl
implementation? If not, why is it a good way of spending your time to
write a CL system? At the other end of the spectrum how many Scheme
implementations are there?
None of this is to say that I don't respect the people who do write CL
systems: obviously I do.
> With what money? The profit you made when using his product?
Sure. Or any other of the normal ways companies buy each other (note
I'm not actually planning on doing this!).
The point I'm trying to make is that, if you are writing on a
mainstream platform (not an embedded processor, I guess), then you
probably have either one or two commercial systems and either one or
two free ones which are of usable quality. Why do you need more? I
certainly do not need more: what's holding me back is not a vast
number of CL implementations to waste my time choosing between, it's
the fact that I can't program very well, and I probably don't have any
ideas which will make me rich if I could, so I spend my time ranting
away on usenet instead. My guess is that that's what holds most of us
back.
--tim
On 02 Apr 2001 18:14:03 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>I'm not denying that the C/C++ world is churning out more
>implementations than the Lisp world. However I really doubt there are
>a huge number of pure-play compiler vendors out there. I repeat my
>(guessed, obviously) assertion that almost everyone is either selling
>the compiler to support some other product that they sell. *Or* they
>are selling libraries of some kind, or they're selling things like
>Purify which help you escape from the problems of writing in C/C++
>(this is a second, new, claim).
Yes, yes but if you look a bit further than the mere facts? If we
don't we are in an endless loop:
"Why are there so many offerings in the C/C++/Java markets?
Because there is a need for them.
Why do people go shopping on the C/C++/Java markets?
Because they find a lot that they need."
There is nothing built into CL that prevents it's programmers to take
a place, _if_ they want to. That was my point. Also that it does not
have to be grand from the start.
>Considering how many more people writing C/C++ professionally than
>there are writing Lisp, I would even venture to claim that there are
>*less* serious compilers-per-professional-programmer for C/C++ than
>there are for Lisp. Of course I don't have evidence for this (this is
>usenet, evidence is disallowed), but in the general-purpose-computer
>world I doubt there are a huge number of implementations, and I
>suspect that almost all of them are not pure-play vendors but people
>trying to sell something else which needs a compiler to support it.
>
>In any case, I want to claim that the number of implementations is
>simply irrelevant to a language's popularity. How many VB
>implementations are there, how many Perl, how many tcl? Do you think
>it would be a good way to spend your time to write a Perl
>implementation? If not, why is it a good way of spending your time to
>write a CL system? At the other end of the spectrum how many Scheme
>implementations are there?
Never ask questions like that without lots of smileys. Perl, Scheme?
Arrgh.
As for CL, perhaps not actually writing one. But knowledge of the
internal machinery is important if you want to make good applications,
one must get to _know_ a user's expectations and needs before
designing his interface, etc. How is that possible of one always stops
when the initial ideas seem to work?
>None of this is to say that I don't respect the people who do write CL
>systems: obviously I do.
>
>> With what money? The profit you made when using his product?
>
>Sure. Or any other of the normal ways companies buy each other (note
>I'm not actually planning on doing this!).
>
>The point I'm trying to make is that, if you are writing on a
>mainstream platform (not an embedded processor, I guess), then you
>probably have either one or two commercial systems and either one or
>two free ones which are of usable quality. Why do you need more? I
>certainly do not need more: what's holding me back is not a vast
>number of CL implementations to waste my time choosing between, it's
>the fact that I can't program very well, and I probably don't have any
>ideas which will make me rich if I could, so I spend my time ranting
>away on usenet instead. My guess is that that's what holds most of us
>back.
100%, make it 110%. Agreed. Yes. We discuss _how_ to use the most
powerful language, but what do we produce when using it?
Lars
PS. I got myself a good grin from you recent article about why people
dislike Lisp and the effect of academic nogoods. It gave me a sense of
wow. It is almost possible to read between the lines and find advice
about the need for writing "real" applications. (append smiley)
·············@era.ericsson.se (Lars Lundback) writes:
>
> Yes, yes but if you look a bit further than the mere facts? If we
> don't we are in an endless loop:
>
> "Why are there so many offerings in the C/C++/Java markets?
> Because there is a need for them.
>
> Why do people go shopping on the C/C++/Java markets?
> Because they find a lot that they need."
>
> [..]
> PS. I got myself a good grin from you recent article about why people
> dislike Lisp and the effect of academic nogoods. It gave me a sense of
> wow. It is almost possible to read between the lines and find advice
> about the need for writing "real" applications. (append smiley)
I think we likely agree. I think that the way to make Lisp more
successful (and overcome some prejudices) is by cool, real-world
applications. I particularly think that this is more important than a
multiplicity of implementations (although I would be worried if there
were *less* than 2 supported systems for any platform I was
considering...). Badly-written academic AI code is not cool.
I personally think that the way to greater success is also not through
trying to interface with everything under the sun. It's nice to be
buzzword-compliant, but as far as I can see things like CORBA and XML
& whatever-is-fashionable-this-week are *so* badly-designed and
overcomplex that the only way to support them is to hire a million
monkeys, and this is not a luxury we have. Better to use the fact
that we already have something that does all the interesting things
XML does, and use that in some interesting new application. You can
get an awful long way with sockets alone, if you can think of
something interesting to do. After all, that's how the web took off,
though it's hard to remember it now as it gets buried under
overcomplex standards.
--tim
I use common lisp to implement compilers and language translators. In our
consulting practice, we often take a "physicists" attitude towards solving
problems, i.e. find a notation in which to express the problem, then use the
notation to solve the problem. So, we often end up building application
specific languages.
Common Lisp makes experimentation with such languages extremely easy, since
it has everything you need to build a compiler built into the lisp
language - hashes for symbol tables, stacks (lists + push / pop) for scopes,
the lisp reader for tokenizing (i.e. scanning).
Common Lisp has all the features you need for RAD (rapid application
development) - garbage collection, run-time type checking instead of
compile-time (this reduces syntactic noise, and lets you change your mind
rapidly without suffering long re-editing cycles (I used to be a
strong-typing bible thumper, but I've begun to realize that it causes more
problems than the ones that it actually solves)).
And, best of all, Common Lisp does not constrain you to a single paradigm.
I tried to like Smalltalk and Eiffel, but finally decided that OOP is a huge
set of epicycles in the programming process, causing confusion and resulting
in no more practical reuse than using old fashioned libraries, e.g. it takes
at least as long to learn to use the best Smalltalk (VAST) class library as
it takes to become a Windows programmer; you can't get a VAST job unless you
can demonstrate 5 years of experience (something's wrong with that picture
of reuse).
I'm currently building a practical visual language in Common Lisp. In the
past I built an Eiffel compiler in emacs lisp, a semantics description
language (i.e. the hard part of a compiler) in lisp, a source-to-source
language translation tool and all sorts of experimental languages and tools
in lisp.
pt