David A. Black wrote: > Hi -- > > I'm writing this separately from any thread partly because it's a new > topic, and partly because I don't want to appear to be pouncing on any > particular post or person. If anything, I'm pouncing on several of > each :-) But really I'm just puzzling things through. > > Over the years and, I think, particularly in recent months, there's > been a ton of suggestions for changing Ruby syntax. The majority > involve adding new semantics through new punctuation. Most of the > rest involve some kind of distillation of existing syntax into > something smaller. > > Thus we've see talk of: > > lambda -> () {} > ary.every.capitalize > def some_method(:a: :b:,; c::d=:e => f) :-) > > and so forth. > > Ruby has always "sold itself" to programmers in large part because it > looks so good and, in the eyes of many, many people, successfully > balances expressiveness with clarity. "Readability" is not an > absolute -- but the empirical evidence suggests that a lot of people > experience Ruby as very readable. > > I'm certainly convinced that if even a few of the punctuation and/or > condensation things happen to the syntax, Ruby's reputation for > readability will decline rapidly and permanently. I may be wrong, but > my belief and working hypothesis is that the "readability margin" is > quite narrow and easily erased. > > That leaves me wondering why all these suggestions keep arising. > > I think what's happening is that people who've used Ruby for a while > get used to it, and then they sort of shift their readability > threshold. In other words, if you've seen this: > > a.map {|b| b.meth } > > for several years, then even though it looked beautiful and concise > and transparent to you at first, it will start to look verbose and > syntactically inefficient. So then you might want to have: > > a.every.meth {|b| (or implicit var, or whatever) } > > Similarly, if you're used to: > > f = lambda {|a,b| ... } > > then after a while, you might find that so natural that you feel > "ready" for > > f = lambda -> (a,b) { ... } > > And yet... if you had encountered the latter version first, you would > never have had the feeling of balance and cleanness that you got (or > at least I did) from the former version. > > So I think there's a kind of readability inflation going on: people > who are acclimatized to Ruby start feeling comfortable about going to > the "next" level of line-noise and/or compactness. > > I'd like to sound a note of caution about this. I think it has the > potential to disserve Ruby's interests, by moving the language away > from the thing that has been proven to be so attractive. > > I've never been big on the idea of adding features to Ruby to make > newcomers "from" other languages feel at home. But here, I am indeed > concerned about newcomers. The point, though, is the same, but from > the other side: just as I do not advocate putting in C++, Java, or > Perl features to sweeten the pot for people considering Ruby, so I do > not advocate *removing* what I see as *Ruby* features (even at a > fairly fine-grained level). I think either of these things can alter > the balance. > > No, I do not think Ruby should stagnate and be dead. If 1.8.3 were > the last version, it would not stagnate and be dead, because people > *use* it and do things with it. The fact that, for me, that counts as > non-stagnation does perhaps mean that I am quite conservative about > language change. I don't think the language needs to change, unless > something is truly broken or missing. > > > David > I agree with you that many suggestions have arisen, but many of them are simply a way to think outside the box (I hate myself for using that phrase, but I can't think of anything better.) I think one of the many great things about Ruby is that each new addition is carefully considered; does it correspond to the Ruby Way? It it clear to me that `collection.every.method' does not. Neither do I think the `->' lambda syntax does. But in the case of named arguments, the great amount of alternative syntax propositions is a huge advantage - they may not look anything like what we'll end up with, but they've been considered, and maybe parts of them can be melted into the final syntax. One thing I would like to add is that we really ought to reconsider the heavy use of symbols, especially arrows. This just doesn't look good: def foo(a =>, b =>, c =>) obj = -> (a, b = 1){ block } And it's not clear to an outsider what it means. Use English words when possible, and don't abbreviate too much. Cheers, Daniel