Hacker News Reader

Comment by brudgers | Hacker News Reader

What parts of Common Lisp are bad? Wouldn't removing them require revising the standard [ANSI INCITS 226-1994 (R2004)]?

Most of the bad parts come from Lisp being so old and the standard being written at a time when nobody knew what was going to win out.

Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility.

Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place.

Somewhat related, there's more inconsistent naming than in most languages. The destructive form of concatenate is nconc, but the destructive form of reverse is nreverse, etc.. Most built-in predicates end with "p", but some of the older ones don't. These days there's pretty solid consensus on how things should have been done, and how they should be done in the future, but we're still stuck with the old stuff.

It's basically 60 years of backwards compatibility concessions.

You're right, removing the bad parts of Common Lisp would technically require coming out with a new version of the standard, "Common Lisp 2015" or something, but I don't think anybody has proposed doing that. My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.

[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...

I'm pretty sure you can use first and rest in Common Lisp if you don't like car and cdr

http://en.wikibooks.org/wiki/Common_Lisp/Basic_topics/Lists

As usual, problems come when reading someone else's code, not writing your own.

If you make a dialect without car/cdr the first thing about 30% of lisp hackers will do is write a macro to generate definitions for all of these:

http://www.lispworks.com/documentation/HyperSpec/Body/f_car_...

> Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place.

What I often see on the Internet is people complaining about car/cdr and suggesting to replace them with first/rest or equivalent. Most of the times those people don't understand why doing so is a bad idea.

Cons cells can be (and are, all the time) used to build arbitrary data structures, not just lists. "first" and "rest" or "head" and "tail" make sense if you're dealing with a linked list (and notice, that Common Lisp does provide you such named functions), but they are not right names if your structure is a tree, or a graph (yes, you can build cyclical structures with cons cells).

Sure, car/cdr terms are relicts of the old architecture, but I'm yet to see someone propose names that are agnostic to data structures constructed with cons cells. And, as some old Lisp hacker mentioned somewhere, car/cdr combinations like caaddr, etc. are easy to say over the phone ;).

I recognized the talking over the phone thing from SICP.

http://youtu.be/X21cKVtGvYk?t=22m40s

Yup, that's the source, thanks :).

I also highly recommend those lectures to everyone who haven't seen them. There's a lot of insight there (and even more in SICP book).

> Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility.

As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.

They're keywords; you needn't use them if you don't want them.

> My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.

Which is sad, since a new standard (say, a CL-2015 package…) would be able to build on top of much of what is really good about CL.

> As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.

I would love to see an example of pathnames being useful today. In my experience they're the only part of Common Lisp that is an active impediment to getting work done on a Unix system. It would be awesome if we could have a generic file naming mechanism that would also represent URIs. Unfortunately Common Lisp pathnames manage to suck at both Unix filenames and URIs.

I'm working on something that will need all the features of pathnames too. I haven't looked at what would be needed for URIs yet though.

The thing about revising a standard is that it's a social task and not a technical one, and the cost of getting everybody on board is accommodating differing opinions. See the sibling about nil vs '() vs #f. All this is to say, if you want to get the CL hackers on board, you need to meet their needs, at least partially, in addition to cleaning out the cruft; and your cruft might be the hill that I choose to die on.

I've got a PDF somewhere of Richard Gabriel's notes on the history of Lisp; it sheds interesting (if opinionated) light on the evolution of Common Lisp.

That nil does double duty as boolean false and shorthand for '(). Scheme got it right with #f not being the same thing as '()

I'm in the minority, but that's something that annoys me about Scheme. Lisp-style list processing code is more concise when nil is false. I also think array-processing or Haskell list style code is better than Lisp style list code, so IMO most Scheme code ends up with the worst of both worlds.

Reply on news.ycombinator.com