

Steps Towards an Acceptable Lisp - pwpwp
http://pwpwp.blogspot.com/2009/09/steps-towards-acceptable-lisp.html

======
ggchappell
Much of this looks good; however, I _really_ hope that "unfriendly" stuff
isn't taken to heart. (Or maybe everyone can take it to heart, except for one
language community, and then _that_ becomes the "acceptable Lisp".)

On the other hand, I'm interested in a different set of issues. Consider
Haskell. As a language, it's not doing too badly. Why? Well, one reason is
that it is very well designed. But another is Hugs. Hugs was available a
decade ago, it ran anywhere, was lightweight, let you use your favorite
editor, implemented almost the complete standard, let you write and run
Haskell code easily immediately after installation (which was fast), and,
while it's a bit short on tools, it does let you write and run "real"
programs.

I would say that Lisp desperately needs a Hugs.

If I look into getting a Lisp implementation, I see that they want me to learn
Emacs, or mess with the JVM, or are not available on all platforms, etc. None
of these things have much to do with the language itself, and they are all
barriers to adoption.

I just want to click a box in my package manager, hit the button to download,
run the program, and be in a REPL, or maybe say "edit" (or whatever) and be
typing in a source file, which I can easily compile and execute.

Again, Lisp needs a Hugs. But Hugs was designed years ago, and things have
changed. What does "a Hugs" for today look like? I'm not completely sure, but
the above is a start toward describing it, I think.

~~~
blasdel
It's called DrScheme (I don't think there's an equivalent for CL)

~~~
ggchappell
Thanks for the pointer. I'll look into that.

------
olavk
> I think an unfriendly community is a great feature, because it keeps idiots
> out, and there's no place for idiots in the world of Lisp.

It also keeps a lot of smart people out though.

~~~
caffeine
It especially keeps out the people who pay smart people.

------
krakensden
Clojure seems to have most of what he wants- I wonder if he's aware of it.

~~~
pwpwp
For my tastes, Clojure strays too far from proven ground.

It's nice to experiment with stuff like persistent data structures and STM,
but I don't think the next big Lisp, if there is one, will be based around
that model.

It's simply too far removed from the (object-oriented, semi-functional) Lisp
programming model of the last decades.

~~~
J_McQuade
"It's simply too far removed from the (object-oriented, semi-functional)
_Common_ Lisp programming model of the last decades"

~ahem~ Common Lisp and Lisp are not equal. Well, maybe in a sense, but they're
definitely not eql.

Anyway, I'm still unsure about Clojure myself (not really had the chance to
dive in), but a lot of the 'unproven' ideas you mention (persistent data, STM,
also lazy functions etc. etc.) have been doing the rounds in PL circles for
quite a while now. It's interesting to see them taking root in lispsville, if
nothing else.

I like Lisp and I like Haskell - Clojure seems to take cues (very well proven
ones, I might add) from both but, like I say, I've yet to really see how well
they've been married.

~~~
francoisdevlin
As an avid Clojurian, I can recommend taking the plunge. The seq abstraction
goes a long way to reducing library sizes. This is going to be as big a deal
as the STM.

My $.02

