Why Racket? Why Lisp?

I fail to see your point. You could accidentally put a brace in the wrong spot, or use an if statement without braces in a C-like language, and it would stand out visually much less than the code you cite above.

"But I've literally never run across a situation where I needed my code to edit itself."

Well, "need" is a strong word. I mean, you could probably argue, in a philosophical sense, you never needed to write any computer programs in the first place (plenty of people go through life without doing so).

However, it is very likely there were times in your life where having your code edit itself would have led to getting a program working in less time, with fewer bugs, or better performance. Which of these benefits apply, of course, depend on the problem you were trying to solve.

"So I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time."

Um, no. Rich Hickey has pointed out idiomatic Clojure requires fewer parens than the equivalent Java.

> all Lisps seem to be more or less interchangeable when it comes to the language

Definitely not true.

It may be true to an extent for implementations of one particular lisp, like Common Lisp or Scheme, but even then there are very real, and significant differences. Simple and regular syntax makes it actually much easier to build many different semantics, and that's what lisps are about.

Racket has less libraries than Clojure and no access to JVM ecosystem. On the other hand it's FFI capabilities to C are very nice and easy to use. Racket macro system - syntax-parse (with syntax-rules and syntax-case and... defmacro for simpler cases) - is the most powerful there is right now. Combined with access to the reader and ability to make reader macros this makes Racket much easier to extend and transform than Clojure (by design). Which takes us to the biggest advantage of Racket, which is it's actually a family of languages, both s-exp based and with traditional syntax, built for specific purposes, which you can mix and match easily. Typed Racket and lazy variant, and FrTime, and Datalog - and more - are examples of this. Then you have module system which is a game changer for unit-testing, object system which is more powerful than most (besides CLOS, but there's always Swindle), the most advanced contracts system among all PLs, and of course quite fast JIT compiler and many more.

Clojure is simpler than Racket, but provides a set of highly opinionated defaults which people are comfortable with. I think Clojure and Racket are like Sublime Text and Emacs - Emacs is strictly more powerful, but it requires much more work to use this power well, while Sublime works well from the get go. But in the end both are infinitely better than Notepad and sooner or later you will come to know both, which is what I suggest you should do.

Good call on the diamonds.

Echoing everyone else, basically, your other points are a bit shortsighted.

You never need code that edits itself - completely true. Completely missing the point. Most programming features fall into this category; you don't -need- them, you could always use assembly instead. The point is that once you get them into your brain as an option, problems that might otherwise be tricky or time consuming become much easier.

To that end, everything is an expression is a list...yeah, you don't need it either. But, assuming the above (that code that can edit itself turns out useful sometimes), imagine how easy it is to metaprogram when all your executable code is just a list, and you already know how to modify lists.

In either case, you don't -need- the feature, sure, but a moment's reflection might open up the possibility that once you fully grok the ramifications, and have it amongst your other programming tools, you'll find a good use for it.

As to too many parentheses, as someone else mentioned,

  foo(a, b, c)

simply becomes

  (foo a b c)

Not really any more of them.

Does anyone else find it difficult to highlight things on this page? Specifically, 'kvetchery' which is found in the third paragraph.

I believe the author is the one responsible for the facelift of Racket's documentation. He may belittle his own lack of formal programming education but I am thankful for his design chops.