Personally, I don't think the problem for non-Lispers is with the number of parentheses so much as with the *depth* of parens-nesting and having to invert the reading order, starting from the deepest s-expr and reading your way back out.
I'm still very new to Clojure (basically I have only been paying close attention to it for a few weeks, and have not written any substantial Clojure code yet), and I come from ten years of programming the usual non-Lisp Python/Java/JavaScript/C-style languages. But I can honestly say that reading Clojure code comes very naturally for me now, as long as I'm familiar with all the functions in an expression, and I assure you that it's certainly not that I'm special or particularly bright. Interested programmers are willing to learn different syntaxes - judging from the number of apps, there are probably at least fifty thousand programmers who were willing to look past all the square brackets in Objective-C so that they could write iPhone apps. What I think makes it difficult to approach an S-expression isn't the parentheses, but the fact that you often have to read it in an inverse order, or maintain a mental stack of functions that have been applied so far. For me, this is especially the case when function calls are nested very deeply. I'm not familiar with it, but from your example it appears that the ->> macro lets the code be written in an order which is not inverted. Furthermore, the first example "looks" like it has more parens than the ->> example, even though it actually has fewer, because of its deeper nesting - so it's easier to read through what's happening in the ->> example, without having to maintain a mental stack of what functions have are being applied to the expression. For interested programmers new to Clojure, I would think this is way more useful than reducing the number parentheses. e PS: I use the term "interested programmers" above because I don't think Clojure will ever appeal to a programmer who isn't interested in learning something new. The syntax is the easy part. The hard part is learning a different approach to designing and structuring programs. On Fri, Dec 18, 2009 at 2:07 PM, Martin Coxall <pseudo.m...@me.com> wrote: > I had this thought at work, when I should have been working, so please bear > with me if it's nonsense. > > One of the things that always puts people off of Lisp, as we all know, are > the parentheses. Now, many ways have been suggested of doing this in other > Lisps, but have never taken off, mainly due to inertia and a fear of > sacrificing homoiconicity. > > However, I love Clojure, and want to see it really take off. And so I want to > see all barriers to that removed. Also, I think the language is young enough > that seemingly-but-not-really radical proposals can still be sneaked in. > > Let's take this example, since I note that Rich Hickey weighed in in the > comments: > > http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html > > (apply merge-with + > (pmap count-lines > (partition-all *batch-size* > (line-seq (reader filename))))) > > This little snippet has ten parentheses. And is potentially very unnerving to > a non-lisper. Ten parentheses in four lines seems a lot to most programmers. > > Rich, in the comments, suggests a pipelined style to make the code more > readable: > > (->> (line-seq (reader filename)) > (partition-all *batch-size*) > (pmap count-lines) > (apply merge-with +)) > > > I accept that this is more readable because it has less nesting. But it now > has *12* parentheses, more than the original, potentially just as alarming to > the Lispophobes. > > My question is this: why can't we introduce a simple and importantly, > optional 'off-side rule' (much simpler than Haskell's) that allows the reader > to infer many of the parentheses? > > A very simple offside rule could turn the original into: > > apply merge-with + > pmap count-lines > partition-all *batch-size* > line-seq (reader filename) > > > With a startling two parentheses and Rich's corrected version into: > > ->> > line-seq (reader filename) > partition-all *batch-size* > pmap count-lines > apply merge-with + > > > Also with two. That last example in particular looks splendidly readable. > Almost... monadic. > > The parenthesis inference here is very simple, and could be stated in two > sentences: > > For each line that is not within a vector, and does not have an opening > parenthesis, infer an opening parenthesis at the start of the line. Remember > the level of indentation, and infer a closing parenthesis at the end of the > line *before* the next line whose indentation is the same as or less than the > remembered one. > > My question is: why would such a scheme work/not work, and why would/would > not it be desirable? > > Martin > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
