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.
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.