"Readability" inflation

D

David A. Black

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
 
J

James Britt

David said:
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
 
D

Daniel Schierbeck

David said:
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
 
T

Trans

Daniel said:
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.
 
H

Hugh Sasse

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=[:pepperoni, :ham] named :toppings,
c=[:thin] named :crust_thickness)
imaginate:)pizza_factory).make_me(c,t) # [1]
end

nice short vars for codeing, then

# My toppings for today
mt=[:ham, :cheese, :pineapple]
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/articles/2004/09/01/imaginate-the-article
 
W

why the lucky stiff

David said:
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
 
T

Trans

Or 'as'?

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

nice short vars for codeing, then

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

T.
 
D

Daniel Schierbeck

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

nice short vars for codeing, then

# My toppings for today
mt=[:ham, :cheese, :pineapple]
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 => [:pepperoni, :ham]


Cheers,
Daniel
 
J

James Britt

why said:
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
 
J

Joe Van Dyk

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.

I love the current Ruby syntax.

If 2.0 just contained a faster Ruby, and kept the same syntax, I'd be overj=
oyed.
 
P

Pete

pizza =3D Pizza.new :crust_thickness =3D> :really_thick,
:toppings =3D> [:pepperoni, :ham]

looks like a hash, if you ask me...

so what the extra keyword for ??



Hugh said:
# A factory method
def create_pizza(t=3D[:pepperoni, :ham] named :toppings, =20
c=3D[:thin] named :crust_thickness)
imaginate:)pizza_factory).make_me(c,t) # [1]
end
nice short vars for codeing, then # My toppings for today
mt=3D[:ham, :cheese, :pineapple]
pizza =3D create_pizza(mt named :toppings)

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

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

pizza =3D Pizza.new :crust_thickness =3D> :really_thick,
:toppings =3D> [:pepperoni, :ham]


Cheers,
Daniel
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: "Readability" inflation"

|I like that Ruby development is slow. He does wait for our comfort.

Thank you. In fact, I don't like Ruby development is slow. But
unfortunately, I am not smart enough besides being lazy.

matz.
 
R

Ron M

David said:
...a ton of suggestions for changing Ruby syntax....

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

I'm pretty sure it's the opposite of what you think.

In the past, Ruby appealed to people who were fluent in Perl,
ML, Lisp, Smalltalk, the K language, and a bunch of other
languages with truly horrible readability problems.

Judged against that field, Ruby is beautiful.

Today Ruby is attracting people who may have more experience
in C, VHDL and Fortran (me) or Visual Basic (like marketing
departments for UI prototypes).
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.

For us people with less broad exposure to esoteric languages, this:
c.map{|b| b.meth}
really isn't as intuitive as you'd think.

If I were to ask people around the office, I'd expect guesses
like these for "c.map{|b| b.meth}":

? It defines a function with the funny name "c.map" that takes
no arguments; that pipes the variable b it's input to b and
then to b.meth (like MSFT's Monad shell's pipe operator)?

? It uses "c" to return a hashtable ("map" sounds like HashMap
in Java) with one element with name "b" and value "b.meth"?

? It takes the locations in the object "c" and plots
the meth labs on the google-map "b"?

In defense of "{|x| ...}", I really like it over C-style for
loops. But readability for new users certainly isn't one of
it's strengths.



Consider Microsoft's Monad's

get-childitem | sort-object extension | foreach { $_.filename}

vs Ruby's

get-childitem.sort_by{|child| child.extension}.map{|child| child.filename}

Msh makes Ruby's 4-time repetition of "child" look quite tedious,
without adding any readability that I can see over the Microsoft 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 reiterate that I think it's the opposite. Newbies without
the theoretical CS backgrounds are complaining about the parts
that they find confusing or tedious.

The one really great part about Ruby, though; is that almost any
time someone complains, someone else posts some magical addition
to some module that gives the complainer almost exactly what he
wanted -- so I'd tend to agree the language shouldn't need many
of these changes.

But I think what's driving the increased requests are mostly
things that people find hard to read, rather than clean
things that people are getting bored with.
 
K

Karl von Laudermann

Trans said:
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.

I admit I haven't read all of the posts in the named parameter threads,
so I apologize if my question is answered there, but why does there
even need to be a new syntax for declaring methods with named
parameters at all? My first thought as to what "adding named
parameters to Ruby" means is that *any* method can be called using
named parameters or not. I.e., given a method:

def foo(a, b)
a + b
end

It can be called in any of these ways:

foo(5, 3)
foo(a=5, b=3)
foo(b=3, a=5)

Why can't this be made to work?
 
D

David A. Black

Hi --

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 can't say because I don't know what gravity you think I think they
have :) I don't really want to get into the meta-meta-... thing,
though. It's just a bunch of observations and comments -- "from the
audience" and hopefully harmless, as you say.


David
 
C

Christophe Grandsire

Selon Karl von Laudermann :
I admit I haven't read all of the posts in the named parameter threads,
so I apologize if my question is answered there, but why does there
even need to be a new syntax for declaring methods with named
parameters at all? My first thought as to what "adding named
parameters to Ruby" means is that *any* method can be called using
named parameters or not. I.e., given a method:

def foo(a, b)
a + b
end

It can be called in any of these ways:

foo(5, 3)
foo(a=5, b=3)
foo(b=3, a=5)

Why can't this be made to work?

Because "a=5" is an expression that returns a value, and is thus allowed
as an argument. That would create an ambiguity between "a=5" as an
expression whose return value is used as argument and "a=5" as a named
argument receiving a value.

Anyway, quite a few people, including myself, don't like the idea of all
arguments being optionally named arguments. It obliges method arguments
to be part of the method interface, and that should only happen *when
the developer explicitly wants it that way.*

I know it's a feature of Python, and maybe it hasn't brought anything
bad to it. However, it's one of the reasons why I quit learning the
language. It wasn't the only syntax feature I disliked, but it didn't
balance things out either.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.
 
B

Brian Schröder

Hi --

[snip concerns]

I totally agree with you. Thanks for summing it up so nicely.

best regards,

Brian

After reading the other posts I wanted to make clear that I understood
davids comment as a reminder not too be too eager with change
proposals, but to weight them on a beauty scale. I did not understood
it as a discouragement for proposals. I think it is a good thing, that
not only matz stands against the tide, but that there are other
conservative people as well.

best regards,

Brian
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top