Re: Lisp/Scheme Style Guide
It would be _nice_ to have a default that was the baseline format. The Canon of Clojure Conventional Conformity (). If an org or project wanted to have a different format, they could supply it as a plugin to the clojure-fmt tool. (set-format local-conventions) When the format gets applied, etc is up to the smart people. It would make sense to me that (set-format ...) is for the physical representation of the file on disk and in version control, etc. If my IDE understood (set-format ...) I could *view* and *edit* in my preferred format (local project or IDE setting), I would never know or care about the underlying representation. Does that make sense? If Clojure was stored in an opaque binary container we wouldn't care, everyone's viewer/editor would adjust. The physical representation would cease to matter. On Sep 5, 2010, at 8:06 PM, Daniel Gagnon wrote: I think it would be great if an official clojure-fmt tool existed. I have no interest in forcing people to use it who don't want to. But I think it would set a great baseline for IDEs and would be helpful to the people and teams who like having coding standards. I would be one of a number of people who would voluntarily use such a tool. I would too because I prefer a good and predictable format to a perfect one I'm the only one to use. Also if that tool is customizable, people could use it format source to their own preferences out of git when they pull and format it back when they push. I don't think there's something special about Python that makes it more suitable to something like PEP 8. If Python users were like Lisp users, they'd bicker incessantly about how how much space in indentation but Guido said it's 4 spaces and that's it. I don't believe we can find *the* one style but I would like someone with sufficient clout to suggest *a* style. -- 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
Re: Lisp/Scheme Style Guide
An interesting candidate for this is the current clojure.contrib.pprint tool. It should be adapted to not only grok clojure forms, but also strings, of course (and this may not be that easy), so that nothing in the source code is lost during the parsing ... 2010/9/6 sitk...@gmail.com: It would be _nice_ to have a default that was the baseline format. The Canon of Clojure Conventional Conformity (). If an org or project wanted to have a different format, they could supply it as a plugin to the clojure-fmt tool. (set-format local-conventions) When the format gets applied, etc is up to the smart people. It would make sense to me that (set-format ...) is for the physical representation of the file on disk and in version control, etc. If my IDE understood (set-format ...) I could *view* and *edit* in my preferred format (local project or IDE setting), I would never know or care about the underlying representation. Does that make sense? If Clojure was stored in an opaque binary container we wouldn't care, everyone's viewer/editor would adjust. The physical representation would cease to matter. On Sep 5, 2010, at 8:06 PM, Daniel Gagnon wrote: I think it would be great if an official clojure-fmt tool existed. I have no interest in forcing people to use it who don't want to. But I think it would set a great baseline for IDEs and would be helpful to the people and teams who like having coding standards. I would be one of a number of people who would voluntarily use such a tool. I would too because I prefer a good and predictable format to a perfect one I'm the only one to use. Also if that tool is customizable, people could use it format source to their own preferences out of git when they pull and format it back when they push. I don't think there's something special about Python that makes it more suitable to something like PEP 8. If Python users were like Lisp users, they'd bicker incessantly about how how much space in indentation but Guido said it's 4 spaces and that's it. I don't believe we can find *the* one style but I would like someone with sufficient clout to suggest *a* style. -- 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
Re: Lisp/Scheme Style Guide
In an effort to paint the shed until it crumbles I will stoke the engine of discourse with starter fluid. I see a couple issues that probably *should* be resolved within the community and once resolved can be pointed to as Canon of Clojure Conventional Conformity (). bla bla wadler's law ... 1) People like to format, name etc their code differently. Lets all verb a noun and call it syntaxing because I think that is an apropos name. 2) People don't agree on (1), see wadler's law 3) Other languages have solved this using various mechanisms a) Python doesn't really have this problem b) Perl is using http://perltidy.sourceforge.net/ So I make the following proposal. Just a sketch, the blanks need to be filled in. A syntax formatting definition file is created that declares what flavor of layout you enjoy, your source files are declared to be in that format. (set-format Leibnitz) (set-format icanhazcheeseburger) A tool is created to convert from one format to the other. Your IDE would present code in *your* format, the universe is perfect in your eyes, rainbows match your kitchen The version control system would merge/patch/commit code in the *tree's* format Everyone is happy, syntax continues not to matter (for the most part). This issue does need to get resolved, at least in the context of Clojure. There are so many different ways that programmers, I meant monkies that encode ideas in s-expressions can represent those ideas *and* arbitrarily decide that their butter side side up is sooo much more awesome than the other guys butter side down. If this keeps up Clojure will become Common Lisp and we might as well add in reader macros and call it good. If we can push through this hard time and come back out on the other side a stronger Lisp there won't be anything that can stop us. Go team! On Sep 1, 2010, at 9:59 AM, Alan wrote: I'm afraid if I write my code while this thread is going on, I'll just have to reformat all of it once the discussion has settled this decades-old argument. On Sep 1, 9:45 am, ataggart alex.tagg...@gmail.com wrote: This is so terribly boring. Don't you guys have any code to write? -- 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
Re: Lisp/Scheme Style Guide
a) Python doesn't really have this problem Python doesn't have this problem because the canonical style is define by PEP 8 and Pythonistas love simplicity through conventions. PEP 8: http://www.python.org/dev/peps/pep-0008/ I think it's actually a great feature of the language, I almost never got code that didn't match or nearly matched PEP 8. Google's go goes even further by having the canonical style define by gofmt. Once your code is written, you run it through gofmt and it turns canonical. If your code doesn't look nice after gofmt, you must file a bug against gofmt rather than hand tweak the formatting. I'd be all for having clojure-fmt that would format clojure code in the way Rich prefers it so that when I get random code I could convert it to a nice and predictable format. It should be even simpler to write for a lisp than other languages. -- 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
Re: Lisp/Scheme Style Guide
I'd be all for having clojure-fmt that would format clojure code in the way Rich prefers it so that when I get random code I could convert it to a nice and predictable format. It should be even simpler to write for a lisp than other languages. See Guy Steele Common Lisp, The Language pp748-769 Pretty Printing This facility is the culmination of thirteen years of design, testing, revision and use of this approach -- Steele This problem has a long history and a lot of thought in the lisp community. It would be trivial to have slime automatically prettyprint every expression. It would be trivial to define a canonical style for clojure. The problem isn't technical at all. The problem is social. Actually, the problem is that I don't know any lispers who could consider it a problem worth thinking about, although they spent 13 years not thinking about it. Prettyprinting lisp code is a homework assignment. Getting every lisper to agree is a United Nations summit meeting. There are so many things you can think in lisp that you can't even think in other languages. For instance, define a function (defun foo () ) define private variables only accessible to certain functions (let (x) (defun foo1 () x) (defun foo2 () x) define classes with private variables and local methods (defun classname () (let (x) (defun method () x))) define modules with global private variables, classes and private variables local to the classes. (let (y) (defun class1 () (let (x-class1-private) (defun class1-method-1 () ) (defun class1-method-2 () ))) (defun class2 () (let (x-class2-private) (defun class2-method-1 () ) (defun class2-method-2 () It is possible to do all of that without using any new language extentions. Java won't allow naked functions and I don't see a way to make modules except with compile-time package naming. Python has different, but equally limiting, restrictions on what you can think and how you can think about it. Lisp allows you to think of these ideas and then write code to structure the ideas. The layout of the code mirrors the ideas. As in architecture, Form follows function and lisp allows you complete freedom of both so I don't think you can ever define a form that will be useful and general. Now we come to the debate about style. The indentation shown above has meaning in that it shows you what I intended for each level of structure. If your pretty-printer says that all (defun) forms (well, (defn) forms) are required to start in column 1 then this loses the semantics of my nesting. There are no general rules that cover all of the things I can think in lisp. That makes lisp completely different from python or java. The ONLY general rule about lisp code formatting I know is that the other guy's code is badly formatted :-) Tim Daly Daniel Gagnon wrote: a) Python doesn't really have this problem Python doesn't have this problem because the canonical style is define by PEP 8 and Pythonistas love simplicity through conventions. PEP 8: http://www.python.org/dev/peps/pep-0008/ I think it's actually a great feature of the language, I almost never got code that didn't match or nearly matched PEP 8. Google's go goes even further by having the canonical style define by gofmt. Once your code is written, you run it through gofmt and it turns canonical. If your code doesn't look nice after gofmt, you must file a bug against gofmt rather than hand tweak the formatting. I'd be all for having clojure-fmt that would format clojure code in the way Rich prefers it so that when I get random code I could convert it to a nice and predictable format. It should be even simpler to write for a lisp than other languages. -- 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
Re: Lisp/Scheme Style Guide
On Sun, Sep 5, 2010 at 1:08 PM, Daniel Gagnon redalas...@gmail.com wrote: I'd be all for having clojure-fmt that would format clojure code in the way Rich prefers it so that when I get random code I could convert it to a nice and predictable format. It should be even simpler to write for a lisp than other languages. I think it's unfortunate that all three IDEs/plugins I have tested (Emacs Clojure mode, Netbeans Enclojure, IntelliJ La Clojure) have slightly different indenting conventions. Furthermore, all of them have certain holes in their indenting treatment -- for example, I posted many months ago that the letfn construct was a source of difficulty for most or all of the plugins I had tried. I think it would be great if an official clojure-fmt tool existed. I have no interest in forcing people to use it who don't want to. But I think it would set a great baseline for IDEs and would be helpful to the people and teams who like having coding standards. I would be one of a number of people who would voluntarily use such a tool. -- 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
Re: Lisp/Scheme Style Guide
I think it would be great if an official clojure-fmt tool existed. I have no interest in forcing people to use it who don't want to. But I think it would set a great baseline for IDEs and would be helpful to the people and teams who like having coding standards. I would be one of a number of people who would voluntarily use such a tool. I would too because I prefer a good and predictable format to a perfect one I'm the only one to use. Also if that tool is customizable, people could use it format source to their own preferences out of git when they pull and format it back when they push. I don't think there's something special about Python that makes it more suitable to something like PEP 8. If Python users were like Lisp users, they'd bicker incessantly about how how much space in indentation but Guido said it's 4 spaces and that's it. I don't believe we can find *the* one style but I would like someone with sufficient clout to suggest *a* style. -- 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
Re: Lisp/Scheme Style Guide
In an effort to paint the shed until it crumbles I will stoke the engine of discourse with starter fluid. I see a couple issues that probably *should* be resolved within the community and once resolved can be pointed to as Canon of Clojure Conventional Conformity (). bla bla wadler's law ... 1) People like to format, name etc their code differently. Lets all verb a noun and call it syntaxing because I think that is an apropos name. 2) People don't agree on (1), see wadler's law 3) Other languages have solved this using various mechanisms a) Python doesn't really have this problem b) Perl is using http://perltidy.sourceforge.net/ So I make the following proposal. Just a sketch, the blanks need to be filled in. A syntax formatting definition file is created that declares what flavor of layout you enjoy, your source files are declared to be in that format. (set-format Leibnitz) (set-format icanhazcheeseburger) A tool is created to convert from one format to the other. Your IDE would present code in *your* format, the universe is perfect in your eyes, rainbows match your kitchen The version control system would merge/patch/commit code in the *tree's* format Everyone is happy, syntax continues not to matter (for the most part). This issue does need to get resolved, at least in the context of Clojure. There are so many different ways that programmers, I meant monkies that encode ideas in s-expressions can represent those ideas *and* arbitrarily decide that their butter side side up is sooo much more awesome than the other guys butter side down. If this keeps up Clojure will become Common Lisp and we might as well add in reader macros and call it good. If we can push through this hard time and come back out on the other side a stronger Lisp there won't be anything that can stop us. Go team! On Sep 1, 2010, at 9:59 AM, Alan wrote: I'm afraid if I write my code while this thread is going on, I'll just have to reformat all of it once the discussion has settled this decades-old argument. On Sep 1, 9:45 am, ataggart alex.tagg...@gmail.com wrote: This is so terribly boring. Don't you guys have any code to write? -- 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
Re: Lisp/Scheme Style Guide
On Tue, Aug 31, 2010 at 1:52 PM, Greg g...@kinostudios.com wrote: Can we please drop this? No offense Greg, but yes, please, drop this. By replying, all you've done is perpetuate this :( It's clear you don't agree (with lots of other people's opinions) and we get that. Style is personal - do what makes you happy. But we really don't need to keep discussing this (do we?). FWIW, I blogged a Clojure example (for my, mostly, CFML audience) and someone complained the code was over formatted but it came straight out of Eclipse after CCW had formatted it. Clearly a personal preference... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Re: Lisp/Scheme Style Guide
I guess much of this comes down to style. I find xml-http-request easier to read and consistent with the english language practice of using hyphens to join words in compound modifiers. But my point regarding XMLHttpRequest was regarding the seemingly arbitrary and difficult to remember (for me at least) uppercasing of the letters in XMLHttpRequest. That choice seems no more valid than XMLHTTPRequest or XmlHttpRequest, all of which I find much harder on the eyes, and more difficult to type, than xml-http-request. Cyrus On Sep 1, 2010, at 1:23 AM, Mark Engelberg wrote: On Tue, Aug 31, 2010 at 3:38 PM, Cyrus Harmon cyrushar...@gmail.com wrote: XMLHttpRequest vs. xml-http-request. I rest my case. I'm not even sure what case you're making, let alone what side you're resting for. :-/ -- 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
Re: Lisp/Scheme Style Guide
Fogus, I believe it is you who is confused. The painter is responsible for everything about the painting. Where the brush strokes are placed, how they are used, the medium that is used, the brush widths, and everything else. If his point was to paint a bridge he could have done it through a variety of methods, using a variety of tools, a variety of strokes, and different points of view. It is the art collector who then takes the finished masterpiece and decides whether it is upside-down or not. - Greg On Aug 31, 2010, at 7:34 PM, Fogus wrote: It would be a tragedy if The State ordered Picasso to make his paintings more realistic I think your confusing the virtue in shuffling parentheses around. If you want to place your parentheses on their own line then more power to you, it's your style -- but don't confuse it with making high art. The beauty is in the painting, not in the fact that you choose to hang it upside-down. :f -- 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
Re: Lisp/Scheme Style Guide
On Wed, Sep 1, 2010 at 11:07 AM, Greg g...@kinostudios.com wrote: Fogus, I believe it is you who is confused. The painter is responsible for everything about the painting. Where the brush strokes are placed, how they are used, the medium that is used, the brush widths, and everything else. If his point was to paint a bridge he could have done it through a variety of methods, using a variety of tools, a variety of strokes, and different points of view. It is the art collector who then takes the finished masterpiece and decides whether it is upside-down or not. - Greg Comparing code formatting to painting practice is a poor metapor at best. Also, Art is not individualistic practice - it is entrenched in communities and conventions, otherwise it would be unable to communicate. By the simple fact that the form of painting has been chosen - not sculpture, performance, installation, video, or multimedia - would in many Art circles denote a clear sign of odious conventionalism. Regardless of form, there is such a thing as outsider art. But as with code, it usually means few people care, regardless of it's valid subjective merit for the small audience that wishes to take the time to appreciate it. In both art and code what most people enjoy the most is the element of novelty, play, and even destructiveness within the bounds of well known conventions and accepted constraints. It's a question of balance, not absolutes. Also, it would add to your credibility if you contributed more often to conversations not based around the fairly superficial topic of paren placement. Clojure has far, far more interesting and deeper avenues of discussion to offer. David -- 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
Re: Lisp/Scheme Style Guide
On Sep 1, 2010, at 8:33 AM, David Nolen wrote: Comparing code formatting to painting practice is a poor metapor at best. The comparison is between programming and painting. Code formatting is being compared to the various artistic decisions involved in painting. I think it is a very apt metaphor. The author is solely responsible for these decisions, he (or she) decides what the right medium, method, and perspective to take, and it is their point of view that is then considered to be correct, not the art collector's. Regardless of form, there is such a thing as outsider art. But as with code, it usually means few people care, regardless of it's valid subjective merit for the small audience that wishes to take the time to appreciate it. All of the greats started out as outsiders, practically by definition. The were regarded as the fathers (or mothers) of their respective styles or art forms. Code, is ultimately turned into colorless 0's and 1's. If there is any human element to the code itself, it is in the code style and the architectural decisions. As an architect is not only responsible for ensuring the building is built in a sound manner, capable of withstanding earthquakes and storms, so too are they responsible for the aspects of the building that have absolutely nothing to do with function, and everything to do with form. It is this human element that is appreciated. Also, it would add to your credibility if you contributed more often to conversations not based around the fairly superficial topic of paren placement. Clojure has far, far more interesting and deeper avenues of discussion to offe I very much agree, and I can't wait to do so! - Greg On Wed, Sep 1, 2010 at 11:07 AM, Greg g...@kinostudios.com wrote: Fogus, I believe it is you who is confused. The painter is responsible for everything about the painting. Where the brush strokes are placed, how they are used, the medium that is used, the brush widths, and everything else. If his point was to paint a bridge he could have done it through a variety of methods, using a variety of tools, a variety of strokes, and different points of view. It is the art collector who then takes the finished masterpiece and decides whether it is upside-down or not. - Greg Comparing code formatting to painting practice is a poor metapor at best. Also, Art is not individualistic practice - it is entrenched in communities and conventions, otherwise it would be unable to communicate. By the simple fact that the form of painting has been chosen - not sculpture, performance, installation, video, or multimedia - would in many Art circles denote a clear sign of odious conventionalism. Regardless of form, there is such a thing as outsider art. But as with code, it usually means few people care, regardless of it's valid subjective merit for the small audience that wishes to take the time to appreciate it. In both art and code what most people enjoy the most is the element of novelty, play, and even destructiveness within the bounds of well known conventions and accepted constraints. It's a question of balance, not absolutes. Also, it would add to your credibility if you contributed more often to conversations not based around the fairly superficial topic of paren placement. Clojure has far, far more interesting and deeper avenues of discussion to offer. David -- 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
Re: Lisp/Scheme Style Guide
This is so terribly boring. Don't you guys have any code to write? -- 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
Re: Lisp/Scheme Style Guide
On Sep 1, 2010, at 9:45 AM, ataggart wrote: This is so terribly boring. Don't you guys have any code to write? A similar question may be asked of you. Do you not have anything better to do than complain? If you find this thread boring, why are you 1) reading it, and 2) replying to it and thereby keeping it alive? - Greg -- 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
Re: Lisp/Scheme Style Guide
I'm afraid if I write my code while this thread is going on, I'll just have to reformat all of it once the discussion has settled this decades-old argument. On Sep 1, 9:45 am, ataggart alex.tagg...@gmail.com wrote: This is so terribly boring. Don't you guys have any code to write? -- 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
Re: Lisp/Scheme Style Guide
Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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
Re: Lisp/Scheme Style Guide
The concept of the One-Style-To-Rule-Them-All is just childish. It is akin to the enforcement of school uniforms, and in many ways perhaps worse. The imposition of aesthetic preferences upon others is likely to result in the following: - A counter-reaction, such as argument, insults, flame wars - Animosity amongst members of the group - Noise on the channel - The fostering of a militant, prickly community (i.e. the one that LISP is famous for) Clojure is an opportunity to depart from all of that. - Greg On Aug 31, 2010, at 1:52 PM, Greg wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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
Re: Lisp/Scheme Style Guide
The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 -- 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
Re: Lisp/Scheme Style Guide
On Tue, Aug 31, 2010 at 4:52 PM, Greg g...@kinostudios.com wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: I'd like to quickly point out, that you attempt to put an end to the discussion, and then offer opinion. That's a great way to *start* the conversation. -- http://www.apgwoz.com -- 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
Re: Lisp/Scheme Style Guide
I apologize for apparently re-opening some fresh wounds. I wasn't trying to assert that these guidelines should be universally adopted or enforced. There are a number of conventions that exist for writing lisp, and I thought that this paper was interesting because it - collects and explicitly states many of these conventions which are rarely spelled out explicitly - attempts to explain some of the conventions that can be mystifying at first - offers genuinely good readability and maintenance reasons for some of the mentioned conventions but please, don't mis-understand my intentions, I see nothing wrong with personal coding idosynchronies, I myself have been known to drop the occasional ((fn [el] (body-which-uses el)) (form-which-defines-el)) just because I've grown tired of `let'. That said even if you don't follow common conventions it can be useful to know what they are. Sorry for troll baiting, it was not my intent. -- Eric Greg g...@kinostudios.com writes: The concept of the One-Style-To-Rule-Them-All is just childish. It is akin to the enforcement of school uniforms, and in many ways perhaps worse. The imposition of aesthetic preferences upon others is likely to result in the following: - A counter-reaction, such as argument, insults, flame wars - Animosity amongst members of the group - Noise on the channel - The fostering of a militant, prickly community (i.e. the one that LISP is famous for) Clojure is an opportunity to depart from all of that. - Greg On Aug 31, 2010, at 1:52 PM, Greg wrote: Can we please drop this? This is going to go nowhere fast, like other thread on closing parens on new lines. Whoever wrote this did a terrible job, at least WRT that topic. Not only did he misrepresent the trailing parenthesis style (not all parenthesis must be trailed), but the so-called rationale given for choosing stacked parens over trailed parens is laughably devoid of any rational thought: Rationale: The parentheses grow lonely if their closing brackets are all kept separated and segregated. - Greg On Aug 31, 2010, at 9:47 AM, Eric Schulte wrote: This is the best I've seen so I thought I'd share (pulled from a post on the guile mailing list) http://mumble.net/~campbell/scheme/style.txt (note: the attached copy opens in Org-mode in Emacs for easier reading) -- 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=enstyle.txt -- 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
Re: Lisp/Scheme Style Guide
Speaking of style conventions, am I the only one who finds it mildly irksome that in any Clojure code, half the identifiers are lisp-style-multiword-names while the other half are javaCamlCaseMethodNames. It feels so inconsistent. I'd be happier if Clojure just moved completely to caml case (takes up less width). Thoughts? -- 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
Re: Lisp/Scheme Style Guide
XMLHttpRequest vs. xml-http-request. I rest my case. On Aug 31, 2010, at 3:35 PM, Mark Engelberg wrote: Speaking of style conventions, am I the only one who finds it mildly irksome that in any Clojure code, half the identifiers are lisp-style-multiword-names while the other half are javaCamlCaseMethodNames. It feels so inconsistent. I'd be happier if Clojure just moved completely to caml case (takes up less width). Thoughts? -- 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
Re: Lisp/Scheme Style Guide
On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. He is making an objective claim about something that is totally, completely, subjective. Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective phenomenon that depends on the observer. In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact, to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while others lend themselves to a different one. Further, he doesn't really treat the word project with the sophistication it deserves. A code project is a rather complex thing. A single project may in fact be composed of multiple, disparate projects, written by different authors. How he can claim that Every project I know of has a style is beyond me and leads me to question how observant or aware he is of the code he has used, for practically every significant project that I've used, participated in, or created has relied on the integration of various other bits of code and libraries written by different authors with different styles. My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer. He is right about one thing though, and that is that so long as style is not a matter of language syntax, there will be people who bring up this discussion again and again because they are for some reason or other incapable of handling a different style of code, just like some time ago white people in America were incapable of allowing blacks to drink from the same drinking fountains as they. Therefore there are actually two solutions to this problem. One of them is apparently easy, and the other is hard. Either you: 1) Mandate code style to be a part of the language's syntax. or you: 2) Grow up and learn to accept the reality that some people think differently from you. It seems to me that the very spirit of LISP leans towards the second solution. LISP is, after all, a very dynamic, open, and extensible language. It does not mandate that you use very many special forms or constructs or keywords. It even allows the creation of new languages within itself. Such as spirit of freedom and openness is what I love about LISP, and why I think Mr. Arnold is mistaken. - Greg -- 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
Re: Lisp/Scheme Style Guide
On Tue, 31 Aug 2010 15:40:10 -0600 Eric Schulte schulte.e...@gmail.com wrote: I apologize for apparently re-opening some fresh wounds. I wasn't trying to assert that these guidelines should be universally adopted or enforced. There are a number of conventions that exist for writing lisp, and I thought that this paper was interesting because it - collects and explicitly states many of these conventions which are rarely spelled out explicitly - attempts to explain some of the conventions that can be mystifying at first - offers genuinely good readability and maintenance reasons for some of the mentioned conventions That was pretty much my impression as well - it was more a collection of stylistic best practices than a real style guide - at least until he gets down to Naming, at which point it starts becoming a bit more opinion than observed practices. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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
Re: Lisp/Scheme Style Guide
On Tue, 31 Aug 2010 15:41:13 -0700 Greg g...@kinostudios.com wrote: On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Except you didn't. At best, you ripped apart a straw man based. Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. He is making an objective claim about something that is totally, completely, subjective. Productivity and code quality are totally, completely, subjective? So all the many, many words written about things agile development, quality engineering, productivity measures, software lifecycles, and so on - are basically meaningless, because they're trying to improve things that are totally, completely subjective? Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. I'm willing to grant that one on slightly less solid ground. He's assuming that 1) the project chose a reasonable style, as opposed to one designed to obfuscate code, and 2) that the people involved are likewise not outliers, and can deal with any reasonable coding style. But granted that, his statement pretty much stands as is. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective phenomenon that depends on the observer. In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact, to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while others lend themselves to a different one. My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer. OK, maybe you're one of the outliers, and don't have any problems with reasonable (or even unreasonable) styles. Yeah, I can see how that would help you. I also regularly work on such projects myself, and changing styles in mid-stream is similar to changing languages in mid-stream: I have to reset how my mind parses things. That projects *have* style guides indicate that others also have this problem. Just like Ken said - adopting any single reasonable style causes me (and probably most people) a lot less grief than letting me use my (or them use their) preferred style but having to switch styles between files, or worse yet, functions. Either you: 1) Mandate code style to be a part of the language's syntax. or you: 2) Grow up and learn to accept the reality that some people think differently from you. And the reason for the posting: you missed a VERY common third alternative. Or at least, it's commonly suggested, though I don't know that any project has actually implemented it: 3) Have your scm format code to canonical form when it's checked in. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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
Re: Lisp/Scheme Style Guide
On Aug 31, 2010, at 5:26 PM, Mike Meyer wrote: Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. There is no straw man, I understood his point fully. People choose various styles for various reasons, and those reasons include productivity and code quality. I listed many reasons related to productivity and code quality in a blog post describing the reasons some choose to trail their parenthesis: http://gregslepak.posterous.com/on-lisps-readability It is also interesting to note, that among the responses to that post, it was brought up that some prefer to stack their parenthesis because it compactifies their code, thereby letting them see more code per-square inch of screen real-estate. They mentioned that this could be very useful if, for example, you're in a situation were you don't have a large screen to work on (i.e. a netbook). I think that's a very valid reason to prefer stacked parenthesis. It's rational and it relates to productivity. More power to them. I don't use a netbook though and usually code on a large monitor, so I can write using trailing parenthesis and get the added benefits that I mentioned in the post. To each his own! As someone once observed, programming is very much like painting or other artistic endeavors. It would be a tragedy if The State ordered Picasso to make his paintings more realistic, (Yes, we can see how you might imagine that to be a building, but We say it has to be done this way.), or to use a particular kind or brush or stroke. There is always controversy when someone steps outside the wall of How Things Are Done. But that is what makes life interesting and worthwhile. The same song played over and over eventually loses its magic. So there are both practical and philosophical reasons to embrace the existence of diversity in code style, and of all the languages out there, it would be ironic and most tragic if the language that facilitates the most freedom of expression, were to be hijacked by the Style Police. - Greg On Tue, 31 Aug 2010 15:41:13 -0700 Greg g...@kinostudios.com wrote: On Aug 31, 2010, at 2:35 PM, fin wrote: The concept of the One-Style-To-Rule-Them-All is just childish. Have you read Style is Substance? http://www.artima.com/weblogs/viewpost.jsp?thread=74230 No, I hadn't, thanks for the link. I tried to read the whole thing but stopped after reading what he considered to be logic. Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in fact quite questionable. I can rip them apart if you'd like: Except you didn't. At best, you ripped apart a straw man based. Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles. All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this statement is. People get very passionate about their preferred style, and if you ask them to write in another style they will complain and cringe and claim that some such or other capability of theirs is being hampered. Um, read the explanation: he's talking about productivity and code quality. He didn't say people didn't care about styles, or weren't passionate about styles. Which means you haven't addressed his issues, just your straw man. He is making an objective claim about something that is totally, completely, subjective. Productivity and code quality are totally, completely, subjective? So all the many, many words written about things agile development, quality engineering, productivity measures, software lifecycles, and so on - are basically meaningless, because they're trying to improve things that are totally, completely subjective? Premise 4: For any non-trivial project, a common coding style is a good thing. Relevant quote: having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. I'm willing to grant that one on slightly less solid ground. He's assuming that 1) the project chose a reasonable style, as opposed to one designed to obfuscate code, and 2) that the people involved are likewise not outliers, and can deal with any reasonable coding style. But granted that, his statement pretty much stands as is. Here he introduces the concept of conflicting coding styles without explaining what the hell that is. I have seen many projects that have different code style interspersed throughout, yet how they were conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity. Whether or not a code style is in so-called conflict with another is a completely subjective
Re: Lisp/Scheme Style Guide
It would be a tragedy if The State ordered Picasso to make his paintings more realistic I think your confusing the virtue in shuffling parentheses around. If you want to place your parentheses on their own line then more power to you, it's your style -- but don't confuse it with making high art. The beauty is in the painting, not in the fact that you choose to hang it upside-down. :f -- 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
