[fnordsensei]

I ran into LISP during my university days as well and was pretty much force fed it. I didn't want to touch it with a ten foot pole after that. However, for various reasons, I ended up using Clojure to prototype a rather large project, and was surprised at how different it felt to work with it compared to my university days, in a positive way. Might be that I had matured, I dunno.

I don't feel that there's anything particularly magical with the paren being on the left hand side of the verb that automatically makes it less readable than when it is on the right hand side of the verb.

[platz]

I think its also the indentation along with everything is an expression, formatted as a list kind of thing.

Especially that alternating pairs business.

Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.

I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.

[Morgawr]

>Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.

The whole point of macros is that they are written in the same syntax as everything else (because of homoiconicity you can operate on your code as native data), you don't need to know what is a macro and what is not for 90% of the code you write. There are very little cases in Lisp languages in general where the difference between a macro and a function are evident, and in Clojure even less (compared to another dialect like, let's say, Common Lisp).

There are some times where that might be useful, but that's why we have a repl and macroexpand.

[platz]

Yes, they have the same syntax, but the semantics are different:

"that macro function is called and is passed the unevaluated operand forms. The return value of the macro is then evaluated in its place.

If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right." - http://clojure.org/evaluation

There are many macros and special forms in clojure where you have to understand that the arguments are not evaluated first - and if you try to reason about what happens as if they were eagerly evaluated you get the wrong answer or an error

[calibraxis]

> I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.

That's why the pipeline operator (->>) is common. Then you just read it from up to down.

[davidw]

I wonder what some of the design guys would say about the information contained here and its readability:

https://github.com/stuarthalloway/programming-clojure/blob/m...

https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

Grabbed at random. I think the larger indentation and fewer parens do make a difference when you squint at things.

Of course, I also think as a professional programmer, if something does the job, get over it and get on with it. I use Erlang myself, which also gets lots of syntax complaints.

[siscia]

I write clojure and a little bit of C and I find the clojure part extremely more readable...

[davidw]

Is it because it simply does a lot more with less code, though?

Just squinting at the code to see the shape of it rather than worrying about the contents, the C blocks look more distinct, to me.

[siscia]

probably every let's say "method" are cleaner, and you can actually say what is happening.

C is more dispersive...

Thought I code way more clojure than C