> Yes, I read the link. I'm going to hazard a guess that lisp is not your > native language :-)
I consider Lisp to be one of my favorite languages (if not my favorite), and I've been coding in it for several years. It's rather silly to assume something about someone's programming experience based on their code style. Sometimes you'd be right, and other times you'd be wrong, just as with any sort of stereotyping. > "Scope" is a very slippery concept in a language like lisp. > Where it does occur in obvious cases (e.g. a "let") you'll > find that lispers universally indent their code, just like everyone else. This I understand very well (as I mentioned in the post). It really has no bearing on the central argument though. It's only introduced as a guideline as to where you might want to consider trailing your parens. > That's a very personal issue and I don't think I've ever struggled to > understand code based on the outdenting style. > I think I've said that several times now. :-) I actually do like the succinctness of stacked parenthesis, but unfortunately that style has many shortcomings that I find rather annoying. Again, to each his own. Sincerely, Greg Slepak On Aug 18, 2010, at 2:49 PM, Tim Daly wrote: > > > Greg 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. >> > In lisp it is functions all the way down. Defining functions > that introduce "scope" and having them outdent is odd. > > Some of those functions could be macros which introduce > lexical or dynamic scope. Should functions that are macros > use outdenting? Maybe some should, such as (with-open-file...) > but I often have macros that introduce binding blocks yet they > appear to the user to be a function. (e.g. the MyFactory macro) > > "Scope" is a very slippery concept in a language like lisp. > Where it does occur in obvious cases (e.g. a "let") you'll > find that lispers universally indent their code, just like everyone else. >> Again, the link goes much more into depth on this. >> > Yes, I read the link. I'm going to hazard a guess that lisp is not your > native language :-) >> 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. >> > Well, if all else fails, try (pprint your-expression) and see what the > canonical version is. > > The modelling clay (lisp) doesn't care, it reflects the shape of your > thoughts. > If you want brick shapes (java), the lisp reader won't care. > > Your claim seems to be that outdented code in brick form is easier to read > and understand. > That's a very personal issue and I don't think I've ever struggled to > understand code based > on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to > stumble :-) ) > > I do think it is interesting that most of the code snippets I see posted here > in Clojure > do not tend to use outdenting brace style. And when I look at core.clj I > don't see any > outdenting going on but I find the code highly readable. In fact, I can't > find a single > instance of outdenting anywhere in src/clj/clojure. Rich has obviously > discovered > his inner lisp. > > Anyway, since this is a "religious issue" with no resolution I can only > recommend: > http://www.youtube.com/watch?v=5-OjTPj7K54 > > Beware the lightning :-) > > Tim Daly > > > >> - Greg >> >> ------------------------------------------------------------------------ >> >> >> 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
