"Readability" inflation

ruby-talk
1

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 :slight_smile: 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) :slight_smile:

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
dblack@wobblini.net

2

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

3

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 :slight_smile: 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) :slight_smile:

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

4

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

···

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

5

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

6

Hi --

<snip>

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

···

On 10/28/05, David A. Black <dblack@wobblini.net> wrote:

7

David A. Black wrote:

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

8

Hi --

[snip concerns]

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

best regards,

Brian

···

On 28/10/05, David A. Black <dblack@wobblini.net> wrote:

David

--
David A. Black
dblack@wobblini.net

--
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

9

Hi --

<5|\|1* |24|\|+>

+ |-| 3 |2 3 15 4 |. 5 0 1 |_| + 3 1 _v |\| 0 + |-| 1 |\| 9

/|/ |2 0 |\| 9 4 |. 0 |_| + 4 |= 3 |/|/ 3 >< + |2 4

5 _v |\/| |. 0 1 5 1 |\| |2 |_| |. _v

David

3

10

I usually come around to agreeing with you that so-and-so change adds
more line noise than is worth it, but this particular one I've disliked
right from the beginning. It's not just the visual clutter, it's the
conceptual overhead of introducing a new variable merely because ruby
has to attach a method to something. Note the progression from

ary.sort {|a,b| a.meth <=> b.meth}
ary.sort_by {|a| a.meth}
ary.sort_by :meth

The |a| adds absolutely nothing to the readability of the code. It's a
case of cluttering the simple case in order to support the complex one,
and ruby usually manages to do a pretty good job of keeping machinery
out of your way until you need it.

martin

···

David A. Black <dblack@wobblini.net> wrote:

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:

11

I agree strongly with this, and the rest of David's comments. In fact
I'll go so far as to take the probably unpopular stance that most of
these "syntax discussions" are a big waste of time. Seriously, they
are like giant distributed committee meetings that spend days talking
and arguing and yelling to produce nothing valuable at the end. The
"named arguments" and "block syntax" related threads were just
ridiculous. There have been many others over the years.

Now matz and the other old-timers have never been ones to censure or
otherwise impede discussion on this mailing list, and I certainly
wouldn't do that either. But consider all the time people spend
writing kilobytes of text on this mailing list in fairly frivolous
discussions, and add to that all the time it takes other people to
read those kilobytes. Now what if that time were spent doing something
else? Like, say, coding new Ruby libraries! Or, even more crazy,
helping on YARV!

See, I'm a pragmatist (after all, it was "The Pragmatic Programmer"
that eventually brought me into the Ruby fray back in 2001.) I think
actions speak louder than words, and that the most useful discussions
on this mailing list involve someone posing a problem, and others
solving it in interesting and elegant ways.

So I don't see much value in these syntax discussion threads which
stretch into 100s of messages, especially when in the end, nothing
really valuable comes from them. Well, I'm probably being a little
harsh here...I imagine matz considers some of the ideas people make
and maybe those are things he hasn't thought of. But overall I think a
lot of time is wasted.

So, anyhow, before you decide that this really cool new syntax should
be put into Ruby, or before you decide to add your ever so important
opinion into these infinite threads, stop. Before posting, consider
how else your time could be spent.

Just something to thing about...

Regards,
Ryan

···

On 10/28/05, David A. Black wrote:

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.

12

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 :slight_smile:

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

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.

···

a::b are.

13

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.

14

Hugh Sasse wrote:

  # 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

15

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

16

Hi,

···

In message "Re: "Readability" inflation" on Sat, 29 Oct 2005 02:09:38 +0900, why the lucky stiff <ruby-talk@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.

              matz.

17

Hi --

···

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

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 :slight_smile: 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

--
David A. Black
dblack@wobblini.net

18

> 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

···

On 28/10/05, Brian Schröder <ruby.brian@gmail.com> wrote:

On 28/10/05, David A. Black <dblack@wobblini.net> wrote:

>
> David
>
> --
> David A. Black
> dblack@wobblini.net
>
>

--
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

19

Joe Van Dyk wrote:

···

On 10/28/05, David A. Black <dblack@wobblini.net> wrote:

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

I agree. If all Ruby 2.0 brought was a VM I’d be happy. That, and
M17N...and perhaps keyword arguments ;-D,
        nikolai

--
Nikolai Weibull: now available free of charge at http://bitwi.se/\!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

20

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"?

Well, *did* you actually ask? What about showing your colleagues a short Ruby program that contains this like of code and collecting their interpretation? That would certainly be interesting to hear. IMHO context helps a great deal in understanding previously unknown concepts.

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.

Well, it depends: your line full of pipe symbols looks like a line from a bourne shell script to me... :slight_smile: I guess you really need some kind of basic knowledge in either case.

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.

It interesting to see how people make different observations: to me it looks as if I more often read "wow, Ruby is so cool and I can even read it although I'm a newby".

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.

Agreed.

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.

Maybe it's not exactly boredom but the human drive to constantly improve things which is especially strong in engineers and similar folks. While this force is often good there are many places where too much degrades things (I'm thinking of the over engineered cars of some German manufacturers...). That hard part is to identify the optimum and stick with that. Also, the optimum may change over time, as requirements change.

A general advantage of conservatism is that it doesn't create too many different variants for the same or similar concept thus limiting the overall size of the playing field. And this in turn helps people a lot to get started. Just compare learning curves for natural languages with comlex rules and syntax with those of languages with only few principles applied consequently.

Kind regards

    robert

···

Ron M <rm_rails@cheapcomplexdevices.com> wrote: