On 7/18/07, Gavin Kistner <gavin / refinery.com> wrote:
> unknown wrote:
> > I don't mean I think that there should be weird or confusing
> > exceptions to things -- and people certainly disagree as to what's
> > weird or confusing -- but only that I don't generally find symmetry or
> > consistency, as such, to be sufficient reasons for design decisions in
> > Ruby.
>
> Ralph Waldo Emerson wrote:
> "A foolish consistency is the hobgoblin of little minds, adored by
> little statesman and philosophers and divines. With consistency a great
> soul has simply nothing to do."
Gavin I am astonished, by what reason do you throw good ol'Emerson at me?
Is there a single indication that I was talking about foolish consistencies?
BTW the sentence of RWE is quite ( I spare you the adjective ) would
be nice to see the context.
Consistency for me is much more to react logically, much in Göäels' sense,
Extreme examples:
Integer#to_f  implies Array#to_f  that would be a stupid consistency.
String#to_i implies Nil#to_i what do you think about this?

Object#to_s for an intelligent consistency

>
> Consistency is very helpful in some situations. (If everything in system
> XX worked in the same way,
that's not consistency that is conformism
> it would be very easy to figure out how a new
> proposed feature should behave, and it would be very easy for a newcomer
> to know exactly how it worked, since it wouldn't be a special case.)
and hence there would be no power to achieve anything, of course.
>
> But like an unyielding policeman who still writes you a ticket for
> speeding when you're rushing to the hospital with your sick daughter, a
> foolish consistency makes no allowance for special cases. It blindly
> applies the set of rules with no consideration if there might be a good
> argument for an exception.
Please read again, what is this all about?
>
> This is what I think of when I hear Matz argue for certain
> inconsistencies.
Than let us argue for certain inconsitencies

> Handcrafted features may show nicks and scratches from
> inconsistent application. They may not have the pure, clean lines of
> something that was honed by a machine. But those special cases carve out
> bumps that (by and large) make sense for the common case.
>
> A final example: blocks. It would be more notionally pure to allow an
> arbitrary number of blocks to be passed to a method. It would be
> consistent with other method arguments if the method validated that the
> right number of blocks were passed.
Honestly these are much too strong statements to be postulated like that.
 >It would be consistent if the blocks
> passed as parameters were objects assigned to variables that you had to
> call methods on to get them to do something.
Well they are, so what are you trying to say?
>
> (And, of course, you can do this if you want.)
>
> But what we have is the special handcrafted notation of one-block per
> method, a special block that is optional, and that can be called simply
> with the "yield" keyword. And I find it elegant, and appropriate for 95%
> of the cases. I don't think I'd call it pure or consistent, but I'd be
> angry if it were removed from the language.
Well I call it pure and consistent and you are talking about something
completely unrelated here.
>
> And...a final comparison. I program in Lua for a living. It is a great
> language because at its core it's very simple, very consistent.
I was indeed intrigued by that
> It's
> very, very easy to learn, because there are so very few special cases.
> It has very little syntactic sugar. (You can't even write a+=b, but must
> write out a = a+b.) I loved learning Lua, in large part because of its
> consistency. And I really don't like writing in it much, because it is
> so rigid and simple-minded.
Completely agree!

But to draw a conclusion, you have thrown all that at me because I said that
Integer(nil) -> 0 is inconsistent in itself and that it's usefulness
could be discussed and that I feel that Nil#split -->[] might be more
useful, and that I consider this kind of design choices inconsistent,
and I was hoping to have some explanations about that, and I get
"Ruby's cool" and good ol' Waldo.

It is somehow disappointing.

Robert


-- 
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck