4 ms·

> People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that

by bmh100 12y ago

> People complain about the lack of run-time support for concurrency and IO in the specification. I don't think they realize, coming from other languages, that Common Lisp doesn't need it. The specification defines the language and a minimal ball of mud for doing practical work with it. Things like concurrency, threading, and IO are implementation issues and have been solved by high-quality open-source implementations for quite some time. We even have good libraries that provide a cross-platform layer to things like threading. In that case, it would be useful to newcomers to introduce those facilities into the core of the language. The more batteries are included, the easier language adoption becomes. > But ultimately people bike-shed over "car/cdr" and specialized functions for specific data-types (ie: AREF, GET-HASH, etc). You can write higher-order functions to abstract away sequence access and iteration if you want: people have and there are good libraries for it. To me, this is not bike shedding, but user experience design. The more learning that is required to accomplish a given goal the first time, the less productive and more difficult that goal becomes. "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead?

agentultra 12y ago
> "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead? Nothing about programming is intuitive. The problem here is that you've adopted ideas and notions from another language and are bringing that baggage to Common Lisp. If you learned Common Lisp first you might not have this very issue you describe. For historical reasons, "car" and "cdr" are the names of special pointers to the elements of a cons cell. There's nothing about them that have anything to do with lists. You just happen to be able to construct lists by linking together cons cells. CAR and CDR simply deference the pointers in the cons cell: (atom . atom) Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right." One or both of those atoms could be a cons cell... so there's nothing about CAR or CDR that has anything to do with notions of "first", "last", "head", or "tail." Those are higher-order functions for operating on linked list and are in the Common Lisp specification anyway. Suggesting that Common Lisp should remove them is like saying you should remove pointers from C.
- dragonwriter 12y ago
  > Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right." Then names like "left" and "right" rather than mnemonics for "contents of address part of register" and "contents of decrement part of register" would make sense.
  - agentultra 12y ago
    There's nothing you can call them that will make any more sense than CAR and CDR. You can call them BOB and DOUG, LEFT and RIGHT, UP and DOWN, CAKE and DAFFODIL. It wouldn't matter. They're still just symbols to a function that deferences the associated pointer in a cons cell. The powers that be chose CAR and CDR and they're about as good as any. The bonus discovery that the (car (cdr some-cons-cell)) could be shortened to CADR via a macro was just icing on the cake. Now we have a macro that can access any part of an abstract tree. Nice. There's nothing intuitive about programming. There's no analogy you can apply to CAR and CDR or even CONS which will suddenly make sense to your primitive mind. You can't pick up a cons cell in your handle, fiddle with it, and throw it back at the computer. There's no analog in nature which resembles it. It's an ephemeral thing that only exists inside a machine because an idea someone had made it so. So stop looking. If that's the biggest hurdle to learning Lisp I'd be surprised if someone could be taught to program in any other language. Try teaching C declaration syntax to someone. char *(*c[10])(int **p); I can explain a cons cell in five minutes tell you that there are two functions for accessing its sub-parts and we can move on. ... to red-black trees, skip lists, linked lists, circular buffers, trieps, whatever. Update: I don't mean to say I'd be surprised if someone could be taught to program in any other language in any sort of glib or pejorative sense. Of course one can learn to program without hearing about a cons cell. What I mean by that is it takes some willingness to accept abstract concepts and turn them into symbols in order to learn how to manipulate them.
    - dragonwriter 12y ago
      > There's nothing intuitive about programming. If that was true, than naming constructs in programming languages wouldn't matter at all. > If that's the biggest hurdle to learning Lisp Its not, its just one of many small hurdles that keep Lisp as a fairly niche language, despite its strengths when viewed from a 30,000 foot level. > Try teaching C declaration syntax to someone. C-family languages declaration syntax is a major factor in the popularity of dynamically typed languages (newer statically typed languages that are starting to take back some ground mostly reduce both the clutter of that syntax and the need for declarations at all.) So, other than illustrating the a similar (but larger) problem to the car/cdr problem, I'm not sure what the relevance is.

by bmh100 12y ago

agentultra 12y ago

> "car" and "cdr" are not intuitive to me. Why not use "first" and "rest" or "head" and "tail" for CL21 instead? Nothing about programming is intuitive. The problem here is that you've adopted ideas and notions from another language and are bringing that baggage to Common Lisp. If you learned Common Lisp first you might not have this very issue you describe. For historical reasons, "car" and "cdr" are the names of special pointers to the elements of a cons cell. There's nothing about them that have anything to do with lists. You just happen to be able to construct lists by linking together cons cells. CAR and CDR simply deference the pointers in the cons cell: (atom . atom) Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right." One or both of those atoms could be a cons cell... so there's nothing about CAR or CDR that has anything to do with notions of "first", "last", "head", or "tail." Those are higher-order functions for operating on linked list and are in the Common Lisp specification anyway. Suggesting that Common Lisp should remove them is like saying you should remove pointers from C.

dragonwriter 12y ago
> Where atom can be a value or a another cons cell. In this visualization it's useful to think of CAR as referring to the "atom on the left" and CDR referring to the "atom on the right." Then names like "left" and "right" rather than mnemonics for "contents of address part of register" and "contents of decrement part of register" would make sense.
- agentultra 12y ago
  There's nothing you can call them that will make any more sense than CAR and CDR. You can call them BOB and DOUG, LEFT and RIGHT, UP and DOWN, CAKE and DAFFODIL. It wouldn't matter. They're still just symbols to a function that deferences the associated pointer in a cons cell. The powers that be chose CAR and CDR and they're about as good as any. The bonus discovery that the (car (cdr some-cons-cell)) could be shortened to CADR via a macro was just icing on the cake. Now we have a macro that can access any part of an abstract tree. Nice. There's nothing intuitive about programming. There's no analogy you can apply to CAR and CDR or even CONS which will suddenly make sense to your primitive mind. You can't pick up a cons cell in your handle, fiddle with it, and throw it back at the computer. There's no analog in nature which resembles it. It's an ephemeral thing that only exists inside a machine because an idea someone had made it so. So stop looking. If that's the biggest hurdle to learning Lisp I'd be surprised if someone could be taught to program in any other language. Try teaching C declaration syntax to someone. char *(*c[10])(int **p); I can explain a cons cell in five minutes tell you that there are two functions for accessing its sub-parts and we can move on. ... to red-black trees, skip lists, linked lists, circular buffers, trieps, whatever. Update: I don't mean to say I'd be surprised if someone could be taught to program in any other language in any sort of glib or pejorative sense. Of course one can learn to program without hearing about a cons cell. What I mean by that is it takes some willingness to accept abstract concepts and turn them into symbols in order to learn how to manipulate them.
  - dragonwriter 12y ago
    > There's nothing intuitive about programming. If that was true, than naming constructs in programming languages wouldn't matter at all. > If that's the biggest hurdle to learning Lisp Its not, its just one of many small hurdles that keep Lisp as a fairly niche language, despite its strengths when viewed from a 30,000 foot level. > Try teaching C declaration syntax to someone. C-family languages declaration syntax is a major factor in the popularity of dynamically typed languages (newer statically typed languages that are starting to take back some ground mostly reduce both the clutter of that syntax and the need for declarations at all.) So, other than illustrating the a similar (but larger) problem to the car/cdr problem, I'm not sure what the relevance is.