If you truly have been shunning Lisps because of parentheses I can only tell you that it will start to make sense once you see that they're just lists and that the fact that everything (including your code) is some variation of a list means that you are now (sometimes in the background) able to modify everything as if it was a list.
S-expressions are uniform in that they all look the same way. This means you have one form for literally everything in the program and you will have no problem parsing that form. It makes reading, mentally parsing and editing easier because everything is neatly delimited by parentheses.
In terms of readability, do you have any particular difficulties parsing the following code?
(define (sum/recursive lst [sum 0])
(if (null? lst)
sum
(sum/recursive (rest lst)
(+ sum (first lst)))))
We are defining a function, sum/recursive, that will take a list and return the sum of all the numbers in that list.
We use a default value of 0 for a function parameter called sum to store the sum. When the input list is empty ('(null? lst)' returns true) we return that variable. There is no return keyword, we just specify that variable and it will be returned.
If the list isn't empty, we apply sum/recursive on the rest of the list and as a second parameter we add the first number in the list to the already accumulated sum ('(+ sum (first lst))'). Using matching parens in your editor will make it obvious when you have matched the right amount of parens.
It should be noted that Racket, this Lisp variant, uses '[]' as well to delimit certain parts, for readability.
Lisp's super power (homoiconicity) comes at a trade-off of reduced discriminability. A good syntax highlighter and well-indented code (like you provided) reverses this effect considerably, but imho, it still takes a lot of getting used to for beginners.
In any case, the bigger part of the being productive in a codebase is to figure out how it encodes the domain, what idioms and patterns are favoured etc. So sometimes, it's just not worth adding another source of aggravation for "new arrivals".
I disagree with regard to Clojure. IME, the fact that it's a lisp doesn't seem as hard for noobs to grasp as immutability by default, or pickup up the functional programming mindset. We usually go for folks who use Emacs, so they may already have an indoctrination.
When you compare Clojure to other lisps, I think you'd agree it's more discriminable, given the plethora of literals that dont use parenthesis:
vectors [1 2 3]
sets #{1 2 3}
maps {:key "value" :name "Bryan"}
I've used clojure for some weekend hacking and have found that the biggest challenge is feeling like my code is non-optimal. I can get stuff to work and could build real stuff in clojure, but I hesitate because I feel that it's not necessarily idiomatic.
I guess I need a clojure mentor for the first non-trivial project. There really isn't that much idiomatic web-related code out there to read, and with clojure there is also quite a lot of variation in how systems get designed (b/c of the power and expressiveness available).
This is not an excuse, just noting the factor that has turned out to slow me down. If i had more leisure time I'd just power through and build stuff until I arrived (through trial and error) at my own sense of best-practices / design tradeoffs. That has yet to happen but will someday.
> S-expressions are uniform in that they all look the same way.
If you treat the language as a user interface to your computer, shouldn't things that do different things have different appearances, to help you distinguish them at a glance?
The braces become "invisible" after some training.
Different elements of the program are distingishable.
"+" is different from "if", which is different from "42".
It's all about people, so there are likely not cut and dried answers, but I know I have always found C style code a bit easier to read than Lisp style code. Part of this may be due to other conventions, such as larger indents in C code.
Like you say, with training, the differences are probably not that big a deal, but I don't think they are something to completely ignore, either.
S-expressions are uniform in that they all look the same way. This means you have one form for literally everything in the program and you will have no problem parsing that form. It makes reading, mentally parsing and editing easier because everything is neatly delimited by parentheses.
In terms of readability, do you have any particular difficulties parsing the following code?
We are defining a function, sum/recursive, that will take a list and return the sum of all the numbers in that list.We use a default value of 0 for a function parameter called sum to store the sum. When the input list is empty ('(null? lst)' returns true) we return that variable. There is no return keyword, we just specify that variable and it will be returned.
If the list isn't empty, we apply sum/recursive on the rest of the list and as a second parameter we add the first number in the list to the already accumulated sum ('(+ sum (first lst))'). Using matching parens in your editor will make it obvious when you have matched the right amount of parens.
It should be noted that Racket, this Lisp variant, uses '[]' as well to delimit certain parts, for readability.