> There is a fairly prominent Lisper who argues the exact opposite; that Lisp is the ideal language for coding before knowing what you really want to code. I'd suggest reading Paul Graham's essays on the subject as a basis for discussing this particular point before going any further.

I don't know if you're assuming here that I don't actually use Lisp; I do, and have, for at least six years, after reading those very essays. I still find it to be write-only, but I don't think I'm communicating what I mean by that clearly.

When I say "write-only", my meaning is "requires extensive amounts of external mental state for interpretation." An unfinished painting is write-only: while you're painting, you can experiment, yes, but that's because the "random-access" bit that you're experimenting upon is not what's on the canvas, but rather what's been loaded up into your mind. If you leave off a painting for some months and then return to it, or if someone else tries to finish your painting—well, they will need to spend days staring at it to dissect the original goal of the work, the original style and methodology, before they can proceed. It is the same with Lisp: the text of a Lisp program is the canvas, while the "effective rules" of the program end up reflected mostly in the programmer's mind. To resume a Lisp program after some months is no easy task, any more so than rebuilding a filesystem index purely from its on-disk data records.

> Ruby's usability is pretty nice, but it has some seriously cool theoretical ideas, too. It's a few steps beyond just putting a prettier interface on i.e. Java. It may not be the most original language, but it's popularizing a lot of things most "working programmers" haven't encountered.

There's a large difference between "theoretical ideas" and "theoretical purity." A theoretically-pure language can be held in the mind all at once, because it only has a few key concepts. Lisp, Smalltalk, Forth, Lua or io, etc. are theoretically-pure, while, say, Perl, while containing many amazing and useful theories, is theoretically a leftover surprise. Theoretical purity is good for the usability of a language: three tools in your toolbox are better than three-dozen, if they each solve all the same problems just as efficiently. However, it seems like, the more theoretically-pure a language becomes, the less concerned its practitioners become with actually evaluating or developing the UX of the language. This is, I think, why Go is being mostly rejected by working programmers, for example: C, as much as it doesn't seem like it, is a theoretically-pure language (as in assembler, it's all just memory addresses which either hold values or other memory addresses), and Go is purely a UX enhancement over it—but the systems programmers are so used to C-like syntax for their systems programming that they won't stop to consider alternatives that enhance long-term usability (such as, say, slices.)

> That seems like a questionable metric for the quality of a programming language.

Well, I did say "basically." :) Think of the sort of "reading comprehension" test you might have had to do in elementary school. To be scientific, you have to control for the subjects' exposure to different linguistic paradigms, the content of each code-snippet, etc. In fact, it would likely be easiest to test with two entirely made-up languages, each of which differ by only one syntactic element X, and see how comprehension varies on X. But I digress: it was just an example off the top of my head, because there are currently no metrics for programming language quality whatsoever, and any metric, no matter how bad, is better than none. If you have a better idea, then we should use that better idea, but what we shouldn't do is pretend the usefulness of a programming language[1] is completely subjective, and that they can't be compared.

[1] I do not use "programming language" to mean "platform" or "standard library" here; merely the mapping from syntax to semantics. LISP-style Lisp is the degenerate-case of a programming language, with a one-to-one mapping from its syntax to the compiler's AST structure.