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