On 28 May 2009, at 23:06, Juan Zanos wrote: > On May 28, 2009, at 5:20 PM, Eleanor McHugh wrote: >> On 28 May 2009, at 19:55, Juan Zanos wrote: >>> Terseness is a perfectly reasonable goal. It's a corollary to >>> Occam's Razer. >>> No? If you're going to sacrifice conciseness you should have a >>> good reason >>> for doing so. >> >> Occam's law applies to theory formation, not to literate >> exposition. When writing code I'd rather err on the side of >> verbosity if that expresses my model well to those who lack my >> implicit knowledge, than terse and incomprehensible to anyone >> except myself. > > I'd be careful about making such a narrow definition of the "law of > succinctness." I'd also be careful about trying to twist the > definition of > terse towards meaning incomprehensible. A part of the definition > of terse is > "easy to read." As with most things in life, whether or not something is "easy to read" depends upon your frame of reference. What makes perfect sense to you today may not at a later date, and may never make sense to someone else. That's why I mentioned implicit knowledge, a commodity which is present in all skills and that by its nature is hard to transmit because those who possess it are largely unaware of its existence. > You can choose whatever word you want to describe conciseness, but > most of them > imply or directly state clearness or an ease of understanding not > compromised > by beating around the bush or cluttering things up. You can choose > a near > synonym for concise that sometimes has a sense of impoliteness to > make concise > look negative, but the fact is the computer doesn't care. No, the computer doesn't care and is quite happy to be programmed in its own binary language - just a stream of 1s and 0s. However the history of language design has been to move away from direct machine notation (which is tedious and error prone), co-opting syntactic and semantic features from natural languages. This makes good sense as code has to be designed and maintained by people who in general have a higher facility with natural language than they do with machine code. And one of the interesting things about natural language is that it's not indentation sensitive. > Trying to argue that longer is somehow inherently better doesn't > make any > sense. You clearly haven't spent much time trying to maintain extremely terse C or you'd have quite a different perspective. > If you really feel that way then Ruby is a poor choice considering how > many wonderfully tedious languages there are just filled with > redundancy and > unnecessary syntax. How about Java's long winded forced naming > conventions? > Or better yet how about C++ templates for readability? There's just > a ton of > information about every last detail concerning types and all kinds > of stuff and > lots of redundancy. Certainly that is wonderfully readable compared > to Ruby. There are two kinds of redundancy. That which comes from cut-and-paste and is a code smell, and that which exists as a structural safeguard. 'end' is the latter kind of redundancy and whether you like it or not many of us find that supposed lack of conciseness to be a concise representation of block identity. > Seriously, if you want to argue some other point about > implementation details > or some implication of a particular solution well then that's fair > game. But > you're not going to get anywhere arguing that longer is better or > telling > people to go away and use some other language. And you're not going to get anywhere by acting as if significant indentation is a must-have for Ruby or any other language. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason