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