Steps Towards an Acceptable Lisp | Hacker News Reader

Steps Towards an Acceptable Lisp

pwpwp.blogspot.com

19 pointspwpwp12 comments

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.

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

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

Hehe, you are telling my hearts content. I think something along those lines need to be thwapped into the face of every designer and implementer of a new language:

- do not take away my vim for your puny IDE. I rather won't try your language than learn a new editor - have a reasonable compiler out there which follows the guidelines to a compiler/interpreter interface on the command line: either "myLanguageCompiler program; ./program" or "myLanguageInterpreter program". - get this reasonable standard compiler into the major linux repositories

Basically, all of these boil down to a single important point: Lower the entry barrier to your language considerabely, even to a point where things are just reasonable and not great for the new programmer.

Certainly, vim might not be good for editing (say) Lisp, and the standard compiler called (say) lisp or lispc might not be fast and efficient for everything, but I don't care about that if I just want to spend an evening toying around with the language.

> 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.

It especially keeps out the people who pay smart people.

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

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.

"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.

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

the (object-oriented, semi-functional) Lisp programming model of the last decades.

I disagree with your claim, both here and in the OP, that the Lisp programming model is object-oriented. CLOS is just a library, one can write arbitrarily complex Lisp programs without going near it, and many Lisp hackers don't. Thinking in Lisp is not at all the same thing as thinking in objects. (After building OO systems for years, one reason I like Common Lisp is that I want nothing more to do with OO.)

The reason CL is semi-functional is not CLOS but the fact that it fully supports imperative programming, leaving it up to the programmer to decide what side effects to allow where.

It does have another big advantage: it's clean. Not having to be compatible with a prior lisp made it possible to have a lot of small things changed. Like the lambda function syntax, or the "def" special form, or the really nice reader syntax for vectors and maps. Both above the hood and below it's based on consistent abstractions. Other lisps would be too, no doubt, but they suffer from having evolved over a very long time.

And it grows, including towards what you it's say it's lacking right now. Recently it got the capability to work with mutable data structures (transients), which makes it less functional, but still without giving up the advantages.

Reply on news.ycombinator.com