«

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

--
David A. Black

David A. Black wrote:
> That leaves me wondering why all these suggestions keep arising.

My Instant Theory:

Early users (circa release of Programming Ruby, 1st edition , or
earlier) of Ruby were language geeks, the sort of people who actively
scan the horizon for interesting programming languages. They are
already accustomed to a variety of syntax, so readability is a fairly
fluid concept.

Once Ruby started getting more attention it attracted a wider audience,
including many with less broad language experience and a different idea
of readability.

I haven't gone back to see who has been advocating or supporting what
change or additions, so I do not know if this is even remotely accurate.
But there are certain topics that have attained permathread status,
and syntax munging is becoming one of them as Ruby attracts more users.

I also suspect that on this matter Ruby is a "victim" of its own
success. It makes it far easier to create DSLs and more-readable code,
and may have raised users' expectations about such.

(In fact, when I explain Ruby to people, among the first things I tell
them about is method_missing and send, and how, with those two things,
you can write almost anything like you like and get Ruby to do something
useful.)

James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

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

Daniel Schierbeck wrote:

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

Ruby the Can-Do langauge

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

The { |x| ... } syntax never turned me on about Ruby. In fact, my
first thought what why not do(x) ... end. But it was the *utility* of
blocks that made the difference.

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

Does

def foo(a:, b:, c

look any better? Not to me. To me it looks worse b/c of what :a and
a::b are.

> And it's not clear to an outsider what it means. Use English words when
> possible, and don't abbreviate too much.

Case in point, what's the english equiv of #===. I'd really like to
have one.

T.

On Sat, 29 Oct 2005, David A. Black wrote:

> Hi --
>
> [...] 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
[...]
> 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.

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

And it doesn't take much. I mean, people often object to
pluralization in Perl by means of @collection and
$collection[member]

>
> 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
[Compress the code by moving to a higher base ]
>
> 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.
>

So what is so bad about introducing more keywords? Yes, they can
stamp on existing variables, but what if, just for parameter passing
we introduced "named"

# A factory method
def create_pizza(t=[epperoni, :ham] named :toppings,
c=[:thin] named :crust_thickness)
imaginate(izza_factory).make_me(c,t) # [1]
end

nice short vars for codeing, then

# My toppings for today
mt=[:ham, :cheese, ineapple]
pizza = create_pizza(mt named :toppings)

There's no ambiguity with past forms, and the syntax is still fairly
English. (On the basis that the rest of Ruby is fairly English: I'm
not suggesting people should fit to my linguistic bias.)

Ruby has very few keywords now. I know this might upset things that
talk to name daemons, because they already have the named string
inside the code, but if it improves readability it might be a price
worth paying.

Hugh
[1]
http://www.toolshed.com/blog/article...te-the-article

David A. Black wrote:

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

So, is your compaint about the suggestions? Or about Matz' own recent
tinkerings with the language? Because although your overall comments
lean toward the first, your specific examples point towards changes Matz
has messed with. Discussions he has encouraged.

I think suggestions from the audience are harmless. Matz rarely gives
credence to these and even accepted RCRs go untouched for upwards of 5
years. Anyway, I'd hate to silence the crowd, these are our people.
These are casual discussions, do they really have the gravity you think
they have?

And the syntax choices that Matz plays with often get shelved. He's
played with the local block variables syntax since I can remember. I
like that Ruby development is slow. He does wait for our comfort.

_why

Or 'as'?

# A factory method
def create_pizza(t=[epperoni, :ham] as :toppings,
c=[:thin] as :crust_thickness)
imaginate(izza_factory).make_me(c,t) # [1]
end

nice short vars for codeing, then

# My toppings for today
mt=[:ham, :cheese, ineapple]
pizza = create_pizza(mt as :toppings)

T.

Trans wrote:

> Case in point, what's the english equiv of #===. I'd really like to
> have one.

"kind of equal to"?

Hugh Sasse wrote:
> # A factory method
> def create_pizza(t=[epperoni, :ham] named :toppings,
> c=[:thin] named :crust_thickness)
> imaginate(izza_factory).make_me(c,t) # [1]
> end
>
> nice short vars for codeing, then
>
> # My toppings for today
> mt=[:ham, :cheese, ineapple]
> pizza = create_pizza(mt named :toppings)
>

Looks interesting... I still think this is better, though

class Pizza
def initialize(named toppings, named crust_thickness = :thin)
@toppings = toppings
@crust_thickness = crust_thickness
end
end

pizza = Pizza.new :crust_thickness => :really_thick,
:toppings => [epperoni, :ham]


Cheers,
Daniel

why the lucky stiff wrote:
> David A. Black wrote:
>
>> 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.
>
>
> So, is your compaint about the suggestions? Or about Matz' own recent
> tinkerings with the language? Because although your overall comments
> lean toward the first, your specific examples point towards changes Matz
> has messed with. Discussions he has encouraged.
>
> I think suggestions from the audience are harmless. Matz rarely gives
> credence to these and even accepted RCRs go untouched for upwards of 5
> years. Anyway, I'd hate to silence the crowd, these are our people.
> These are casual discussions, do they really have the gravity you think
> they have?

I agree that suggestions and discussion are important, and, with Matz
calling the shots, there is little risk of any sort of Ruby Community
Process goofiness.

Also do not believe that David is in any way trying to silence anyone.
He's offering a voice to a particular point of view, not trying to
discourage discussion.

James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys