--1926193751-855310258-1234969478 565 Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-855310258-1234969478=:9565" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1926193751-855310258-1234969478 565 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi -- On Wed, 18 Feb 2009, Juan Zanos wrote: > > On 18 fñ×r. 09, at 09:07, Robert Dober wrote: > >> On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale <rick.denatale / gmail.com> >> wrote: >>> On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja / slaphack.com> wrote: >>> >> >>> def foo bar >> >> That is very hard to read indeed, but why? >> >> def foo( bar ) >> >> This is not so much better! >> We are all totally accustomed to the fact that foos and bars designate >> the same kind of thing. >> >> I therefore think that >> >> def fact n >> >> is more readable for most people than >> >> def n( fact ) >> >> which is nonsense of course (in the particular context). >> >> Naming seems more important than params or not params (of course if I >> might say?). > > Good point. Syntax isn't all there is to readability. But it does have > some effect. > > In this case the parenthesis don't make anything inherently more readable and > aren't helpful in resolving the nonsense names. The parenthesis are only > meaningful if you already know what they mean. Readability arguments are > often tainted by experience with previous languages. And it must be > remembered that no programmer is born knowing a previous programming > language. If we insist, implicitly or otherwise, that readability means that > something looks like 'C' or Java or any other language then we place limits > on how much we can simplify syntax. I'd actually say that each example with > parenthesis requires a lot more explanation of why they are their, what they > mean, what are the syntax rules that govern them, etc. I agree (except for your last sentence). I honestly don't give C or Java (or Lisp, etc.) a moment's thought in any of this, when I'm writing Ruby. Just Ruby. One thing I've had to come to terms with, reluctantly (because it would be so nice if it were otherwise), is that there is literally no such thing as inherent readability. Readability simply does not inhere in the notation, any more than it does in a given alphabet. I'm not sure why these discussions, when they're about Ruby, always seem to be 99% about other languages. Ruby has one of the most distinct visual styles ever. I guess the issues arise because you *can* make it look like C: printf("%s\n", string); or Lisp (sort of), or whatever. I've always thought of that stuff as marginal -- kind of a party trick, more than a real exploration of Ruby's own style. The reason I don't agree with your last sentence is that I don't think it's possible to explain or defend most of these things. For example, the convention of: attr_accessor :x without parentheses can't really be explained or rationalized. It's just the convention. In the end, it's a bit fuzzy. There's a clustering around certain conventions (like the attr_accessor one), but there are outlying practices, slopes to the bell curve, whatever. I do wish people would not write: def a b, c but if they do, I can't really expect an explanation. It's just what they like. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09 --1926193751-855310258-1234969478 565-- --1926193751-855310258-1234969478 565--