Hacker News Reader

Comment by galaxyLogic | Hacker News Reader

I'm starting to see the allure of plain Lisp. All it has is functions and functions have names which convey a meaning. Plus some syntax for creating macros.

Now CAR and CDR don't convey a lot of meaning I agree. But that's just a matter of poor naming. They should (in my opinion) be called 'first' and 'rest', or something similarly meaningful and descriptive.

Of course short-hands and aliases are good for most often used functions. But I would prefer those to be aliases, with a proper descriptive name available as well.

And operator precedence, that makes code in a different language really hard to understand. Parenthesis make it explicit. Keep it simple. That makes code more verbose but then you can use macros to make it less so.

View on HN

> Now CAR and CDR don't convey a lot of meaning I agree. But that's just a matter of poor naming. They should (in my opinion) be called 'first' and 'rest', or something similarly meaningful and descriptive.

Some Lisps do that, but I think it's important to remember what CAR and CDR actually do, which isn't always related to lists: They access what's being pointed to by the pointers in a cons cell, which can be used to create multiple data structures in a given Lisp, so keeping the names abstract prevents the code from having the wrong names all over the place. For example, if I'm using cons cells to construct a key-value store, CAR isn't "head of list" it's "key" and CDR isn't "tail of list" it's "value" especially if the cons cell looks like this: (a . b) such that the CDR isn't a list of any kind.

In Common Lisp, of course, there are more efficient data structures for a lot of what older Lisps used cons cells for, so this is less of a concern, but I still think it's important to prevent confusion.

Good to understand. So maybe key() and value() would be good, more descriptive names for them then.

But I do think using a natural-language name like CAR even if very specialized, is better than using single-char symbols as function names.

> So maybe key() and value() would be good, more descriptive names for them then.

My point is that they can be used in many different ways, and are, such that any mnemonic name would be misleading in some contexts.

They could have multiple aliases, and you could pick the one that fits the context

By my estimation, it seems you've now spent about ∞× more time making suggestions how to improve Lisp than actually working in it.

Without working in in Lisp solidly for a good 6 months, you don't know where the actual pain points are.

What in your estimation are the actual pain points of Lisp?

It depends exactly on which implementation and dialect we are talking about.

Mainly people sometimes report things lacking in the ecosystem. The number of people doing any kind of Lisp are relatively small.

If you're doing FOSS, you might find it hard to get collaborators and pull it solo.

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

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

Circa 1990 or before.

car and cdr are deeply entrenched in the Lisp culture: in the systems, historic and past and volumes of literature. Criticizing these always reads like someone stepping off a plane on their first trip to some country, are telling the locals that their words are confusing, and maybe they should speak English.

When you see car, cdr and other related functions in Lisp code, it communicates that the code has strictly a physical interpretation, using well-known, decades-old idioms. You know exactly what it's doing with what kind of structure, and you know not to try to read any meaning into it. As to what that structure represents, what it's being used for, you have to look elsewhere; those names don't give that away. But to a Lisp hacker, spots in a program littered with car/cdr/cons/caddr/... are comfort zones.

It's good to have one set of names for this "just structure, no meaning" stuff and stick with them, than to go inventing new ones. That's more important than their specific choice. There is no end to what a cons-cell-based structure can mean, and so no end to the potential sets of better names for its parts; it's best to leave that to individual programs.

It's good that the names are short. MacCarthy saved us from awful ones. Before Lisp, there was a project called FLPL: Fortran List Processing Language. The names came from that, but in that project, for some inexplicable reason, they had XC ... RF prefixes and suffixes: XCARF, XCDRF, ... MacCarthy had the presence of mind to shorten the insane naming scheme, but not all the way to just A, D.

Mainstream Lisp dialects like Common Lisp have first and rest. Plus other names like second, third, as well as numeric indexing into a list. These names are still meaningless with regard to what a list is used for. first is no more informative than car about what is expected to be first; it's only clearer to complete neophytes who haven't gone through the 15 minute tutorial on car and cdr.

Reply on news.ycombinator.com