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

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

--

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.

    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.

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

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.

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

   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]

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

--

so what the extra keyword for ??

On Fri, 28 Oct 2005 19:27:03 +0200, Daniel Schierbeck  

In message "Re: "Readability" inflation"
    on Sat, 29 Oct 2005 02:09:38 +0900, why the lucky stiff <ruby-t...@whytheluckystiff.net> writes:

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

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

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.

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.

best regards,

Brian

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)

On Sat, 29 Oct 2005, why the lucky stiff wrote:

David

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

best regards,

Brian

On Oct 28, 2005, at 1:07 PM, Trans wrote:

     String contains "abc"
     0..10 contains 5
     1,2,3,4 contains 3
     /^[a-z]*$/ includes "apple"

It would be nice if Array#=== was aliased to Array#include?  So that

     somearray === someval

would check for membership.  You can "cheat" a bit with the case
statement as follows:

     a = [1,2,3,4]
     b = 3

     case b
     when *a
       puts "match"
     else
       puts "no match"
     end

This works with any object that responds to to_a but of course
requires that an array be constructed instead of a more efficient
lookup into the object that could be done via a
customized === method.

I find it interesting that before 1.8 was released, I was frequently
installing the latest 1.7.x because it had some new feature I needed. I
kept that up for a while with 1.9.x just out of habit, but didn't really
need anything that was in 1.9 but not 1.8. I'm very happy with 1.8.2, in
fact.

   def initialize(opts)
     opts[:crust_thickness] ||= :thin
     @toppings = opts[:toppings]
     @crust_thickness = opts[:crust_thickness]
   end