Re: Reddit Guys on the Pros and Cons of Lisp

Pisin Bootvong wrote: 
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/
.

Relevant Pages

  • Re: Lisp in a Box
    ... > Lisp implementation to get started with the language. ... with lots of libraries and documentation all in one place. ... Bundle binaries of Gnu Emacs, CLISP, and some library package that suits ... entire "this runs on that, but not this" scenario, because Emacs and CLISP ...
    (comp.lang.lisp)
  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... library" of Common Lisp? ... If something isn't in the language, it will be in some common library, ... you might find M linked list libraries and N ... The more years you spend as a programmer, the more you learn ways to ...
    (comp.lang.lisp)
  • Re: Why Lisp is too hard for me to use
    ... > Lisp. ... > deal with the complexity alluded to in this thread. ... python libraries without being a python-ite is a major pain. ... > (by essentially understanding the difference between a debian system ...
    (comp.lang.lisp)
  • Re: A lisp foundation - a model for open source development?
    ... Lisp doesn't stand very well in terms of popularity so money from ads ... quality libraries we need sponsors, to gain sponsors we need to be ... Create an foundation, let's call it Alexandria ... deposit under foundation library. ...
    (comp.lang.lisp)
  • Re: A lisp foundation - a model for open source development?
    ... Lisp doesn't stand very well in terms of popularity so money from ads ... quality libraries we need sponsors, to gain sponsors we need to be ... deposit under foundation library. ...
    (comp.lang.lisp)