Live data from Hacker News

The Land of Lisp

landoflisp.com

141–146 of 146 posts

Re: The Land of Lisp

#141

Earlier quoted context omitted.

As an avid haskeller with a lot of respect for lisp, I've gotta say I really love the depiction of the Republic of Haskell as a police state, where side effects receive no mercy.

Wouldn’t it be more apt to say that side effects are not secondary citizens in haskell republic and they have first class support?

Yes, and the whole io-commands-as-values thing that outdoes anything the Command Design Pattern is capable of, and all that.

But given that the meme of haskell-has-no-side-effects exists, the Haskell Police State is funny.

Re: The Land of Lisp

#142
post #140

Earlier quoted context omitted.

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage. Sadly, it's a one-man thing. And CL seems quite stagnant. I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard. Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

> Compilation to the LLVM is a huge advantage

Is it? Advantage over what?

> And CL seems quite stagnant

That's good then, since he can better catch up.

> Sadly, it's a one-man thing.

He can always reuse code from other implementations. Though I agree that it is too much work for a single person to create a quality implementation of Common Lisp.

Problem seems to be that there is not enough interest in another implementation based on an un-explorered infrastructure (LLVM).

> CL progressed beyond its ANSI standard

It has. In implementations and libraries.

Re: The Land of Lisp

#143
post #128
post #122

Earlier quoted context omitted.

> CLISP is unmaintaned AFAIK, it is not really unmaintained, the developers just haven't done a release in years. When I fire up CLisp on openSUSE Tubmbleweed (their rolling release distro), it says Welcome to GNU CLISP 2.49.60+ (2017-06-25) That would make me think that development might have slowed down, but not stopped.

Yet, if you visit that URL, you are greeted with : Current version: 2.49 (2010-07-07) Seems like the patch level on openSUSE is provided by the package maintainer, not CLISP. It looks like Debian Wheezy is at "2.49-8.1", Ubuntu Xenial is at "2.49-9ubuntu1", FreeBSD Ports is at "2.49_6", but also marked deprecated/expired as of 2014. I'd venture that the maintainer is applying patches to the upstream source to keep it…

The most recent commit to the source tree (https://sourceforge.net/p/clisp/clisp/ci/tip/tree/) was today.

Not sure how much that is worth - with no release in seven years, I would guess there is not much going on. But it is still more than nothing.

Re: The Land of Lisp

#144
post #140

Earlier quoted context omitted.

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage. Sadly, it's a one-man thing. And CL seems quite stagnant. I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard. Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

But the whole idea, to your own point, is that there are lisps everywhere, compiling to everything and each having specialized additional features for the local needs, yet the ansi core remains intact, so everyone can use every one of those lisps (if they really are lisps...I’m looking at you, clojure!) [ED: I’m good with RSR5 too ... Jerry Sussman himself calls scheme a Lisp!]

Re: The Land of Lisp

#145
post #140

Earlier quoted context omitted.

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

CLASP is for me the most exciting CL implementation right now. Compilation to the LLVM is a huge advantage. Sadly, it's a one-man thing. And CL seems quite stagnant. I wish one implementation triumphed over the others, and CL progressed beyond its ANSI standard. Clojure has many interesting things. So does Racket. The Lisp landscape is too fragmented. And thus libraries are a huge problem.

>I wish one implementation triumphed over the others

That would be terrible. Part of the nice things of CL is that you can choose the implementation according to what you need. For example ECL if you want to embed your lisp code with C code. ABCL if you really need to call lots of Java libs (or have Java code call your Lisp code easily), and so on. We're talking about mature, proven, tested implementations.

If one implementation triumphed over others, over time we'd be in a position similar to, say, Python or Clojure, where there is only one or two implementations, besides some experimental implementations, and nothing else.

Something that needs to be mentioned is that CL is truly standardized; if you have a code written in Common Lisp, chances are it will compile straight away on most of the implementations (ECL, ABCL, SBCL, etc), with no change needed. So having many implementations does not mean there is any kind of fragmentation in the language.

>and CL progressed beyond its ANSI standard.

CL is one of the most extensible languages out there, so it has already progressed way beyond the ANSI standard. The standard doesn't need modification to support new things. There are already many libraries giving you things that are not in the standard (like sockets or threads) but in a portable and standarized way.

Re: The Land of Lisp

#146
post #68

Earlier quoted context omitted.

> The main issue people have with the book is that it uses CLISP-specific code in a few places. CLISP's last release was seven years ago, and because it hasn't really been maintained it's beginning to bitrot. Folks in #lisp generally don't recommend using CLISP these days, instead recommending actively-maintained implementations like SBCL, CCL, ECL, ABCL, etc. Note that CLISP is actively maintained; the most recent c…

Last I heard they were looking for a maintainer: http://article.gmane.org/gmane.lisp.clisp.general/14256 Has someone stepped up?

From the commit history, looks like Bruno Haible & Sam Steingold are still doing it.
Post reply on HN