Reddit Guys on the Pros and Cons of Lisp
Adam Connor
http://www.davidnewberger.com/wp/2005/11/28/if-you-havent-reddit-you-are-missing-out/
as seen on Planet Lisp:
"In the pros department: it’s a great programming language. Ruby,
python, perl, java can’t really compete as languages. HTML and
symbolic expressions are almost a one-to-one mapping, so generating
HTML is a breeze. It’s great fun to work in, and I’ve certainly
learned a good deal about programming in general just for using it.
"Having a Lisp process I can manipulate on a live server has been very
handy for updating small changes and debugging as well.
"The drawbacks all basically stem from the same problem. Since very
few people actually use Lisp, we can’t take advantage of the
tremendous community support the other languages have. There are few
libraries, few implementations, and little real-world examples of
building large-scale websites in Lisp. The language itself (ANSI
Common Lisp) hasn’t changed much since it was standardized, which was
about 20 years ago.
"I don’t regret writing reddit in Lisp at all. It’s a particularly
good language for developing applications without a solid plan of
where you’re going. Lisp never gets in the programmer’s way. However,
sometimes (oftentimes, more like it) the environment does (again, lack
of a strong community). We may rewrite reddit in something else as we
bring on more programmers, but Lisp has certainly served as well up
until this point."
I suspect the drawbacks have a lot to do with scaring bigger
organizations away from Lisp.
--
adamnospamaustin.rr.com
s/nospam/c\./
jayessay
> From
> http://www.davidnewberger.com/wp/2005/11/28/
if-you-havent-reddit-you-are-missing-out/
>
> tremendous community support the other languages have. There are few
> libraries, few implementations, and little real-world examples of
^^^^^^^^^^^^^^^^^^^
If nothing else, this bit is crazy. There are probably too many
implementations floating around if anything.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Bruce Hoult
jayessay <nos...@foo.com> wrote:
> Adam Connor <u...@nospam.com> writes:
>
> > From
> > http://www.davidnewberger.com/wp/2005/11/28/
> if-you-havent-reddit-you-are-missing-out/
> >
> > tremendous community support the other languages have. There are few
> > libraries, few implementations, and little real-world examples of
> ^^^^^^^^^^^^^^^^^^^
>
> If nothing else, this bit is crazy. There are probably too many
> implementations floating around if anything.
Yep. How many implementations are there of Perl, Python, Ruby, Visual
Basic, PHP?? Doesn't stop any of them.
--
Bruce | 41.1670S | \ spoken | -+-
Hoult | 174.8263E | /\ here. | ----------O----------
Bill Atkins
particular do they need that aren't already available? There exist
Common Lisp libraries for the most common application areas (database
interfaces, networking, bioinformatics, web servers, XML processing,
etc. plus a few neat libraries that most other languages couldn't even
think about having (CL-WHO, UCW, iterate)). For sure there aren't as
many libraries for Common Lisp as there are for, say, Perl, but take
advantage of interactive development and write them yourself.
Seriously, though, what are all of these great libraries that Lispers
are missing out on?
Bill
Eric Hanchrow
Bill> Seriously, though, what are all of these great libraries
Bill> that Lispers are missing out on?
Here's an example of a Perl library that I found that saves me a bit
of work: 'Graph'. It does topological sorting, and finds the sources
of a graph. I could probably have written those pieces that I needed
myself, but it sure is nice to have it already written.
--
I shrivel inside each time [Star Wars] is mentioned.
-- Sir Alec Guinness
Emre Sevinc
>>>>> "Bill" == Bill Atkins <batk...@gmail.com> writes:
Bill> Seriously, though, what are all of these great libraries
Bill> that Lispers are missing out on?
EH> Here's an example of a Perl library that I found that saves me
EH> a bit of work: 'Graph'. It does topological sorting, and
EH> finds the sources of a graph. I could probably have written
EH> those pieces that I needed myself, but it sure is nice to have
EH> it already written.
Did you check out new Common Lisp libraries by Garry King?
CL-Containers Common-Lisp's answer to STL and Smalltalk
CL-Graph Utilities and algorithms for Graph manipulation
CL-MathStats Miscellaneous math and statistics utilities
CL-Variates Portable Random Number Generators and tools
metabang.bind Handle destructuring, multiple-values and let simultaneously
Metatilities Various useful utilities
Moptilities Implementation independent MOP utilities
TINAA Common-Lisp documentation tool
http://lemonodor.com/archives/001288.html
http://www.metabang.com/open-source-software.html
Is cl-graph mature enough to help you or does it lack
some functionality?
Happy hacking,
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
codyk........@gmail.com
> Seriously, though, what are all of these great libraries that Lispers
> are missing out on?
>
> Bill
>
If anybody actually wants to listen to newcomers, rather than ignoring
any hint of deficiency in their (admittedly awesome) favorite language,
here's a couple:
1. A community standard, cross-implementation tool to find and install
libraries, ala cpan or ruby-gems. asdf-install is close, but: A. lots
of authors dont use it and B. the sbcl version is (afaik) still not
merged with the portable version. The difference between 'gem install
rails' and, say, manually tracking down all of the dependencies needed
for the latest UCW is phenomenal.
2. A solid https / http client library that handles cookies. LWP is a
gateway drug for perl, and CL doesnt have anything that comes close.
trivial-http is too trivial. cl-curl is not asdf-installable, due to
(afaik) the author being dissatisfied with asdf-install as compared to
clc.
lest I be accused of merely whining, i would be happy to work on these
issues, given some indication of possible directions, eg.
#2 may be as straightforward as writing up a 'howto write web scrapers
using common lisp', which I may do if cl-curl ends up meeting my needs.
(last time I needed a scraper, I ended up writing it in python after
little success)
#1b is probably over my head, but I'd be happy to find out otherwise.
#1a . . . .? go about on CLiki making asdf-installable versions of
software where possible?
-cody
Pascal Bourguignon
> Bill Atkins wrote:
>> Seriously, though, what are all of these great libraries that Lispers
>> are missing out on?
>>
>> Bill
>>
>
> If anybody actually wants to listen to newcomers, rather than ignoring
> any hint of deficiency in their (admittedly awesome) favorite language,
> here's a couple:
>
> 1. A community standard, cross-implementation tool to find and install
> libraries, ala cpan or ruby-gems. asdf-install is close, but: A. lots
> of authors dont use it and B. the sbcl version is (afaik) still not
> merged with the portable version. The difference between 'gem install
> rails' and, say, manually tracking down all of the dependencies needed
> for the latest UCW is phenomenal.
Is there a way to collect automatically the list of declared packages
(asdf-installable) in cliki.net?
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
drewc
> "codyk........@gmail.com" <codyko...@gmail.com> writes:
>
>
>>Bill Atkins wrote:
>>
>>>Seriously, though, what are all of these great libraries that Lispers
>>>are missing out on?
>>>
>>>Bill
>>>
>>
>>If anybody actually wants to listen to newcomers, rather than ignoring
>>any hint of deficiency in their (admittedly awesome) favorite language,
>>here's a couple:
>>
>>1. A community standard, cross-implementation tool to find and install
>>libraries, ala cpan or ruby-gems. asdf-install is close, but: A. lots
>>of authors dont use it and B. the sbcl version is (afaik) still not
>>merged with the portable version. The difference between 'gem install
>>rails' and, say, manually tracking down all of the dependencies needed
>>for the latest UCW is phenomenal.
>
>
> Is there a way to collect automatically the list of declared packages
> (asdf-installable) in cliki.net?
>
You mean like http://www.cliki.net/asdf-install , or something more
invloved?
drewc
--
Drew Crampsie
drewc at tech dot coop
"... the most advanced use of lisp in the field of bass lure sales"
-- Xach on #lisp
Pascal Bourguignon
> Pascal Bourguignon wrote:
>> "codyk........@gmail.com" <codyko...@gmail.com> writes:
>>
>>>Bill Atkins wrote:
>>>
>>>>Seriously, though, what are all of these great libraries that Lispers
>>>>are missing out on?
>>>>
>>>>Bill
>>>>
>>>
>>>If anybody actually wants to listen to newcomers, rather than ignoring
>>>any hint of deficiency in their (admittedly awesome) favorite language,
>>>here's a couple:
>>>
>>>1. A community standard, cross-implementation tool to find and install
>>>libraries, ala cpan or ruby-gems. asdf-install is close, but: A. lots
>>>of authors dont use it and B. the sbcl version is (afaik) still not
>>>merged with the portable version. The difference between 'gem install
>>>rails' and, say, manually tracking down all of the dependencies needed
>>>for the latest UCW is phenomenal.
>> Is there a way to collect automatically the list of declared
>> packages
>> (asdf-installable) in cliki.net?
>>
>
> You mean like http://www.cliki.net/asdf-install , or something more
> invloved?
Yes, that's it.
:(search :term (package) :title "<h2>asdf-installable packages</h2>")
Thanks.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Pisin Bootvong
there are few implementation. But that there are few free
implementations that always works. (I think most people are not going
to pay for ACL or LispWorks while they can download Ruby, Python or
Java for free and can also use it for commercial)
Choices are: CLISP, CMUCL and SBCL.
If I need to work on Windows then I have to choose CLISP.
If I need to use multithread then I need to use SBCL, and only work on
x86 Linux.
If I need to use FFI-Callback, I need to sue CMUCL or CLISP, SBCL
callback only work on x86 Linux.
If I need to use Unicode then I have to choose SBCL or CLISP.
Can you tell me what should I choose if I need multithread Lisp on
Windows?
Please don't tell me to choose an implementation based on each project.
I never have to do that with Java. The benefit of never need to change
the lisp implementation is that I can be proficient in it. No
implementation is going to be perfect. So instead of learning to work
around only one implementation's bug, with multiple implementation I
have to be aware of that implementation's different behavior and
workaround. That's not nice.
Most of the time, nobody has such problem when they are working with
Ruby or Java. They either have the feature or they don't. And if they
don't, the chances are that a feature added by 3 people working on one
implementation will be more robust/well-designed/well-maintained than a
feature added by 3 people, each works on separate lisp implementation.
-----
Regarding the availability of libraries, most open-source library comes
from the need of the original author to solve their problem at hands.
If I were the author of some good library, how much effort am I going
to spend to make sure that my libraries works on CLISP or CMUCL when my
environment was Lispworks with Multithread and Unicode support?
Someone might like my library and helping porting parts to CMUCL,
another guy to CLISP. But isn't that waste of effort? If they don't
have to do that, they can put effort on adding features to the library
instead.
And often, the effort is even more wasted. Some people saw a library
that do what they like but not on the supported implementation. But the
library may be to hard to port, too much must be done to make it work
on their platform. So instead of porting, they decide to write a new
library, only little variant from the original library, only with less
feature, rarely maintained, but it works for their cases. Just take a
look at http://www.cliki.net/database. Many of them works only on a
specific implementation. And to port them all to CFFI would require
lots of effort. If only lisp define standard FFI interface, all of
those library would be automatically ported.
If someone writes a library that works on Java or Ruby, it works for
others that download them, that's because they all are on the same
implementation. At most, they will be dealing with OS-dependent
work-around. But those are still less of the issue than both
implementation dependent and OS dependent issue.
>From what I observes, library that are not much diversed are libraries
which only do calculation. CL-PPCRE, ITERATE, etc. are portable and
cool. It draws lots of user.
But very small amount of user goes for something that is specific to
SBCL, CMUCL, etc. For example, Araneida/UCW doesn't even have Unicode
and File upload support. How long has Python came out? Lisp is way
older but yet we don't even have an application server as good as Zope
yet? Please tell me why.
No software in the world is bug-free, even those made in Lisp. So for
anyone wanting to get their work done, picking the library that has
more user base is often safe bet. Having three different library only
do job of dividing user base.
Pascal Costanza
> Please don't tell me to choose an implementation based on each project.
> I never have to do that with Java.
That's incorrect. With Java, you always have considerable periods of
time in which you have to worry about the concrete version number of
Java. It happened during the transition from 1.0 to 1.1, from 1.2 to
1.3, from 1.3 to 1.4, and now from 1.4 to Java 5. Only the transition
from 1.1 to 1.2 was relatively smooth because they didn't add new
language features, etc.
Just recently I tried to compile some large Java application that was
developed for 1.4 but didn't compile anymore because some of the new
keywords in Java 5 were used as variable names. That project is unlikely
to be updated by the original developers, so there are definitely
similar situations in the Java world like in the Lisp world. The only
real difference is that there are lots more Java hackers than Lisp
hackers out there which helps in some cases, but not when you are
concerned about a niche Java library or Java application.
And I haven't yet talked about the differences between the various
micro, standard and enterprise editions with their respective sub- and
de-facto standards...
> The benefit of never need to change
> the lisp implementation is that I can be proficient in it. No
> implementation is going to be perfect. So instead of learning to work
> around only one implementation's bug, with multiple implementation I
> have to be aware of that implementation's different behavior and
> workaround. That's not nice.
...but doable. Many people do it.
> Most of the time, nobody has such problem when they are working with
> Ruby or Java. They either have the feature or they don't. And if they
> don't, the chances are that a feature added by 3 people working on one
> implementation will be more robust/well-designed/well-maintained than a
> feature added by 3 people, each works on separate lisp implementation.
Again incorrect. The problem with those languages is that if they don't
have a particular feature, they either announce it to have it in the
future which stifles your progress and/or forces you to use ugly
workarounds in the meantime, or they don't announce it which definitely
forces you to use ugly workarounds. Those languages don't offer enough
abstraction facilities to make your workarounds look like first-class
citizens of the language, which is an important feature because it makes
programming less error-prone. (However, Ruby is probably better in this
regard than Java.)
> And often, the effort is even more wasted. Some people saw a library
> that do what they like but not on the supported implementation. But the
> library may be to hard to port, too much must be done to make it work
> on their platform. So instead of porting, they decide to write a new
> library, only little variant from the original library, only with less
> feature, rarely maintained, but it works for their cases.
[...]
> If someone writes a library that works on Java or Ruby, it works for
> others that download them, that's because they all are on the same
> implementation.
In theory yes. In reality, there's also a lot of redundancy - many
libraries doing almost the same - for those languages.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Peter Herth
> Regarding availability of implementations, the problem is not that
> there are few implementation. But that there are few free
> implementations that always works. (I think most people are not going
> to pay for ACL or LispWorks while they can download Ruby, Python or
> Java for free and can also use it for commercial)
>
> Choices are: CLISP, CMUCL and SBCL.
>
> If I need to work on Windows then I have to choose CLISP.
> If I need to use multithread then I need to use SBCL, and only work on
> x86 Linux.
> If I need to use FFI-Callback, I need to sue CMUCL or CLISP, SBCL
> callback only work on x86 Linux.
> If I need to use Unicode then I have to choose SBCL or CLISP.
>
> Can you tell me what should I choose if I need multithread Lisp on
> Windows?
You can always name a feature set that is not provided by any
implementation - for Lisp as easy as for Java or Python. The only
difference is, that individual Lisp implementations *may* have that
featureset, even if it isn't standard.
>
> Please don't tell me to choose an implementation based on each project.
> I never have to do that with Java. The benefit of never need to change
> the lisp implementation is that I can be proficient in it. No
> implementation is going to be perfect. So instead of learning to work
> around only one implementation's bug, with multiple implementation I
> have to be aware of that implementation's different behavior and
> workaround. That's not nice.
>
> Most of the time, nobody has such problem when they are working with
> Ruby or Java. They either have the feature or they don't. And if they
> don't, the chances are that a feature added by 3 people working on one
> implementation will be more robust/well-designed/well-maintained than a
> feature added by 3 people, each works on separate lisp implementation.
>
What you underestimate is, that there is a very explicit and well
documentated Ansi Common Lisp standard. So this lays a clear set
of features which is highly portable across the different Lisp
implementations. If you look at the Ltk source, there are about 20
lines of code which go beyond Ansi Common Lisp so it is currently
running on every Common Lisp I know of.
But changing the Lisp implementation dependant on the project is
also a non-issue in my experience. It is even so much a non-issue
that depending on the phase of the project I tend to use different
Lisps. So for example for development I use the Lisp that has the
faster compiler, but deploy on another Lisp without any problems.
> -----
>
> Regarding the availability of libraries, most open-source library comes
> from the need of the original author to solve their problem at hands.
>
> If I were the author of some good library, how much effort am I going
> to spend to make sure that my libraries works on CLISP or CMUCL when my
> environment was Lispworks with Multithread and Unicode support?
> Someone might like my library and helping porting parts to CMUCL,
> another guy to CLISP. But isn't that waste of effort? If they don't
> have to do that, they can put effort on adding features to the library
> instead.
My experience with Ltk was, that I added support for 3 Lisp
implementations I had available - that was no big effort as due to the
standardisation of Common Lisp only a few lines had to be changed. Soon
after I published Ltk I got mails with patches to enable Ltk on other
Lisps. And after about 2 months all known Lisps were fully supported.
> And often, the effort is even more wasted. Some people saw a library
> that do what they like but not on the supported implementation. But the
> library may be to hard to port, too much must be done to make it work
> on their platform. So instead of porting, they decide to write a new
> library, only little variant from the original library, only with less
> feature, rarely maintained, but it works for their cases. Just take a
> look at http://www.cliki.net/database. Many of them works only on a
> specific implementation. And to port them all to CFFI would require
> lots of effort. If only lisp define standard FFI interface, all of
> those library would be automatically ported.
Well if a library contains lots of useful stuff, it gets ported. If the
porting is too much work, the library may not have been that useful in
the first place. There is ofcourse one notable exception, that are
libraries which depend heavily on the FFI. But in the last months a lot
of progress was made towards a portable FFI so I expect that problem to
be reduced much in the future.
> If someone writes a library that works on Java or Ruby, it works for
> others that download them, that's because they all are on the same
> implementation. At most, they will be dealing with OS-dependent
> work-around. But those are still less of the issue than both
> implementation dependent and OS dependent issue.
>
>>From what I observes, library that are not much diversed are libraries
> which only do calculation. CL-PPCRE, ITERATE, etc. are portable and
> cool. It draws lots of user.
>
> But very small amount of user goes for something that is specific to
> SBCL, CMUCL, etc. For example, Araneida/UCW doesn't even have Unicode
> and File upload support. How long has Python came out? Lisp is way
> older but yet we don't even have an application server as good as Zope
> yet? Please tell me why.
>
> No software in the world is bug-free, even those made in Lisp. So for
> anyone wanting to get their work done, picking the library that has
> more user base is often safe bet. Having three different library only
> do job of dividing user base.
>
Again, typically there is no more such thing as "three different"
libraries in the Lisp world than with other languages. Even with
single-implementation languages, there are different aproaches to
solving a problem creating several libraries which try to solve the same
thing - and you have to pick from them.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Pascal Bourguignon
> [...]
> And often, the effort is even more wasted. Some people saw a library
> that do what they like but not on the supported implementation. But the
> library may be to hard to port, too much must be done to make it work
> on their platform. So instead of porting, they decide to write a new
> library, only little variant from the original library, only with less
> feature, rarely maintained, but it works for their cases. Just take a
> look at http://www.cliki.net/database. Many of them works only on a
> specific implementation. And to port them all to CFFI would require
> lots of effort. If only lisp define standard FFI interface, all of
> those library would be automatically ported.
All your gripes are well known. But you're not lucky here, for now
there is CFFI. The situation changed recently. You're looking at a
picture 6 month old. Today you don't have any excuse: just write or
port your library on CFFI and it'll work everywheree.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Indentation! -- I will show you how to indent when I indent your skull!"
A.L.
wrote:
>
>"The drawbacks all basically stem from the same problem. Since very
>few people actually use Lisp, we can’t take advantage of the
>tremendous community support the other languages have. There are few
>libraries, few implementations, and little real-world examples of
>building large-scale websites in Lisp. The language itself (ANSI
>Common Lisp) hasn’t changed much since it was standardized, which was
>about 20 years ago.
[...]
>
>I suspect the drawbacks have a lot to do with scaring bigger
>organizations away from Lisp.
Well written.
A.L.
Erik Enge
> How long has Python came out? Lisp is way older but yet we don't
> even have an application server as good as Zope yet? Please tell me why.
Because Zope tries to solve many disjoint problems with one solution
and does so in a largely misguided and generally poorly executed
fashion.
Erik.
ajones
I will agree with that. A while ago (~8 months) I spent a lot of time
looking at zope. I was faced with upgrading a poorly coded (by me no
less) php app, modifying it from tracking software inventory to
handling software + hardware + installations + help tickets + the
kitchen sink. The whole object database concept behind zope seemed like
a useful thing for this, as I had so many different angles from which I
had to approach any individual part of the system.
In the end I just flat out gave up on it though. Zope at times seems
wilfully obtuse, and has lately been one of the convincing factors for
me that object orientation can easily go too far.
RE: the rest of this thread. Lisp has problems. Any language will have
problems, as humans are not perfect and will end up introducing those
imperfections into almost any complicated task we undertake. I think
the real solution here is not to look at "how X does things" as then at
best you end up with whatever problems they may have, but more likely
that plus new ones of your own introduction. Lisp as a language has
survived on its ability to embrace new concepts, integrating them so
fully that they seem they have always been there.
What lisp really needs is to work on being useful. If that means an
automatic package managing downloading system then someone will
eventually write it.
-Adam
Thomas A. Russ
> 2. A solid https / http client library that handles cookies. LWP is a
> gateway drug for perl, and CL doesnt have anything that comes close.
> trivial-http is too trivial. cl-curl is not asdf-installable, due to
> (afaik) the author being dissatisfied with asdf-install as compared to
> clc.
>
> lest I be accused of merely whining, i would be happy to work on these
> issues, given some indication of possible directions, eg.
> #2 may be as straightforward as writing up a 'howto write web scrapers
> using common lisp', which I may do if cl-curl ends up meeting my needs.
> (last time I needed a scraper, I ended up writing it in python after
> little success)
Well, it could also be as simple as using either CL-HTTP or Portable
Aserve, two existing HTTP server libraries that also include client
code.
PortableAserve is asdf-based.
--
Thomas A. Russ, USC/Information Sciences Institute
Pisin Bootvong
Pascal Costanza wrote:
> Pisin Bootvong wrote:
>
> > Please don't tell me to choose an implementation based on each project.
> > I never have to do that with Java.
>
> That's incorrect. With Java, you always have considerable periods of
> time in which you have to worry about the concrete version number of
> Java. It happened during the transition from 1.0 to 1.1, from 1.2 to
> 1.3, from 1.3 to 1.4, and now from 1.4 to Java 5. Only the transition
> from 1.1 to 1.2 was relatively smooth because they didn't add new
> language features, etc.
>
> Just recently I tried to compile some large Java application that was
> developed for 1.4 but didn't compile anymore because some of the new
> keywords in Java 5 were used as variable names. That project is unlikely
> to be updated by the original developers, so there are definitely
> similar situations in the Java world like in the Lisp world. The only
> real difference is that there are lots more Java hackers than Lisp
> hackers out there which helps in some cases, but not when you are
> concerned about a niche Java library or Java application.
>
> And I haven't yet talked about the differences between the various
> micro, standard and enterprise editions with their respective sub- and
> de-facto standards...
>
Response below.
> > The benefit of never need to change
> > the lisp implementation is that I can be proficient in it. No
> > implementation is going to be perfect. So instead of learning to work
> > around only one implementation's bug, with multiple implementation I
> > have to be aware of that implementation's different behavior and
> > workaround. That's not nice.
>
> ...but doable. Many people do it.
>
> > Most of the time, nobody has such problem when they are working with
> > Ruby or Java. They either have the feature or they don't. And if they
> > don't, the chances are that a feature added by 3 people working on one
> > implementation will be more robust/well-designed/well-maintained than a
> > feature added by 3 people, each works on separate lisp implementation.
>
> Again incorrect. The problem with those languages is that if they don't
> have a particular feature, they either announce it to have it in the
> future which stifles your progress and/or forces you to use ugly
> workarounds in the meantime, or they don't announce it which definitely
> forces you to use ugly workarounds. Those languages don't offer enough
> abstraction facilities to make your workarounds look like first-class
> citizens of the language, which is an important feature because it makes
> programming less error-prone. (However, Ruby is probably better in this
> regard than Java.)
>
Right, I should have never brought Java as example. But that is because
it is hard to change how Java works since Sun controls it. So this is
an issue of open/close source language implementation, not that of the
language itself. Ruby is probably better in that it is open source and
runs around more friendly community that useful features will more
likely gets add if there is good reason to it.
Anyway, I'm not talking about the features that require language
semantic changes.
I'm talking about system feature like Threading, Networking; features
that can not be added by simply writing inside the language's world
itself. For example, you cannot create an asdf package that will
provide native thread for CLISP. Such thing can't be written as the
library in the language itself. And it didn't change the syntax of the
language. It requires developer to works on the internal. And since
these are internal detail, it is hardly shared between implementation.
It is already hard for any language community to gain user base. It is
even harder to gain the developer who is also a good C/C++ programmer
who knows internal of the implementation. That's why I said it's pity
that these hard to get resource must be split out.
For example, if SBCL haven't been forked off CMUCL:
- CMUCL in a sense probably got Unicode support.
- The separated effort of porting CMUCL and SBCL to Win32 will be
unified and that will probably speeds up the development since people
who works in group probably can share knowledge.
:: On the other hand SBCL has reason to forked. So, may be, if SBCL
hadn't forked, we would still just get this current CMUCL anyway.
That's not technical issue but more of the political issue, me think.
> > And often, the effort is even more wasted. Some people saw a library
> > that do what they like but not on the supported implementation. But the
> > library may be to hard to port, too much must be done to make it work
> > on their platform. So instead of porting, they decide to write a new
> > library, only little variant from the original library, only with less
> > feature, rarely maintained, but it works for their cases.
> [...]
>
> > If someone writes a library that works on Java or Ruby, it works for
> > others that download them, that's because they all are on the same
> > implementation.
>
> In theory yes. In reality, there's also a lot of redundancy - many
> libraries doing almost the same - for those languages.
>
This is also true for Lisp.
There is many factor to redundant library such as, community size,
implmentation variant, different main goal (footprint size/
performance/feature full), etc.
Lisp doesn't yet suffer the first factor :)
And it's always good to reduce the one factor.
Pascal Costanza
> Right, I should have never brought Java as example. But that is because
> it is hard to change how Java works since Sun controls it. So this is
> an issue of open/close source language implementation, not that of the
> language itself. Ruby is probably better in that it is open source and
> runs around more friendly community that useful features will more
> likely gets add if there is good reason to it.
There are also attempts to extend Java in an open-source style. See
AspectJ for one of the more successful examples. Social issues can
always be solved in one way or another.
The good thing about Lisp is that you don't have to wait for someone
else to include a new language feature, you can just do it yourself. The
other perspective is always important: if you think that a certain
language feature is useful, you don't have to convince and/or force
other people to think so as well. That latter part is very important to
understand, IMHO (and it took me a while to really grasp it).
(Of course, you can also write a compiler/interpreter for your very own
language, but that's a lot more work than adding macro definitions on
top of an existing, alread mature language.)
> Anyway, I'm not talking about the features that require language
> semantic changes.
> I'm talking about system feature like Threading, Networking; features
> that can not be added by simply writing inside the language's world
> itself. For example, you cannot create an asdf package that will
> provide native thread for CLISP. Such thing can't be written as the
> library in the language itself.
Yet Paul Graham used clisp to implement Viaweb, and they found a way to
make this work by running multiple Lisp sessions at the same time. See
http://www.paulgraham.com/vwfaq.html
It seems that if you have the will to achieve something like this, you
will find a way to make it work.
> And it didn't change the syntax of the
> language. It requires developer to works on the internal. And since
> these are internal detail, it is hardly shared between implementation.
Right. The clisp guys seem to be working on multi-threading support. See
http://clisp.cons.org/wanted.html
> It is already hard for any language community to gain user base. It is
> even harder to gain the developer who is also a good C/C++ programmer
> who knows internal of the implementation. That's why I said it's pity
> that these hard to get resource must be split out.
>
> For example, if SBCL haven't been forked off CMUCL:
> - CMUCL in a sense probably got Unicode support.
> - The separated effort of porting CMUCL and SBCL to Win32 will be
> unified and that will probably speeds up the development since people
> who works in group probably can share knowledge.
> :: On the other hand SBCL has reason to forked. So, may be, if SBCL
> hadn't forked, we would still just get this current CMUCL anyway.
> That's not technical issue but more of the political issue, me think.
A different perspective is this: The fact that multiple Common Lisp
implementations exist creates a healthy competition between those
different implementations. This has, among other things, the following
effects:
- The ANSI Common Lisp specification defines what is guaranteed behavior
and what is left as implementation-specific details. By porting your own
projects across several Common Lisp implementations, there is a tendency
that your software becomes more robust. That's because you will quickly
notice accidental implementation-specific dependencies. The various
Common Lisp implementations indeed vary a lot in how they are
implemented, so it is likely that such issues turn up.
- This is even more so the case for semi-standardized libraries, like
the CLOS MOP.
- You have some more power when you talk to your vendor about problems
in an implementation. For example, you can give them some example code
and then tell them that that example code works in those other
implementations. This seems to create a healthy pressure on the vendors
to indeed fix bugs. (They can't use the Microsoft way to declare bugs as
features, so to speak. ;)
- Ultimately, you can switch implementations to take advantage of
specific characteristics. For example, CMUCL and SBCL have very good
compilers, but on the other hand, their compilers are very slow - they
have to perform quite some analysis to produce good code. Clisp has a
very minimal compilation phase - it just produces bytecode that is then
interpreted. While for purely compiled programs that can be a
disadvantage, it can also become an advantage when your program relies
on runtime compilation. For example, see the discussion on performance
issues at http://www.livejournal.com/users/fare/96097.html
For single-implementation languages, you don't have that kind of choice
(apart from completely switching the language that you use).
So while I agree that the "fragmentation" of a community has its
downsides, there are definitely also advantages!
Pascal Costanza
> The other perspective is always important:
The other perspective is also important: ...
rydis
> For example, if SBCL haven't been forked off CMUCL:
> - CMUCL in a sense probably got Unicode support.
There is a branch och CMUCL with unicode support. It's a bit dated,
now; it doesn't seem that people care about unicode enough to port it
forward to current CMUCL.
',mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Adam Connor
wrote:
>A different perspective is this: The fact that multiple Common Lisp
>implementations exist creates a healthy competition between those
>different implementations.
Well, from the outside looking in, I see a bunch of connected
communities, but no core, relative to efforts like Ruby and Perl.
Maybe I'm wrong; it's just an impression. But there are other factors:
the lack of "standard" networking libraries and the like, the fact
that free Lisps depend on Emacs as an editor and Emacs is _not_ the
default editor of many developers, the unfortunate fact that Lisp
syntax is so obviously different. All of these things make it harder
to "sell" Lisp. (And it requires a lot of selling in most contexts.)
Lisp already has a reputation for being esoteric, old, and
unsuccessful. Having spent some time learning it, I think it's also
fantastic. I'm a sucker for elegance, and Lisp has that (as does
Scheme). But, when folks use it to develop a site yet seem to have
reservations about its viability, that concerns me.
Bruce Tate has a book out called "Beyond Java" that suggests Java may
have hit its apex and that it is time to look at alternatives. It's
generating a fair amount of conversation in the Java community. Tate
is clearly impressed by Ruby, but he dismisses Lisp's chances based on
its "history and reputation to overcome". I think it would be a
tragedy if Lisp missed its chance and PHP over the world, and a lesser
tragedy if Ruby did, but... perhaps another question would be: why did
Rails show up for Ruby and not for Lisp? Is the Lisp community as
vibrant as that of Ruby? Is it ready to become popular?
Having read this newsgroup for a while, off and on, I fear I will be
labelled as a troll. I'm not trolling, and I do like Lisp, but I'm not
sold on the Lisp community in the way that I am with Ruby or even
Java. I wish Paul Graham would finish Arc, not because it's
necessarily better (I have no idea), but because he's the only
individual in the Lisp community who seems to be able to articulate
its advantages in a way that attracts converts. Lisp needs libraries,
and facilities, and while it is a chicken-and-egg situation,
ultimately that requires converts.
--
adamnospamaustin.rr.com
s/nospam/c\./
Adam Connor
>What lisp really needs is to work on being useful. If that means an
>automatic package managing downloading system then someone will
>eventually write it.
The problem with "eventually" is that there are windows of
opportunity. Much of the last decade was spent in a haze of all things
Java, where it was very hard to get other technologies considered. I
think that's opening up again, but if something else becomes popular
instead of Lisp, the network effect will make it the dominant
solution.
--
adamnospamaustin.rr.com
s/nospam/c\./
Edi Weitz
> That's why a Lisp on the Java platform would be nice. There
> already is Jatha, a Common Lisp interpreter in Java, but it seems
> to be hard to call Java methods from the Lisp code.
According to the Jatha website it's a "subset" of Common Lisp. No
CLOS, for example.
> If Jatha would make it easier to call any method of the standard
> Java API, I might be tempted to use it for coding
> non-time-critical parts.
Have you looked at ABCL?
<http://armedbear.org/abcl.html>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Adam Connor
wrote:
>On 2 Dec 2005 01:34:13 GMT, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> That's why a Lisp on the Java platform would be nice. There
>> already is Jatha, a Common Lisp interpreter in Java, but it seems
>> to be hard to call Java methods from the Lisp code.
>
>According to the Jatha website it's a "subset" of Common Lisp. No
>CLOS, for example.
>
>> If Jatha would make it easier to call any method of the standard
>> Java API, I might be tempted to use it for coding
>> non-time-critical parts.
>
>Have you looked at ABCL?
>
> <http://armedbear.org/abcl.html>
>
I have. While impressive, I don't think it's to the point where many
organizations would be comfortable with it, yet.
While Java libraries are useful, I don't think it really solves the
problem, any more than Wine solved the problem of gaming on Linux.
Calling Java libraries from Lisp is never going to feel particularly
natural, and leads to questions of "why not just use Java?" If any
scripting language will succeed on that basis, it will be one much
closer to Java's default syntax and assumptions.
--
adamnospamaustin.rr.com
s/nospam/c\./
Jack Unrue
>
> Well, from the outside looking in, I see a bunch of connected
> communities, but no core, relative to efforts like Ruby and Perl.
> Maybe I'm wrong; it's just an impression. But there are other factors:
> the lack of "standard" networking libraries and the like, the fact
> that free Lisps depend on Emacs as an editor and Emacs is _not_ the
> default editor of many developers, the unfortunate fact that Lisp
> syntax is so obviously different. All of these things make it harder
> to "sell" Lisp. (And it requires a lot of selling in most contexts.)
Regarding the editor issue...perhaps a sufficiently-motivated person
(or group of people) could assemble a database of tips-and-tricks
for configuring various editors to enable Lisp-friendly behavior.
The Emacs crowd can point out how these customizations pale in
comparison to the real thing, but so what? Maybe some innovation
can happen by virtue of thinking about Lisp editing from a fresh
point of view?
You have inspired me to work on some macros and syntax definitions
for TextPad (www.textpad.com) and I will report back :-)
--
Jack
Jack Unrue
>
> The problem with "eventually" is that there are windows of
> opportunity. Much of the last decade was spent in a haze of all things
> Java, where it was very hard to get other technologies considered. I
> think that's opening up again, but if something else becomes popular
> instead of Lisp, the network effect will make it the dominant
> solution.
Here's an idea. There are some major initiatives underway right now
to define SOA infrastructure. This is an area that has the attention
of a lot of people in the corporate world in a major way.
Yes, there is usually an underlying assumption that the foundation for
this stuff will be some combination of the usual suspects (Java/C#/PHP
as well as XML-based vocabularies). But one of the key points of SOA
is that service and client are decoupled via language-neutral mechanisms.
Which is a long way of saying that if somebody wants to hook into a
network effect that is strong and growing stronger, get some Lisp
implementations of these initiatives completed.
--
Jack Unrue
Michael Tuchman
Copernican model has elegance, but it isn't as useful for predicting
plaentary motion for the type of problems we're trying to solve.
It will be a hard sell. I guess 500 years go by and it's still the same
old thing. Different is wrong.
Kenny Tilton
Both MCL and AllegroCL offer non-emacs editors which are emacs
semi-workalikes, using the same keychords to do (as ubset of) the same
things. So they do not have the whizbang features of emacs, but they are
great for editing Lisp. I only know a useful handful, but I think
keychords are the way to go.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Bill Atkins
widespread again. Paul Graham's essays and Peter Seibel's book are
drawing a lot of attention to Lisp. More and more cool Lisp projects
have been cropping up in the past couple of years (SBCL, SLIME, UCW,
AllegroCache, reddit, the original Yahoo! Store). We are still a
minority for sure, but the fact that Lisp is returning from the dead
is, as others have mentioned, truly remarkable. No other language has
lasted as long as Lisp has; no other language has fallen almost
completely from favor and then risen again. There is something truly
awesome about Lisp, and I think more and more people are discovering
this.
If you think I'm being overly optimistic, consider the progression of
dominant languages that has taken place since the inception of computer
programming. Assembly language begat C begat C++ begat Java
begat......? Slowly but surely, the computing world is catching up to
what Lisp had 40 years ago. The computing industry wants more
powerful, more high-level languages and it is slowly but surely
choosing more high-level, more flexible languages. Although Java is
still miles and miles from Lisp, it has proven to the industry that
garbage collection and a stable runtime environment (i.e. no segfaults,
etc.) are valuable. Ruby is gaining more and more attention these
days, further proof that the industry is approaching Lisp - among the
languages I've seen, Ruby is the closest I've seen to the Lisp family
(though it's still plenty far away). Ruby programmers are taking
advantage of Ruby's metaprogramming capabilities - this is the basis of
Rails' popularity. It is only a matter of time before Lisp's killer
app (Lisp on Lines? AllegroCache? UCW?) brings it the respect and
popularity it really ought to have.
We Await Silent Lisp's Empire.
Bill
Jack Unrue
That's cool.
I think Adam's point was that Lisp editing will have to be, for some
people, a feature that integrates into their editor of choice rather
than something that tries to act like Emacs. E.g., in TextPad, I
expect the Find function to be invoked by F5 not Ctrl-S
But as you say, there is a market for editors that have an Emacs
emulation mode. LispWorks does that, too.
--
Jack Unrue
Karl A. Krueger
> The most important feature of Arc seems to be its author and
> his famousness. The developement speed might be comparable to
> Perl 6? I.e., from the outside for years nothing seems to
> happen.
Perl 6's "nothing" is somewhat more than Arc's, since you can download
and use a Perl 6 environment: pugs. Yes, you need a *very* recent
Haskell compiler (ghc) to build it.
--
Karl A. Krueger <kkru...@example.edu> { s/example/whoi/ }
Pascal Costanza
Your statement is already a much milder prediction about how bad the
future is for Lisp than what the typical doomsayers said a few years
ago. You can never know what's going to happen in the future.
Both Java and XML are going to collapse under their own weight, but
noone seems to have a good alternative answer to the problems those
technologies are supposed to solve yet. And that's a chance for
something new to arise.
To me, it just seems that those languages are trying to reinvent the
wheel over and over again. By exchanging superficial arguments about
what kinds of syntaxes are more "natural" than others, people are
forgetting that this forces programmers to repeatedly make decisions
about whether to encode something in a data representation language
(XML, etc.) or in a programming language (Java, etc.). This leads to
gaps between those two worlds that must be crossed in some ways, a
tendency for data representations to become subsets of full programming
languages, and a tendency for turning programs into interpreted systems
(because the main program has to read and interpret XML files instead of
having those parts being written in real and compiled programming
languages) which is worse than any scripting language could be - for
example, it's likely that you not only lose static typing but that you
don't have any typechecks at all.
The equivalence of data and programs is the fundamental reason why
software works in the first place. It's a weird idea that only a
restricted part of a computer system (the OS) should be allowed to take
advantage of that equivalence, and it's even weirder that people think
that that equivalence can be shielded from "average" programmers. Due to
Turing equivalence, it's clear that you can just write an interpreter
for a language that treats data as programs in any language, and that's
exactly what programmers seem to be doing everywhere, either consciously
or (probably rather) subconsciously.
To me, these are clear signs that there is a movement towards languages
that don't make the distinction between programs and data in the first
place. And, as Paul Graham says, as soon as you blur that distinction in
a concrete language, you have a Lisp dialect anyway since Lisp is not so
much a language but more a design principle.
It's unclear whether Common Lisp or Scheme will be the languages that
will finally have become the "ultimate" languages that the mainstream
will have agreed on to be the best representatives of this notion of
equivalence of data and programs. But on the other hand, it would be
stupid idea to throw those technologies away because they are the
products of decades of experience with that notion.
Ulrich Hobelmann
keystrokes too much, including me), and most of all they don't want the
whole kitchen sink, but just a small editor that has great Lisp support.
Maybe some are looking for an Eclipse plugin (there is one for Scheme
at least), but I'd consider that far too bloated as well.
Adam Connor wrote:
> Lisp already has a reputation for being esoteric, old, and
> unsuccessful. Having spent some time learning it, I think it's also
> fantastic. I'm a sucker for elegance, and Lisp has that (as does
> Scheme). But, when folks use it to develop a site yet seem to have
> reservations about its viability, that concerns me.
Esoteric and maybe baroque. Many more newbies flock to Scheme for that
reason, and I did for a while. Lisp's age and sometimes non-elegance is
a major marketing setback.
> Bruce Tate has a book out called "Beyond Java" that suggests Java may
> have hit its apex and that it is time to look at alternatives. It's
> generating a fair amount of conversation in the Java community. Tate
> is clearly impressed by Ruby, but he dismisses Lisp's chances based on
> its "history and reputation to overcome". I think it would be a
> tragedy if Lisp missed its chance and PHP over the world, and a lesser
> tragedy if Ruby did, but... perhaps another question would be: why did
> Rails show up for Ruby and not for Lisp? Is the Lisp community as
> vibrant as that of Ruby? Is it ready to become popular?
A friend of mine read Touretsky, didn't really like Lisp's syntax, and
is now hooked on Ruby. Oh well. I tried suggesting he reads PCL but he
just said no.
> Having read this newsgroup for a while, off and on, I fear I will be
> labelled as a troll. I'm not trolling, and I do like Lisp, but I'm not
> sold on the Lisp community in the way that I am with Ruby or even
> Java.
It's a good community, but different from most other communities. I
think the majority here are practising self-employeds or industrial
users in general. The average age is probably much higher than for
other languages that attract basically all the young open-source geeks.
> I wish Paul Graham would finish Arc, not because it's
> necessarily better (I have no idea), but because he's the only
> individual in the Lisp community who seems to be able to articulate
> its advantages in a way that attracts converts. Lisp needs libraries,
> and facilities, and while it is a chicken-and-egg situation,
> ultimately that requires converts.
I dare not offer a solution, and what a solution IS is probably
different for everybody. Most Lispers seem very happy with the language
as it is, while others would like a reformed Lisp that might sell better
to newbies. There is room for both IMHO, and maybe Arc is such a
reformed Lisp.
--
The road to hell is paved with good intentions.
Pascal Costanza
> Ad Emacs: I think many people don't want to learn it (and don't like the
> keystrokes too much, including me), and most of all they don't want the
> whole kitchen sink, but just a small editor that has great Lisp support.
> Maybe some are looking for an Eclipse plugin (there is one for Scheme
> at least), but I'd consider that far too bloated as well.
When I started to dive into Lisp a few years ago, I tried to avoid Emacs
because I didn't want to learn two "big" new things at the same time.
Instead, I have opted for MCL - which is a derivative of Emacs, but it
also supports the typical Macintosh keystrokes and mouse gestures.
Currently, my main development environment is LispWorks for mostly the
same reasons. (It would be cool if the LispWorks environment would also
support other CL implementations because I have to switch between
several, but nevertheless...)
Nowadays, things seem to be much better: Aquamacs gives you an
(original) Emacs but with lots of modifications that turn it into an
application that makes it feel much more like a regular Mac application,
including again all the standard keystrokes and mouse gestures. So
probably nowadays, the choice would have been much easier. I don't think
that Emacs is a major stumbling block anymore.
Of course, this is a Mac perspective, I don't know whether something
comparable exists on the Windows platform. (But who cares about Windows
anyway... ;)
Arthur Lemmens
> (But who cares about Windows anyway... ;)
That's a FAQ. I think Edi answered this recently: many professional
Lisp programmers with real-world customers care about Windows.
Espen Vestre
> Nowadays, things seem to be much better: Aquamacs gives you an
> (original) Emacs but with lots of modifications that turn it into an
> application that makes it feel much more like a regular Mac
> application, including again all the standard keystrokes and mouse
> gestures. So probably nowadays, the choice would have been much
> easier. I don't think that Emacs is a major stumbling block anymore.
Hmm, I have tried a few of the macified emacsen on my PowerBook, but
ended up with the X11 version since they all had their quirks and
tended to look ugly.
However, for development on the PB, I used MCL with its fantastic FRED
editor for years, and now I'm happy as a clam with the LW Environment,
so I use Emacs only for misc. editing and gnus (this is written in
gnus on my PB, but from my linux workstation at work - another reason
why I like to use the X11 version of emacs on my mac).
--
(espen)
Peter Herth
Lisp IDEs there are plenty of beginner-friendly environments for Lisp
coding available. But I have also to add some fundamental comments to
the editor part of the discussion:
- Lisp isn't the only language which requires editor-support for
reasonable working, just look at Python. With its indentation rules,
coding Python without an aware editor is really painfull too.
- As any craftsman should know: if you want to do real work, learn your
tools! This should not be a justification for user-unfriendlyness, but
one needs to point out, that the more powerfull a tool gets, the more
learning it probably requires.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Marcin 'Qrczak' Kowalczyk
> - Lisp isn't the only language which requires editor-support for
> reasonable working, just look at Python. With its indentation rules,
> coding Python without an aware editor is really painfull too.
It's not. It's much easier to type Python without a Python-aware
editor than to type Lisp without a Lisp-aware editor.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Ulrich Hobelmann
> Peter Herth <p.h...@t-online.de> writes:
>
>> - Lisp isn't the only language which requires editor-support for
>> reasonable working, just look at Python. With its indentation rules,
>> coding Python without an aware editor is really painfull too.
>
> It's not. It's much easier to type Python without a Python-aware
> editor than to type Lisp without a Lisp-aware editor.
>
Well, I suppose in Python you can simply TAB everything, as I do in C
and Java.
I've also done Scheme with vi in the past and it works, but that was
more painful than necessary (I learned a bit Emacs since).
A.L.
wrote:
>I think we're getting closer and closer to the time when Lisp becomes
>widespread again.
Good joke.
A.L.
Matthias
> perhaps another question would be: why did Rails show up for Ruby
> and not for Lisp?
I've asked myself this question, too.
It might be a library/coherence thing: If you did Rails in a Common
Lisp, making it support the different implementations would be
annoying. So it probably would support only few implementations, thus
limiting its potential audience.
The second thing is that Rails is _really_ easy to set up, even for
someone who has never touched Ruby before. In contrast, making the
package system work under CL is nothing for a newbie. So, while
people can easily take a quick first look into Ruby when they hear
about Rails, the same would be more difficult with CL-based Rails.
A third reason might be that selling Ruby is easier than selling CL.
M.
Luke J Crook
> "I don’t regret writing reddit in Lisp at all. It’s a particularly
> good language for developing applications without a solid plan of
> where you’re going. Lisp never gets in the programmer’s way. However,
> sometimes (oftentimes, more like it) the environment does (again, lack
> of a strong community). We may rewrite reddit in something else as we
> bring on more programmers, but Lisp has certainly served as well up
> until this point."
"Yes, Lisp is good for prototyping but as soon as you want to get
serious then your project is going to have to be rewritten in C++/Java".
Things were going well up until his last statement. HMS Lisp scuttled.
-Luke Crook
jayessay
Nah, not nearly as good as as --> Nutcase A.L.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Nicolas Neuss
> - Ultimately, you can switch implementations to take advantage of
> specific characteristics. For example, CMUCL and SBCL have very good
> compilers, but on the other hand, their compilers are very slow - they
> have to perform quite some analysis to produce good code.
However, there are also quirks which should not be necessary (like
quadratic compilation times on very simple but lengthy code, see the link
below). Unfortunately, I am not sufficiently expert to correct these
deficiencies (or maybe the problem simply does not hurt me enough). And it
seems as if the compiler is fast enough for most other users.
Nicolas.
P.S.: http://permalink.gmane.org/gmane.lisp.cmucl.general/4527
jayessay
First, question I have is: why do you care? Second would be, does it
even make sense for Lisp to be "popular"?
It could be the problem is with the term "popular". For me "popular"
means, or at the very least connotes, "average", as within, say, 1
sigma of the middle of a bell curve. So, in this context, that would
indicate that to be "popular" means to be used by the current
"average" programmers - programmers who would be placed within 1 sigma
say of average ability. (This is admittedly a bit fuzzy, as you would
have to come up with a reasonable metric(s), but I think most people
here get the idea.)
What I've seen in practice(1) from average programmers and from
working with them leads me to believe that most of them simply do not
have the skills nor inclination to understand the ideas behind Lisp
which make it so potent when mastered. Think about it - the average
programmer even has trouble with recursion. This, in turn, pretty
much guarantees that most of them would not master Lisp, and therefore
never really get beyond programming Java/C/C++/Python/... in Lisp.
While that is not something that would do Lisp (or its "popularity")
any good, and would in fact most likely harm it, the more likely
outcome is that Lisp just wouldn't be used by such programmers at all.
This implies that it would never be "popular" given the current state
(and numbers) of programmers. Python (or GVR) seems to specifically
recognize this "problem of the current average programmer", and is
specifically tailored to "account for it". Thereby making it much
more likely to be "popular".
> tragedy if Ruby did, but... perhaps another question would be: why
> did Rails show up for Ruby and not for Lisp?
That's Drew Crampsie's Lisp on Lines, though it may not yet be up to
your expectations of packaging.
> Is the Lisp community as vibrant as that of Ruby?
Who knows? What does "vibrant" mean?
> Is it ready to become popular?
As per above, this probably doesn't even make sense.
> Having read this newsgroup for a while, off and on, I fear I will be
> labelled as a troll. I'm not trolling, and I do like Lisp, but I'm
> not sold on the Lisp community in the way that I am with Ruby or
> even Java.
Fine, so why are you wasting time and effort here? Why not just go
use Ruby or Java? Just curious...
> Lisp needs libraries, and facilities, and while it is a
> chicken-and-egg situation, ultimately that requires converts.
I understand the basic idea you are trying to express here, but I'm
not sure this is the basic problem. For one thing, with CFFI and
Verazzano now, just use the libs that are there. Getting the
functionality of existing libs into your "harness", will be a drop in
the bucket of the total effort of any project that couldn't be done by
even average programmers in their sleep with PHP or Python. OTOH, if
the project isn't any more than that sort of thing, and you don't
already know how to use Lisp to get it done anyway, why not just use
those "average" oriented languages? Or even Java?
Another thing is that the commercial versions of CL already have all
these "libs" people talk about ready for the using. Just buy the best
one for your needs and get on with it. If a few hundred to a couple
thousand is "a lot of $$" for your project, it is most likely not much
of a project anyway, and so you can just use your PHP/Ruby/Java and
get on with it.
One "wildcard" in all of this, of course, is management, if you are
"working for the man". The key thing to understand here is that
"average" is what management _wants_. There are many reasons for this
- some of which even make sense given the primary goals of management.
/Jon
1. Admittedly, almost by definition I (as any other individual) have a
limited window into the set of average programmers, but if it is
reasonably random (may not be) then the observations here could be
important - apropos the topic anyway.
MSCHAEF.COM
Adam Connor <u...@nospam.com> wrote:
...
>Well, from the outside looking in, I see a bunch of connected
>communities, but no core, relative to efforts like Ruby and Perl.
<my_two_cents>
I think that's innate to Lisp, and its biggest advantage.
Ruby and Perl are specific implementations.
'Lisp' is really a vaguely defined group of highly customizable languages
that have been at the forefront of langauge design for 45 years. It
attracts people that like to think about language design and implement
those designs. (That's why everybody else has been 'catching up', and will
continue to do so.) If there is no canonical implementation to rally
around, it's because if there was just one implementation, the community
would have lost its defining characteristic.
That said, periodic standards are probably a good thing, to the extent
they make it more possible to use a specific language for 'real work'.
They are the 'stable branches' of a seething community of ideas. In that
sense, from my highly outsider's point of view, the ball seems to have
been dropped somewhat. Unless I'm missing something, there is no process
in place to revise ANSI Common Lisp. Maybe you could argue that it doesn't
need to be revised, and all necessary improvements should be provided as
libraries, but that seems like great hubris to me. (Personally I'd like
to see standards for threading, unicode, better binary I/O...).
The Scheme standards process looks to be in better shape, now that they've
started working on R6RS.
</my_two_cents>
I certainly don't mean to belittle the huge contributions of all the
talented folks who have contributed to 'Lisp'. I have a great deal of
respect for what they've all done.
-Mike
--
http://www.mschaef.com
Stefan Scholl
> the lack of "standard" networking libraries and the like, the fact
> that free Lisps depend on Emacs as an editor and Emacs is _not_ the
> default editor of many developers, the unfortunate fact that Lisp
> syntax is so obviously different. All of these things make it harder
> to "sell" Lisp. (And it requires a lot of selling in most contexts.)
And yet many programmers find the time to complain about this in
comp.lang.lisp :-)
--
Web: http://www.no-spoon.de/ -*- IRC: stesch @ freenode
Stefan Scholl
> why did
> Rails show up for Ruby and not for Lisp?
Rails isn't loved by everyone - even in the Ruby community. There
are other frameworks and libraries for the same task. It's just
marketing.
And hacking SQL as a base for your application can't be the last
word.
Perhaps that's the reason there's no Rails for Lisp. Lisp
programmeres tend to describe the whole problem with their own
language and don't like to mix with other languages like XML, HTML,
SQL, etc.
There are libraries and tools to produce JavaScript, CSS, and HTML
out of s-expressions.
Ulrich Hobelmann
> More likely: "HMS Reddit scuttled". [How many times have you heard of
> things that started life in Lisp, worked well, got rewritten into some
> other language (esp. C++) and /not/ failed miserably?]
Hm, don't know, aren't Yahoo's stores still doing fine?
(I've never seen or used them, but Paul Graham said they are good :D)
--
Majority, n.: That quality that distinguishes a crime from a law.
Ambrose Bierce, The Devil's Dictionary
Pascal Bourguignon
> What I've seen in practice(1) from average programmers and from
> working with them leads me to believe that most of them simply do not
> have the skills nor inclination to understand the ideas behind Lisp
> which make it so potent when mastered. Think about it - the average
> programmer even has trouble with recursion. This, in turn, pretty
> much guarantees that most of them would not master Lisp, and therefore
> never really get beyond programming Java/C/C++/Python/... in Lisp.
>
> While that is not something that would do Lisp (or its "popularity")
> any good, and would in fact most likely harm it, the more likely
> outcome is that Lisp just wouldn't be used by such programmers at all.
> This implies that it would never be "popular" given the current state
> (and numbers) of programmers. Python (or GVR) seems to specifically
> recognize this "problem of the current average programmer", and is
> specifically tailored to "account for it". Thereby making it much
> more likely to be "popular".
Ok, let's rebrand Lisp: the programming language for the elite programmers,
and forget about popularity.
I don't understand anyways these people who take decisions based on
what the others do or don't.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Rob Warnock
+---------------
| Peter Herth <p.h...@t-online.de> writes:
| > - Lisp isn't the only language which requires editor-support for
| > reasonable working, just look at Python. With its indentation rules,
| > coding Python without an aware editor is really painfull too.
|
| It's not. It's much easier to type Python without a Python-aware
| editor than to type Lisp without a Lisp-aware editor.
Well, I disagree. I have no trouble at all developing in Lisp
with "vi"[1] (properly-indented Lisp at that!), but I rather
suspect I'd go nuts with Python's significant-whitespace rules
no matter *what* the editor was!
-Rob
[1] And while it's fine for me personally, I doubt that most of you
would consider its basic paren-matching and "operate-on-matching"
[for "operate" = move-to, delete-to, or shift-left/right] to
qualify "vi" as being "Lisp-aware"...
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock
+---------------
| Paul Foley (http://public.xdi.org/=pf) wrote:
| > More likely: "HMS Reddit scuttled". [How many times have you heard of
| > things that started life in Lisp, worked well, got rewritten into some
| > other language (esp. C++) and /not/ failed miserably?]
|
| Hm, don't know, aren't Yahoo's stores still doing fine?
Perhaps, but it's *NOT* still in Lisp!! :-(
About 5 years after Yahoo! bought Viaweb from Graham & Morris
[about 4 years after Graham left] the Lisp code was Greenspun'd
into C++ [see Footnote #1 of <http://paulgraham.com/avg.html>].
-Rob
Ulrich Hobelmann
> About 5 years after Yahoo! bought Viaweb from Graham & Morris
> [about 4 years after Graham left] the Lisp code was Greenspun'd
> into C++ [see Footnote #1 of <http://paulgraham.com/avg.html>].
That far I know. But are[n't] they still doing well despite the rewrite?
Adam Connor
<sp...@mouse-potato.com> wrote:
>I don't understand anyways these people who take decisions based on
>what the others do or don't.
Must be nice. Most employers worry about whether they can get
sufficient developers at an acceptable price. Most developers worry
about convincing their employers, and about maintaining employable
skills.
I've pretty much come to the conclusion that comp.lang.lisp isn't
really very interested in whether Lisp becomes more popular. Lisp
solves your problems well enough as-is.
For many others, the situation is different. Steve Yegge has a bunch
of essays about languages
(http://opal.cabochon.com/~stevey/blog-rants/); his conclusion was
that Ruby is probably the most likely "next big thing". Reluctantly, I
am coming to agree with him. I think Lisp is better in principle (as
is Smalltalk), but in practice the Ruby community makes a better
impression and will probably be the beneficiary of widespread
dissatisfaction with Java.
There's one major fly in that prognostication, which is Ruby's
performance, but it is still a reasonable bet.
Anyhow, maybe in another 10-15 years another window of opportunity
will open...
--
adamnospamaustin.rr.com
s/nospam/c\./
nall...@gmail.com
>and forget about popularity.
>
>I don't understand anyways these people who take decisions based on
>what the others do or don't.
I was an english major in college and became disillusioned pretty
quickly because it seemed like no amount of work or perfection could
surmount the problem of other people's bad taste (or different taste,
whatever). The same can't be said about development, however. There are
tangible, quantifiable characteristics of a more elegant
program/algorithm. Likewise, the person who is able to recognize and
utilize better tools has advantages in things like productivity,
performance, and expressiveness.
One thing I appreciate about the community is that it is composed of
people who, for the most part, not only are smart enough to use it, but
choose to do so because they realize that its better tool than whats
out there.
Degrees of productivity beyond the standard bell curve seems like a
goal more appropriate for lisp. Or, better yet, simply providing the
best environment possible to quickly solve problems and create
beautiful things.
nick
nall...@gmail.com
>sufficient developers at an acceptable price. Most developers worry
>about convincing their employers, and about maintaining employable
>skills.
ah, yes, but where would we be if there weren't people worrying about
how things vould be better?
nick
Pascal Bourguignon
> Anyhow, maybe in another 10-15 years another window of opportunity
> will open...
Good bye! See you in 15 years!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"
Tayssir John Gabbour
> On Sat, 03 Dec 2005 01:29:57 +0100, Pascal Bourguignon
> <sp...@mouse-potato.com> wrote:
> >I don't understand anyways these people who take decisions based on
> >what the others do or don't.
>
> really very interested in whether Lisp becomes more popular. Lisp
> solves your problems well enough as-is.
>
> performance, but it is still a reasonable bet.
>
> Anyhow, maybe in another 10-15 years another window of opportunity
> will open...
> I think it would be a
> tragedy if Lisp missed its chance and PHP over the world, and a lesser
> tragedy if Ruby did, but... perhaps another question would be: why did
> Rails show up for Ruby and not for Lisp? Is the Lisp community as
> vibrant as that of Ruby? Is it ready to become popular?
Please stop doing the typical usenet drama-queen thing. If we on Usenet
don't battle -- nay, FIGHT with spear and battle-axe and fingernails if
we must, we shall fore'er look back on this day and sigh, "We merely
plonked newbies on usenet, instead of grasping greatness."
From this day to the ending of the world,
But we in it shall be remembered-
We few, we happy few, we band of coders;
For he to-day that shares his code with me
Shall be my brother; be he ne'er so vile,
This day shall gentle his condition;
And gentlemen in England now-a-bed
Shall think themselves accurs'd they were not here,
And hold their manhoods cheap whiles any speaks
That fought with us upon Saint Lispin's day.
I have some suspicion that Ruby's success is something any Lisp-using
popularity hag would love:
"You're right: we were not out to win over the Lisp programmers; we
were after the C++ programmers. We managed to drag a lot of them about
halfway to Lisp. Aren't you happy?"
-- Guy Steele, Java spec co-author, 2003
Now we observe the Rubes running around with things like SexpProcessor,
taking ideas from anything they can get their clever hands on... and
"we" are supposed to start infighting as if Ruby were a threat?
"Academics have an interesting view of business: They equate business
with war. A company wins because other companies lose-a classic
misunderstanding of evolution (see my later essay "Money Through
Innovation Reconsidered"). A company keeps everything a secret. A
company tries to spy on other companies. A company cannot trust anyone
not part of themselves. Because of these beliefs, AI companies rarely
made strategic partnerships. A partner, learning of your plans, could
move into your business, couldn't it? That partner could steal your
ideas, right? AI academics didn't have a good idea of how AI
technology would spread to the mainstream. They made the mistake of
assuming the technology was in the mainstream when a company that is
considered mainstream was using it for something."
-- Richard Gabriel, _Patterns of Software_
Java, Python, .NET, Ruby, all the Great Satans... it's always hard to
remember which flavor of the week Lisp needs to lick.
Otherwise Guido bin Matsumuto's gonna git'cha!
> I'm not trolling, and I do like Lisp, but I'm not
> sold on the Lisp community in the way that I am with Ruby or even
> Java.
Yeah, it's depressing not to sit at the table with the cool girls. You
know, the ones everyone hates yet desires their approval.
> I wish Paul Graham would finish Arc, not because it's
> necessarily better (I have no idea), but because he's the only
> individual in the Lisp community who seems to be able to articulate
> its advantages in a way that attracts converts.
Only in the programming world do the cool girls turn out to be
Jehovah's Witnesses.
Tayssir
--
"This melding of code and data is central to all dialects of Lisp, and
is fundamental to the way Microsoft is integrating multiple expression
languages (most notably SQL) in future versions of the Microsoft® .NET
Framework."
-- Don Box, MSDN Magazine, Oct 2005
Peter Herth
> On Sat, 03 Dec 2005 01:29:57 +0100, Pascal Bourguignon
> <sp...@mouse-potato.com> wrote:
>
>>I don't understand anyways these people who take decisions based on
>>what the others do or don't.
>
>
> Must be nice. Most employers worry about whether they can get
> sufficient developers at an acceptable price. Most developers worry
> about convincing their employers, and about maintaining employable
> skills.
This "acceptable price" thingy is somehow funny. I know managers like to
employ "cheap" people, but usually the salaries of a developer are
somehow correlated to the skill levels... So I cannot stop to wonder
what makes people think that hiring cheap software developers is an
extremely clever idea.
> I've pretty much come to the conclusion that comp.lang.lisp isn't
> really very interested in whether Lisp becomes more popular. Lisp
> solves your problems well enough as-is.
>
> For many others, the situation is different. Steve Yegge has a bunch
> of essays about languages
> (http://opal.cabochon.com/~stevey/blog-rants/); his conclusion was
> that Ruby is probably the most likely "next big thing". Reluctantly, I
> am coming to agree with him. I think Lisp is better in principle (as
> is Smalltalk), but in practice the Ruby community makes a better
> impression and will probably be the beneficiary of widespread
> dissatisfaction with Java.
>
> There's one major fly in that prognostication, which is Ruby's
> performance, but it is still a reasonable bet.
>
> Anyhow, maybe in another 10-15 years another window of opportunity
> will open...
Actually the window of opportunity is wide open and the Lisp world *is*
using it. The most interesting piece I took from the last Amsterdam Lisp
meeting was how active the Lisp community is. There are many open source
Lisp projects which are very actively developed - even if they do not
get as much press coverage as some projects in other languages.
Furthermore, business for the Lisp vendors seems to be in an uptake too.
Sure, languages like Python and Ruby got a lot of public attention, but
if you look closely, they are all walking on a path in the direction of
Lisp.
Ulrich Hobelmann
> Adam Connor wrote:
>> On Sat, 03 Dec 2005 01:29:57 +0100, Pascal Bourguignon
>> <sp...@mouse-potato.com> wrote:
>>
>>> I don't understand anyways these people who take decisions based on
>>> what the others do or don't.
>>
>>
>> Must be nice. Most employers worry about whether they can get
>> sufficient developers at an acceptable price. Most developers worry
>> about convincing their employers, and about maintaining employable
>> skills.
>
> This "acceptable price" thingy is somehow funny. I know managers like to
> employ "cheap" people, but usually the salaries of a developer are
> somehow correlated to the skill levels... So I cannot stop to wonder
> what makes people think that hiring cheap software developers is an
> extremely clever idea.
No, the salary of a developer is related to supply and demand. If every
company on earth wants that one coding guru, they'll try to get him with
good offers.
Of course all those companies have one upper limit that they're willing
to pay: the amount of money the developer actually earns them, i.e. her
productivity. That's why most companies (if they know the workers
productivity) will only pay less money for a bad developer.
If a company needs to get a job done, it would be incredibly clever to
get a good Lisp guy and pay him twice the salary, because he might get
the job done more than twice as fast as a Java person would.
Big corps don't know that, but that's basically a competitive advantage
for smaller ones. It depends if you work on a huge code basis with the
customer, and if the customer can only read Java. I'm sure many
(client) companies out there just want results, not actual code, which
is why there are a few Lisp coders.
Peter Herth
> No, the salary of a developer is related to supply and demand. If every
> company on earth wants that one coding guru, they'll try to get him with
> good offers.
>
> Of course all those companies have one upper limit that they're willing
> to pay: the amount of money the developer actually earns them, i.e. her
> productivity. That's why most companies (if they know the workers
> productivity) will only pay less money for a bad developer.
>
> If a company needs to get a job done, it would be incredibly clever to
> get a good Lisp guy and pay him twice the salary, because he might get
> the job done more than twice as fast as a Java person would.
>
> Big corps don't know that, but that's basically a competitive advantage
> for smaller ones. It depends if you work on a huge code basis with the
> customer, and if the customer can only read Java. I'm sure many
> (client) companies out there just want results, not actual code, which
> is why there are a few Lisp coders.
>
Thats exactly what I was expressing - glad you agree :)
Thomas Lindgren
Paul Foley <s...@below.invalid> (http://public.xdi.org/=pf) writes:
> On Fri, 02 Dec 2005 07:02:15 -0800, Luke J Crook wrote:
>
> > [quoted]
> > "Yes, Lisp is good for prototyping but as soon as you want to get
> > serious then your project is going to have to be rewritten in
> > C++/Java".
>
> > Things were going well up until his last statement. HMS Lisp scuttled.
>
> More likely: "HMS Reddit scuttled". [How many times have you heard of
> things that started life in Lisp, worked well, got rewritten into some
> other language (esp. C++) and /not/ failed miserably?]
I would see a C++ or Java rewrite as a big business risk if the
original software is at all complex. A costly distraction at best, and
a life as an also-ran quite likely. And balanced against that risk
... what was the payoff again?
This is the sort of thing you get fired for by Donald Trump.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Asbjørn Bjørnstad
> If a company needs to get a job done, it would be incredibly clever to
> get a good Lisp guy and pay him twice the salary, because he might get
> the job done more than twice as fast as a Java person would.
And fire him when he is done? Being able to do twice as much work
is only valuable if there is twice as much work to do.
> Big corps don't know that, but that's basically a competitive
> advantage for smaller ones. It depends if you work on a huge code
> basis with the customer, and if the customer can only read Java. I'm
> sure many (client) companies out there just want results, not actual
> code, which is why there are a few Lisp coders.
I've never worked as a developer for a big corporation, but have some
years worth of sysadmin work, and my guess is the thinking is somewhat
similar:
I work in a big financial institution, our upper management is very
wary about outages as we are big enough that if we have an outage, it
will be measurable in the financial markets around the world.
So what do you do to prevent outages, do you hire the best admin staff
that money can buy? Nope. Training. And not the technical kind, but in
"processes", you teach your staff to follow procedures and routines
designed to make the staff unlikely to make mistakes. You have a small
engineering group that makes "builds" that the admins later roll out
on the machines. And for the troubleshooting you have a good support
contract from the vendors.
My guess it is the same way in the programming corporations, a small
group of designers and a big group of coders bound by "prosesses"
reducing the importance of their individual skills.
--
-asbjxrn
Ulrich Hobelmann
> My guess it is the same way in the programming corporations, a small
> group of designers and a big group of coders bound by "prosesses"
> reducing the importance of their individual skills.
And you can tell by the results. With the exception of some Mac
software companies I don't know any software vendor that's really good.
Mozilla and Open Office are ok, as in "usable", but I wouldn't pay for
their products.
So your experiences may be the reality of most programmers, but it
doesn't contradict the claim of a company getting a superior edge by
hiring better programmers.
alex...@gmail.com
No. Give us another 50 years.
Robert Strandh
> This "acceptable price" thingy is somehow funny. I know managers like
> to employ "cheap" people, but usually the salaries of a developer are
> somehow correlated to the skill levels... So I cannot stop to wonder
> what makes people think that hiring cheap software developers is an
> extremely clever idea.
I am guessing that, since companies and managers do not know how to
measure, nor even estimate, productivity, they subconsciously assume
as a first-order approximation that the productivity is the same for
everyone. The result is that you should hire the least expensive
one.
--
Robert Strandh
Alan Shutko
> And fire him when he is done? Being able to do twice as much work
> is only valuable if there is twice as much work to do.
In internal development, there's always twice as much work to be done.
--
Alan Shutko <a...@acm.org> - I am the rocks.
Length of an average blink: 0.1 second.
Adam Connor
<tayss...@yahoo.com> wrote:
>Please stop doing the typical usenet drama-queen thing. If we on Usenet
>don't battle -- nay, FIGHT with spear and battle-axe and fingernails if
>we must, we shall fore'er look back on this day and sigh, "We merely
>plonked newbies on usenet, instead of grasping greatness."
Just frustrated and a little discouraged, sorry. I wish you all well,
just feel like I can see the writing on the wall.
--
adamnospamaustin.rr.com
s/nospam/c\./
Adam Connor
wrote:
>For many others, the situation is different. Steve Yegge has a bunch
>of essays about languages
>(http://opal.cabochon.com/~stevey/blog-rants/); his conclusion was
>that Ruby is probably the most likely "next big thing". Reluctantly, I
>am coming to agree with him. I think Lisp is better in principle (as
>is Smalltalk), but in practice the Ruby community makes a better
>impression and will probably be the beneficiary of widespread
>dissatisfaction with Java.
>
>There's one major fly in that prognostication, which is Ruby's
>performance, but it is still a reasonable bet.
Some followup, courtesy today's reddit.com:
Why Ruby is an Acceptable Lisp:
http://randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp
Power vs. Popularity:
http://zifus.blogspot.com/2005/12/power-vs-popularity.html
Why Lisp will never Win:
http://perl.plover.com/yak/12views/samples/notes.html#sl-39
Which is to say, the memes are out there.
--
adamnospamaustin.rr.com
s/nospam/c\./
Wade Humeniuk
to whatever the prevaling opinion of the day is. Not only that
but its healthy. Its healthy in government and democracy and its
healthy in everyday things. Once one accepts one's role, in this case
seeing farther than most that Lisp is a good thing, then one
can move forward. The role of the loyal opposition is so important
that it is required (at least in the Canadian Parlimentary Democrary)
by LAW, Government cannot function without it, debate is mandated.
Some people are viaing for power in the next meritocracy, but
see it for that, not some objective truth. Be the LOYAL opposition,
LOYAL to a higher purpose than one's own standing.
Wade
Tolstoy
http://reddit.com/blog/2005/12/night-of-living-python.html
<quote>
Visiting reddit today, you may notice that things seem a little
different. It's not just your imagination -- as our series of header
icons hinted at, the site has been entirely rewritten in Python during
some marathon coding sessions over the past couple weeks.
Hopefully things won't be too different, but if you notice something
that seems odd or broken, send us a note using the new handy feedback
form and we'll get right on it.
Hopefully our shiny new Python code will make it even easier for us to
add cool new features for your enjoyment. Looks like I'll have to get a
new book...
PS - For all you Lispers, stay tuned for a longer post about why we
rewrote in Python.
</quote>
Pascal Costanza
That's not news, that was already the case for quite some time. Yet Lisp
seems to be growing nonetheless. Let's just wait and see.
The focus here is to get things right, not to get things popular. When
you read those articles a bit more carefully you will notice that they
almost always refer a) to Lisp's lack of popularity and the respective
other language's popularity and b) to what well-known people (Gurus?)
have said about Lisp and about the respective other language.
Most of the people who do use Lisp seem to use it because of strictly
technical advantages. Those never seem to be discussed in such articles.
It would be enlightening to read what technical arguments there are in
favor of Ruby, etc., as compared to Lisp. (Very important: a large
number of users and the resulting infrastructure is not a technical
argument.)
Maybe you think that social issues are more important than technical
ones. Noone keeps you from thinking so, and noone keeps you from
switching. But also noone keeps other people from deciding against
popularity but in favor of technical advantages, because they have a
different set of values in the first place.
Think about it: A lot of people around here have already used Lisp in
times when Lisp's future was a lot darker than it is nowadays. Maybe
they simply have good reasons to do so...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Timofei Shatrov
everyone with this message:
>And then:
>
>http://reddit.com/blog/2005/12/night-of-living-python.html
>
It surely became much slower. Dunno if it's Python related or there was some
increase of popularity.
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
Peter Herth
> Some followup, courtesy today's reddit.com:
> Why Ruby is an Acceptable Lisp:
> http://randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp
> Power vs. Popularity:
Yes, Ruby has some Lispy features, as for example Python has. That is
the reason, I use Python from time to time. I do not think any Lisper
claims that Lisp is the only usable computer language available. In my
youth I even did some successfull programmming in Fortran :p.
Anyway, the article claims: "Ruby gives you about 80% of what you want
from macros" - while the number itself could be discussed (but that
would open annother subdiscussion) so lets assume it is correct. But
while settle for 80% if you can have the full thing? Not talking of all
the other nice features of Common Lisp you do not get in other languages...
> http://zifus.blogspot.com/2005/12/power-vs-popularity.html
> Why Lisp will never Win:
This article is very intersting, as it writes, that Ruby really only
took of because of Ruby on Rails. So what is causing the current
popularity is one single application. That is fine, it may quite be that
for this kind of web programming Ruby on Rails is indeed the "best"
solution, but what consequences this has for the further spread of Ruby
has to be awaited.
> http://perl.plover.com/yak/12views/samples/notes.html#sl-39
Well, this article is plain silly. Yes there are things you do quicker
with specialized tools, and most Lispers use those tools where
appropriate (though I have to say, I cannot comprehend the awk version
while the Lisp one is very readable too me). And there is no permanent
talk on Perl in this newsgroup, currently you could argue we talk about
Ruby only :). But actually this makes a very interesting point: if it is
so, that Lispers often talk about other programming languages while
other communities do less so, could that mean that the typical Lisper
has a wider horizon?
Lars Brinkhoff
> Well, this article is plain silly.
It seems to have been written in 2003.
Alan Crowe
I tried fleshing out this idea in this eassy
http://www.cawtech.freeserve.co.uk/cost-benefit-simplification.2.html
perhaps you will enjoy it.
Alan Crowe
Edinburgh
Scotland
Matthias
1.) You might want to take a look at portfolio theory (Markowitz). It
describes how to deal with uncertain benefits.
2.) The zero-order approximation: "Programmer productivity does not
depend on programming language choice." is probably not so wrong:
If programming language choice were a very significant factor it
would be quite easy to quantify through lab experiments or market
analysis. Apparently, this is not the case.
Peter Herth
> 2.) The zero-order approximation: "Programmer productivity does not
> depend on programming language choice." is probably not so wrong:
> If programming language choice were a very significant factor it
> would be quite easy to quantify through lab experiments or market
> analysis. Apparently, this is not the case.
The fact that we do not longer use Assembler is a very strong hint that
the programming language *has* an obvious influence on the productivity.
William Bland
> And then:
>
> http://reddit.com/blog/2005/12/night-of-living-python.html
>
> <quote>
> Visiting reddit today, you may notice that things seem a little
> different. It's not just your imagination -- as our series of header
> icons hinted at, the site has been entirely rewritten in Python during
> some marathon coding sessions over the past couple weeks.
I'm possibly going to be on my own here, but I've often thought that
reddit doesn't seem like a complex enough problem that it would benefit
much from using Lisp. It seems to me that their biggest problem is in
building a community, which is more of a social challenge than a technical
one.
Sure, *I* would probably still use Lisp, even for simple problems, but I
believe Lisp's advantages over other languages don't become apparent until
you tackle really hard problems.
Just my .02
Cheers,
Bill.
jayessay
> Paul Foley <s...@below.invalid> (http://public.xdi.org/=pf) writes:
>
> > On Fri, 02 Dec 2005 07:02:15 -0800, Luke J Crook wrote:
> >
> > > [quoted]
> > > "Yes, Lisp is good for prototyping but as soon as you want to get
> > > serious then your project is going to have to be rewritten in
> > > C++/Java".
> >
> > > Things were going well up until his last statement. HMS Lisp scuttled.
> >
> > More likely: "HMS Reddit scuttled". [How many times have you heard of
> > things that started life in Lisp, worked well, got rewritten into some
> > other language (esp. C++) and /not/ failed miserably?]
>
> I would see a C++ or Java rewrite as a big business risk if the
> original software is at all complex. A costly distraction at best, and
> a life as an also-ran quite likely. And balanced against that risk
> ... what was the payoff again?
That's definitely true. Acutally the Yahoo store thing is, in fact, a
watered down version of this in action - not as bad as it might have
been, but not so good.
OTOH, it's been quite a long time now since running a company into the
ground or otherwise destroying it's value has been grounds for
anything other than a multimillion dollar "golden parachute" for the
executives responsible.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ulrich Hobelmann
> I tried fleshing out this idea in this eassy
>
> http://www.cawtech.freeserve.co.uk/cost-benefit-simplification.2.html
>
> perhaps you will enjoy it.
Following your terminology I'd say that Scheme and Lisp both have many
affordances on top of few features, which makes them nice.
Lisp has some more affordances, but many more features, which is why it
seems oldish and inelegant to some. OTOH there are some features (and
thus many affordances) which are missing from Scheme, so Lisp attract
some from that camp.
Joerg Hoehle
> >Have you looked at ABCL?
> > <http://armedbear.org/abcl.html>
> and leads to questions of "why not just use Java?" If any
> scripting language will succeed on that basis, it will be one much
> closer to Java's default syntax and assumptions.
I disagree. The Java language is not interesting. The JVM is important.
I haven't used ABCL nor Jatha, but jscheme (a little) and Kawa. I
actually prefered Kawa over jscheme precisely because it did attempt
not look like a Java with Lispish syntax. Rather, it tries its best to
be a Lisp/Scheme with several interesting extensions.
Yet one can still generate a .jar, completely made from Scheme code
and send that to people who are running "Java".
The problem therefore, is not Java, but interaction with the JVM (and
typically the implementation of fixnum, bignum, the many limited Java
libraries which force CL implementors to either roll their own
classes, or not implement full CL but use the standard J2EE API). Here
the Lisp programmers could share experience with many others:
Smalltalkers, Haskell, and JPython people among them. The tradeoffs
might be similar.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
javuchi
Adam Connor ha escrito:
> Why Lisp will never Win:
> http://perl.plover.com/yak/12views/samples/notes.html#sl-39
Funny... to win, what?
Tin Gherdanarra
>
> The problem therefore, is not Java, but interaction with the JVM (and
> typically the implementation of fixnum, bignum, the many limited Java
> libraries which force CL implementors to either roll their own
> classes, or not implement full CL but use the standard J2EE API). Here
> the Lisp programmers could share experience with many others:
> Smalltalkers, Haskell, and JPython people among them. The tradeoffs
> might be similar.
JPython works very well, but this is due to a large
effort by the JPython developers. The JVM does not
lend itself well to python.
The impedance mismatch is probably much larger for Lisp,
for two reasons.
- conses are not a native data type for the JVM
- the object model is completely incompatible with
Java's object model.
The conses can be implemented using regular
JVM data types, of course, but this is probably
slow.
Lisp's meta object protocol can be implemented
in regular Lisp, but then it will be incompatible
with Java's. It would not be possible to derive
a Java class from a CLOS base-class, for example.
If you don't wish to do this anyway, I see no
point in using the JVM. It sucks anyway, or so I've
heard. I'm ready to believe this because stack machines
are inherently slow due to thrashing the stack.
It is interesting that
the parrot folks seem to be stalled at the point
where they want to reconcile perl's and python's
corresponding (and seemingly incompatible)
object models.
Why can't everybody just get with the Lisp program?
Tin Gherdanarra
> Adam Connor ha escrito:
>
>
>>Why Lisp will never Win:
>>http://perl.plover.com/yak/12views/samples/notes.html#sl-39
What I like best is slide 39:
"There are a lot of things wrong with the Lisp user community.
comp.lang.lisp is one of the sickest newsgroups I've ever seen."
How do YOU feel in "one of the sickest newsgroup"?
>
>
> Funny... to win, what?
>
John Thingstad
This is by far the sickest.
If you fail to see that I suggest you see a psyciatrist!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad
<john.th...@chello.no> wrote:
> On Wed, 14 Dec 2005 18:34:27 +0100, Tin Gherdanarra
> <tinma...@gmail.com> wrote:
>
>> javuchi wrote:
>>> Adam Connor ha escrito:
>>>
>>>> Why Lisp will never Win:
>>>> http://perl.plover.com/yak/12views/samples/notes.html#sl-39
>>
>> What I like best is slide 39:
>>
>> "There are a lot of things wrong with the Lisp user community.
>> comp.lang.lisp is one of the sickest newsgroups I've ever seen."
>>
>> How do YOU feel in "one of the sickest newsgroup"?
>>
>>> Funny... to win, what?
>>>
>
> This is by far the sickest.
> If you fail to see that I suggest you see a psyciatrist!
>
no not really ;)
funkyj
> people, a feature that integrates into their editor of choice
I think the reality is that 99% of the people who love lisp find emacs
irresistible.
While VIM, source insight (commercial editor) etc are great for editing
C, C++ and java, how could they possibly touch an editor whose
scripting language is the same language you love and are currently
working in?
Now if someone embedded perl as a scripting language into VIM then VIM
would no doubt become the slam dunk choice for perl programming.
Substitute Python or langugage X for perl in the sentence above and the
statement still holds.
Putting reason aside for a moment <grin>, if you are interested in
other editors, making VIM more lisp friendly would probably be the most
worthwhile effort as it is the other ONE TRUE EDITOR.
--fj
Tin Gherdanarra
> On Wed, 14 Dec 2005 18:44:50 +0100, John Thingstad
> <john.th...@chello.no> wrote:
>
>> On Wed, 14 Dec 2005 18:34:27 +0100, Tin Gherdanarra
>> <tinma...@gmail.com> wrote:
>>
>>> javuchi wrote:
>>>
>>>> Adam Connor ha escrito:
>>>>
>>>>> Why Lisp will never Win:
>>>>> http://perl.plover.com/yak/12views/samples/notes.html#sl-39
>>>
>>>
>>> What I like best is slide 39:
>>>
>>> "There are a lot of things wrong with the Lisp user community.
>>> comp.lang.lisp is one of the sickest newsgroups I've ever seen."
>>>
>>> How do YOU feel in "one of the sickest newsgroup"?
>>>
>>>> Funny... to win, what?
>>>>
>>
>> This is by far the sickest.
>> If you fail to see that I suggest you see a psyciatrist!
I'm seeing two psychiatrists. I hope they don't read this
newsgroup and spot this confession because they would
leave me immediately when learning about the other. And
where am I supposed to get laid, then?
>>
>
> no not really ;)
>
Tin Gherdanarra
>>I think Adam's point was that Lisp editing will have to be, for some
>>people, a feature that integrates into their editor of choice
>
>
> I think the reality is that 99% of the people who love lisp find emacs
> irresistible.
I'm using vim, what puts me into the remaining 1%. I know that
Emacs is the better choice for lisp because of all the features,
but somehow I like vim's modal interface much more than Emacs.
And I CAN find matching brackets in vim ('%').
>
> While VIM, source insight (commercial editor) etc are great for editing
> C, C++ and java, how could they possibly touch an editor whose
> scripting language is the same language you love and are currently
> working in?
You got a point there, but not everybody likes using the
editor as a cockpit for all sorts of browsing, skripting and
making. This dislike is legitimate, I think.
>
> Now if someone embedded perl as a scripting language into VIM then VIM
> would no doubt become the slam dunk choice for perl programming.
It IS already the slam dunk choice for perl programming.
> Substitute Python or langugage X for perl in the sentence above and the
> statement still holds.
>
> Putting reason aside for a moment <grin>, if you are interested in
> other editors, making VIM more lisp friendly would probably be the most
> worthwhile effort as it is the other ONE TRUE EDITOR.
What about rewriting the darn thing in Lisp?
(Yet another great idea for a rewarding Lisp project).
>
> --fj
>
Larry Clapp
>> I think Adam's point was that Lisp editing will have to be, for
>> some people, a feature that integrates into their editor of choice
>
> I think the reality is that 99% of the people who love lisp find
> emacs irresistible.
*Almost* irresistible. :) I've used vi or Vim since 1991, and I've
considered switching to Emacs. I think learning Emacs would be less
painfull than rewriting slime.el in Vim+Perl, and more rewarding in
the long term. (Though I may well do neither, and stagger along with
VILisp. :)
> Now if someone embedded perl as a scripting language into VIM then
> VIM would no doubt become the slam dunk choice for perl programming.
> Substitute Python or langugage X for perl in the sentence above and
> the statement still holds.
:)
If you didn't know (and for others reading), Vim already supports
Perl, Python, tcl, and Ruby, and some other options for
environments/languages unknown to me (cscope, Sun Visual Workshop,
NetBeans, and Sniff).
> Putting reason aside for a moment <grin>, if you are interested in
> other editors, making VIM more lisp friendly would probably be the
> most worthwhile effort as it is the other ONE TRUE EDITOR.
A while back I wrote enough Vim+Perl to get an expression to Swank and
back again, but ran out of free time. Plus my design (such as it was)
was ugly and difficult to debug. Next time (if ever) I'll write a
plain Perl module to talk to Swank, and then write a Vim interface to
the Perl module, instead of trying to do a slime.el -> Vim+Perl
translation piecemeal.
Again, it'd be easier to just learn Emacs. :)
-- L
Nico...@gmail.com
about it, and in my case, I didn't knew it existed. Other languages
have the media now.
I believe lisp has better support for complex algorithms than any other
language. And in the future more and more things will need complex
algorithms than now. So we must be ready for that. I think that in 2-3
years everybody will be talking about lisp if things are done with this
in mind from now. Not now and not in 15 years.
jayessay
> Lisp has not so good implementations
Huh? You seem quite confused here. Lisp has some quite _excellent_
implementations. At least some of which are significantly better than
the typical "other languages". So, your starting "premise" is false
and thus the thrust of the rest of your post seems mixed up as well.