[brudgers]

If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants.

There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as functions in the function position of an x-expression. There are things Clojure will not do such as reader macros. Clojure's syntax is a bit different, but generally reads cleaner in the same way one might say a font reads cleaner. YMMV.

[_19qg]

> lists and other seq's as functions in the function position of an x-expression.

Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.

Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.

Pays back it code maintenance over time...

> but generally reads cleaner in the same way one might say a font reads cleaner.

I think it reads cleaner in the way PERL code is read cleaner.

[brudgers]

Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.

Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.

[int_19h]

Arrays are functions, by definition. They relate inputs to outputs.

[lispm]

That does not mean I want them in a programming language to be functions.

[int_19h]

I guess I just don't see a disadvantage. An array is a pure function, no side effects, so it should always be safe to treat it as one.

[lispm]

One disadvantage: you can't inline the code for such a vector reference, unless the compiler knows at compile time that this is a vector reference.

[int_19h]

But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.