There's something very off about working with a lisp and not being able to inject stateful inline expressions for prototyping. In other lisps you find the fluid abstraction/computational nature of sexps holding up very nicely while in Clojure you find yourself having to rewrite larger portions of functions just to test or fix something. A lot of my turnoffs from Clojure is that it takes away the whole "geometrical logic glue" aspect of sexps and leaves behind what feels like a neutered stack-based language for the JVM in lisp's clothing.
Hmmmm; I haven't worked with Clojure enough, and that after a decade break from programming and several from serious LISP programming, but ... while I like it, I don't find it very tasteful in many ways, including that very sort of way. It's a language I like to program in, but not one I think I'll ever fall in love with like mainline LISP and then Scheme.
While I very much like the first class syntax for arrays, maps, and sets, there's a tremendous advantage to having one main or even exclusive built in composite data type, e.g. I hear that a strength of Lua, which I gather has been very successful. LISP's DNA, as well as Scheme's I'm pretty sure, was established in the days when that was lists.
Clojure tried to push the homoiconicity as a first class rule, so it felt logical to have a literal for built-in types. But at the same time I .. how to say that, don't want syntax. First lisps had the minimum of it: sexp, symbol. jmc lisp stopped there, they then added numbers and strings for ergonomic sanity[1], and it feels the right balance, the proximity of metalevel and language, the adt/dsl feel since everything will be an sexp based abstraction (SICP ate my mind?).
So clojure tried principled consistency, I like the logic of it, but not the result. Erik Meijer and Brett Victor claim it's a good thing to do. Find a concept and go all the way down with it.
[1] it would be fun to be denotational even for these. (arithmetic-sum (number two one three) (number six six six)), yes it would be.
But I think people like us have to accept that many other people hate a sea of parens to the point they violently reject LISPs (e.g. http://ancell-ent.com/images/parens.png) ; my question WRT to Clojure is, how many of them have come on board in part due to adding to and in some cases changing the (nearly) pure s-expression syntax we love?
If a fair number have, I'm willing to accept it for the benefit of "Lisp", for Clojure has created the greatest movement in "Lisp" since the Lisp Machine and microprocessor heyday of the '80s.
Ah, I might add that for me, the REPL style of programming is my #1 feature. One of my greatest programming feats what with CodeCenter/ObjectCenter, an interpretive environment for C/C++, where I ported a scanner driver and rewrote the engine for monster Kodak document imaging scanners in 3 weeks. The very first time I hooked up one of these 600 pound, bigger than a washing machine scanners and hit the "Go" button it worked all the way through to writing files.
Well, until I ran out of file descriptors, forgot a close() ^_^. But I found being able to do that rather impressive, granted, I'd been working on the lower level SCSI code for a couple of years with optical drives and scanners.
That image fails at making its point however. Even without the brackets, who considers "cond = 1 ag ad recurse carry augend addend 1" a beautiful line of code?
IMHO, without parens you will end up aiming for ml and matching. Otherwise removing everything will turn anything into ...
Without punctuation:
int thing int a int b while c = a ++ > b b = 0 a = b + c return c
Well almost gibberish, I have to admit, infix and some mandatory keyword do help. But Lisps have this tendency to be structural ... so their syntax and idioms go along with that very often. It's somehow twisted to remove that from them.
Without types:
thing a b while c = ++ a > b b = 0 a = b + c return c
Without most operator symbols:
thing a b while c eq inc! a > b b = 0 a = sum b c return c
Keeping the process
thing a b while c eq inc! a > b b isnow 0 a set-to sum b c return c
thing a b while c eq inc! a gt b b isnow 0 a isnow sum b c c
Recovering a bit of alternative syntax:
(int thing int a int b) while (c = a ++ > b. b = 0) a = b + c return c
Nope. Tried Gun Emacs with such a mode for a bit recently because that came as a default in a Clojure editing recipe I found, but having using versions of EMACS to edit LISP since 1980 I found it more annoying than helpful, there are times when I want to mangle the text and fix the parens afterwards.
For me the two keys are smart indention and the habit of counting off each opening paren at the beginning of an indented line as I close it. I did this sort of work on GoldHill's EMACS clone in the brief period I worked for them, getting it to blink the opening paren when the point is positioned to the right of the closing paren.
Clojure explicitly makes '()' and '[]' different, as well as a few other delimiters. '(1 2 3) is a list like in Lisp tradition, but [1 2 3] is a vector. That is the syntax that the parent is talking about.
Yes, specifically [:whatever] is syntactic sugar for (vector :whatever) and {:what :ever} is syntactic sugar for {array-map :what :ever}. CL has the #() syntactic sugar for the first and the #'acons syntactic sugar for the second. So, in fact, Clojure is no more unLISPy than CL in the most quoted respect.
(Quote from CLtL: Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.)
