Hi,

Aleksi Niemel wrote:

> Dave asks what Conrad said:
> > "Conrad Schneiker/Austin/Contr/IBM" <schneik / us.ibm.com> writes:
>    <interesting piece of everyday English usage snipped>
> > What he said.
>
> Well, I guess he meant that there's no need to add some logic to "fix" the
> functionality. I also think he bases his argumentation on the fact that
> apparently other languages behave incorrectly too, and uses Java as an
> example. He also states that we could fix this minor thing when we don't
> have anything else to do (my note: it could be written somewhere, so we
> won't forget). Apart from all the other nuances I'm not able to capture to
> my translation, I'm hopelessly lost at the few last lines.

We have finite resources. Under these conditions, some problems are not
worth fixing--especially if such problems don't represent a "feature
regression" (as it were) from languages where such things might have been
considered much more important. In such cases, these glitches are not (any
more) likely to cause serious problems when people write/port applications
in Ruby with comparable dependencies.

> Should we start to promote Ruby as a language of the least meta-surprises.

No, because in the general case, that claim requires an unbounded amount of
largely presently unavailable knowledge. The intended point was that there
will sometimes be exceptions to the rules when the cost/benefit ratio
becomes counterproductive, which is something you have to judge from a
position of being well-informed about dealing with, versus trying to judge
it from the position of a typically less-informed user.

> That is, the language which was designed not to surprise anyone of
> surprises.

The intended point was that the conclusions of the principle of least
surprise can and will vary between people who are unfamiliar with Ruby, but
who in one case (A) are only slightly familiar with the application domain
and who in the other case (B) are experts in the application domain. One
wants to maximize A whenever it is reasonably convenient to do so, but not
when it comes into substantial conflict with B. And it is from the
perspective of B that you want to make cost/benefit cut-off decisions about
exceptions to maximizing A.

In other words, the "principle of least surprise" is a *guideline* that has
to be applied with common sense and pragmatic judgement.

Conrad