2009-09-16

Steps Towards an Acceptable Lisp

Houston, we have a problem

I think that these two quotes capture perfectly the dilemma Lisp is in:
Common Lisp: The king of programming languages. – Slava Pestov

Lisp is Not an Acceptable Lisp. – Steve Yegge
On the one hand, Lisp is totally lovable, on the other hand my heart aches when I look at current Lisps.

Here are my thoughts about what an acceptable Lisp would be:

Generic

An acceptable Lisp would be generic, or protocol-based, meaning that all data types are defined by interfaces, rather than concrete implementations. Think STL, not conses.

Orthogonal

An acceptable Lisp would be built from orthogonal primitives.

One example is control flow. An acceptable Lisp could for example include call/ec and unwind-protect, and be done with it. No need for Common Lisp's salad of catch, throw, tagbody, go, block, and return.

Modular

An acceptable Lisp would include a serious module system, like O'Caml's, that really allows for programming in the large.

Object-oriented

An acceptable Lisp would be as object-oriented as Smalltalk, which means that the only way to get at an object's internals is via messages.

CLOS's generic functions show that OO integrates beautifully with Lisp's semi-functional approach to programming.

Extensible

An acceptable Lisp would be as extensible as existing Lisps, which means at least macros and reader macros, and maybe even OMeta-style completely extensible parsing.

Cutting-edge

An acceptable Lisp would have to bite the bullet, and do some language research, and/or adopt some of the novel results of the Scheme community.

One example is clear staging, aka phase separation. eval-when is simply ass-backwards.

Another example is a hygienic defmacro. It's the Lisp spirit, as evidenced by PLOT's use of hygienic macros.

Proven

Lisp is still lightyears ahead of most other dynamic languages, and an acceptable Lisp would have to carry forward these proven features: rich arithmetic, meta-object protocol, restartable conditions, optional dynamic scope, compiler-at-runtime, generalized references, etc, etc, etc.

Realistic

An acceptable Lisp would have a BDFL, a single implementation, focus on UNIX only, include lotsa batteries (or even better, power generators!), etc, etc, etc.

Unfriendly

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.

This is (a wee bit) tongue-in-cheek of course, but the community should demand from n00bs that they do their homework, and do it well.

I'd much rather have a plainspoken, occasionally angry Linus-type character as BDFL, than a Guido-type, who tries to be n00b-friendly and forthcoming all the time.

Conclusion

Designing an acceptable Lisp is no walk in the park.

The designer of the Next Big Lisp has to keep a large area of the Lisp design space in his head, and make tasteful design decisions.

So, go ahead and just do it!

6 comments:

Anonymous said...

a blog post, no code - it shows

Manuel Simoni said...

Show me your code, buddy!

Manuel Simoni said...

FWIW, I've implemented some of these ideas in CyberLisp, but I think I've made it clear that it's a long trip to an acceptable Lisp.

Anonymous said...

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

Yikes! No thanks. You're view is so skewed that you find the python too noob friendly? Good luck with that.

Anonymous said...

I feel trolled because I cannot tell if you're serious or not. References to OCaml's functors and modules as programming in the large? It is just type composition and poorly implemented too! Does C++ allow programming in the large because of templates?

I guess one can't rest of CLOS's laurels forever.

Anonymous said...

Neither Slava Pesto nor Steve Yegge are Lisp programmers - I don't care what they say about Lisp, buddy.

"CyberLisp' is a nice exercise - it is just a few dozen man years away from some existing Lisp - Lisps that I find acceptable. Lisps like CyberLisp are already existing and every other week a new one gets partially implemented.

I would not even know why I should use CyberLisp or why it should be more 'acceptable' than what I have. Sure, everybody should implement a Lisp language at least once, but it does not mean that it will not die immediately after.