4 ms·

> Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are

> Yeah, lots of this is just swapping out one awkward keyword for another. Many a well-intentioned Lisper eventually begins to see deficiencies where there are none and attempts to improve their implementation of choice. Common Lisp is one such target because people coming from in-vogue languages are used to the language changing every year or two. Invariably this leads to superficial changes at best which are enabled, surprise of surprises, by Common Lisp because it was designed to be extensible. My theory is that if your language of choice needs to change its grammar rules to introduce new features you're basically admitting that you should have added macros programmatic access to the reader. > It's almost like lispers want the opposite of java, long verbose keywords and syntax and then as short as possible variable names. Well syntax is at a minimum in Common Lisp. It tends to avoid syntactical short-hand. The most common I know of being QUOTE, BACKQUOTE, UNQUOTE, UNQUOTE-SPLICE, and FUNCTION: ' ` , ,@ and #' respectively. If you read the preface to the first edition of Structure and Interpretation of Computer Programs I think you will find an enlightening explanation of, Why Lisp?. To paraphrase a brief summary: there are very few ways to form compound expressions and hardly any syntax at all so that the programmer can get to the problem at hand within an hour: the language disappears. The longer names are chosen stylistically based on the maxim that computer programs are meant for humans to read and only incidentally to be executed by a computer. Lisps are not, contrary to popular mythology, list-processing languages. It's a symbolic language. The relationship between symbol and data allows the programmer to think primarily about the transformations to data without the abstractions becoming weak. > Why not switch the parens to something that's a single keystroke? You could. Common Lisp gives you access to the reader. You can write a more fitting syntax you are more comfortable with. I've written reader macros to parse assembler instructions for an emulator I wrote in Common Lisp. > this just seems to be moving things around, not really improving anything That's my impression too. These sorts of experiments are worth trying from time to time in order to see if something can come from them. Maybe something will come out of this. 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. The standard hasn't changed AFAIK because: 1. It'd be expensive and nobody wants to fund another ANSI committee. 2. There haven't been any significant proposals the necessitate revisiting the specification. 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.

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.

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.