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