This is the response anybody who tries to make s-expressions "more readable" will get from lispers: don't bother. It didn't work in the 60's, why would it work

This is the response anybody who tries to make s-expressions "more readable" will get from lispers: don't bother. It didn't work in the 60's, why would it work now? Parens aren't unreadable, not like a sigil and punctuation heavy language, and on top of actually being reasonably readable, they are also extremely easy to edit with something like paredit in emacs and vim. So reasonable readability and extremely easy editing are working against you, also making the code easy to parse gives you not one, but three reasons not to waste time on such ideas. Now, let's look at the reasoning this page gives for this endeavor(from http://sourceforge.net/p/readable/wiki/Problem/ http://sourceforge.net/p/readable/wiki/Problem/): "Many people find Lisp's s-expressions hard to read as a programming notation, and thus reject them both." And many find them perfectly readable. "As noted below, even Lisp luminary Paul Graham agrees that Lisp notations have readability problems!" The page lists several quotes from various people. Interestingly, the two quotes from PG aren't good very good support. The first one talks about mathematical expressions, but I tend not to write many of those in my code, so it is a minor problem at best. And there are macros that let you write infix math in Common Lisp, surely there exist equivalents for scheme and clojure. The second doesn't even talk about lisp, but about code readability in general: "When you program, you spend more time reading code than writing it... a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor." Although I do agree with this quote, I don't believe it applies to lisp, all of the readability problems I have with lisp code have to do with bad naming, bad indentation(something parens actually help with, because the editor can indent your code automatically, since it is easy to parse) and really, nothing unique to lisp. "I have more faith that you could convince the world to use esperanto than [to use] prefix notation." By Paul Prescod function(argument1,argument2) is not prefix? Sure Object.method(args) is infix, but in general, programmers use prefix all the time. Command lines are prefix, nobody writes "filename copyfile /destination/directory" in the shell. Bullshit argument. "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in." A Larry Wall quote in an argument about readability, this one might actually work in my favor :) "After 13 years of doing Lisp and 3 or 4 years of Python, I agree: I prefer writing Lisp, but Python is easier to read." By John Wiseman I agree, Python is easier to read. This is not an argument for lisp being hard to read, it's an argument for python being easier. "LISP: ... mythically from ‘Lots of Irritating Superfluous Parentheses’ " Jargon File HaHa, actually none of the parens are superfluous, unlike in C like languages, where they are, if only you can remember all the damn operator precedence rules, if you can't, they aren't superfluous there either, and you need them to actually make the code more readable. HaHa indeed :) "... and don't ask me about the extraneous parenthesis. I bet some LISP programmer felt alone and decided to make it a bit more homey." Linus Torvalds I don't know the context of this, but I'm willing to bet he was talking about C code. "[If only] we could find characters or signs suited for expressing all our thoughts as clearly and as exactly as arithmetic expresses numbers" Gottfried Wilhelm Leibniz WTF? I'm pretty sure Leibniz was slamming Newton and not Lisp :) "A language should be designed in terms of an abstract syntax and it should have perhaps, several forms of concrete syntax: one which is easy to write and maybe quite abbreviated; another which is good to look at and maybe quite fancy... and another, which is easy to make computers manipulate... all should be based on the same abstract syntax... the abstract syntax is what the theoreticians will use and one or more of the concrete syntaxes is what the practitioners will use." John McCarthy This is a bit difficult to refute, since on the one hand, it sounds reasonable, but on the other hand history didn't work out that way. Some of this is here today, Common Lisp has reader macros, and in Racket you can insert the Greek symbol lambda, instead of typing it out in English. But at least with reader macros, being as conservative about adding them is a good idea, since ultimately they make the code harder to read if overused. I think McCarthy was just throwing ideas out there, and didn't have the decades of hindsight we have today, people have been writing and reading Lisp code for 50 years with little difficulty, and only introducing new people has been a problem, and only because these people have been introduced to alternative notations earlier. Start small children on Lisp, and they would think 5 + 3 * 4 is unreadable, and (+ 5 (* 3 4)) is easy to read. The page continues to say: "Indeed, Lisp notation has changed over time; the quote operator ' was not in the original Lisps, and was added because that construct was so common that it was worth creating an abbreviation. We're just working to add new abbreviations." As I mentioned, that can actually make code less readable if overused. Common Lisp has many such abbreviations: #' for function, #() for vectors, #P"" for pathnames, etc. And the mechanism is extensible, so you can go crazy if you want, adding #{} for hash tables is only a few lines of code. I'd like to conclude with this great essay I came across yesterday: http://www.storytotell.org/essays/good-for-whom.html http://www.storytotell.org/essays/good-for-whom.html