On Aug 18, 2010, at 8:05 PM, Cyrus Harmon wrote: > but I shudder to think what it would be like to read the code for doseq or > destructure if each closing parenthesis were on its own line.
Good thing no one suggested that. :-) > And, as for writing code, I couldn't live without paredit. What would you do without it? - Greg > > I'm reminded gigamonkey's footnote about when functions get too big: > > "A friend of mine was once interviewing an engineer for a programming job and > asked him a typical interview question: how do you know when a function or > method is too big? Well, said the candidate, I don't like any method to be > bigger than my head. You mean you can't keep all the details in your head? > No, I mean I put my head up against my monitor, and the code shouldn't be > bigger than my head." [1] > > There are many different styles for source code, but my experience with lisp > suggests that variable indentation (as provided by emacs lisp-mode or > clojure-mode) and parens-not-on-their-own-line makes for much more readable > code. core.clj is a good example where the code is generally readable, but I > shudder to think what it would be like to read the code for doseq or > destructure if each closing parenthesis were on its own line. > > And, as for writing code, I couldn't live without paredit. > > To each their own, but let's not go down the route of saying "hey, you're > code formatting style sucks, but I don't want to start a flame war" :). > > Cyrus > > 1. http://www.gigamonkeys.com/book/practical-a-simple-database.html > > On Aug 18, 2010, at 6:24 PM, wwmorgan wrote: > >> The Incanter example is confusing for the same reason that the >> Leiningen example from the blog post is confusing, and I don't think >> paren style matters at all. The functions have grown over time, >> they're now too big, and they need to be refactored into several >> smaller functions. The paren style is a red herring. core.clj is >> readable because its functions are short. >> >> When your code makes you want to outdent, you can take this as a >> signal that your function has gotten too big and needs to be >> refactored. >> >> - Will Morgan >> >> On Aug 18, 4:36 pm, Greg <g...@kinostudios.com> wrote: >>>> Now the question you're asking is, why don't lispers write >>>> (MyFactory somearg >>>> ) >>>> which makes me cringe. >>> >>> That's not at all what's being suggested -- you'll find that both in the >>> OP's code and in the link below, there are many locations where closing >>> parenthesis are ended on the same line. >>> >>> Trailing parens are placed only for certain blocks that traditionally would >>> define a "scope" in another language, and this is convenient for many >>> reasons, including generic reasons not attached to any specific language. >>> It's not about carrying over "much loved C style" to Lisp, but to make >>> actual use of parenthesis for the purpose of clearly outlining the >>> structure of your code. >>> >>> Again, the link goes much more into depth on this. >>> >>> Attached is a screenshot of some code from the wonderful Incanter library. >>> I think it's a great illustration of how confusing stacking parenthesis can >>> be (there are many functions in there that are like this). >>> >>> The readability issue occurs when there's a drop in several indentation >>> levels after many lines. This is a problem regardless of what the >>> indentation width is, but is certainly made worse by a small indentation >>> width. >>> >>> - Greg >>> >>> Screen shot 2010-08-18 at 1.32.09 PM.png >>> 48KViewDownload >>> >>> >>> >>> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: >>> >>>> A more serious answer is that when I code in Java I use the >>>> brace-on-a-line kind of indentation. When I code in Lisp I >>>> never write single-line parens of any kind. >>> >>>> I find that I think differently in each language. >>> >>>> My Java code is always a pile of declare-this, do-this, do-this, return >>>> Thus I find that I'm delimiting the scope of my variables, marking my >>>> control flow and branching logic, try/catch logic, class boundaries, etc. >>> >>>> My Lisp code mixes control flow and data structures in the same syntax. >>>> Thus the idea that parens are some kind of control flow delimiter is >>>> not particularly meaningful. >>> >>>> To see the alternative case, take a Java program, find every function call >>>> such as: >>>> MyFactory(somearg); >>>> throw away the ';', and move the paren left to get: >>>> (MyFactory somearg) >>> >>>> Now the question you're asking is, why don't lispers write >>>> (MyFactory somearg >>>> ) >>>> which makes me cringe. >>> >>>> A second reason is that Lisp allows you to think things that Java >>>> does not. Java has this imperative, object-oriented, hierarchical >>>> style of writing. My lisp code sytle varies to fit the problem. >>>> Sometimes it is imperative, sometimes functional, sometimes OO, >>>> sometimes snobol-like pattern matching, sometimes class-based. >>>> Occasionally I dynamically construct the code and execute it inline. >>>> Or I use macros to create my own problem language and code in that. >>>> And I create my data structures "on the fly" inline to the code. >>> >>>> Once you really internalize lisp there are no real constraints >>>> on what you think or write. Thus there is no question of "bracing >>>> style" that is meaningful. >>> >>>> The whole idea of "bracing style" is Java-think. Your language >>>> choice has given you an OO-procedural mindset. So when you reach >>>> for Lisp you want to see what you have come to expect. People who >>>> work with bricks (Java) tend to wonder why they don't find bricks >>>> among people who work with modelling clay (Lisp). The answer isn't >>>> in the material, it is in your mindset. >>> >>>> Just by looking at lisp code I can tell what your native language >>>> is. Fortran programmers simulate COMMON blocks, C programmers use >>>> things as pointers, etc. "You can write Fortran in any language" >>>> is a famous quote but "you can't write Lisp in any language". And >>>> you can quote me on that. (But only in my obituary :-) ) >>> >>>> In fact, I think that this is going to be the hardest barrier >>>> to the adoption of Clojure. "Real Java Programmers" are not going >>>> to like the bracing style (or lack thereof) in Clojure. >>> >>>> Tim Daly >>> >>>> Greg wrote: >>>>> It's almost purely community convention that has been adopted from Lisp. >>> >>>>> You may be interested in this link: >>> >>>>> http://gregslepak.posterous.com/on-lisps-readability >>> >>>>> There is much discussion about this topic there. >>> >>>>> Cheers, >>>>> Greg >>> >>>>> On Aug 18, 2010, at 2:09 AM, michele wrote: >>> >>>>>> Wouldn't that make it easier to keep track of them. >>> >>>>>> Example: >>> >>>>>> (defn myfn-a [a b] >>>>>> (if (zero? b) >>>>>> a >>>>>> (recur >>>>>> (afn (bfn (...)) a) >>>>>> (dec b)))) >>> >>>>>> (defn myfn-b [a b] >>>>>> (if (zero? b) >>>>>> a >>>>>> (recur >>>>>> (afn (bfn (...)) a) >>>>>> (dec b) >>>>>> ) >>>>>> ) >>>>>> ) >>> >>>>>> -- >>>>>> 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 >>> >>> >> >> -- >> 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 -- 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
