Selon Bob Hutchison <hutch@recursive.ca>:
I think there is a fundamental problem here. Scheme, a language with
a lot of support for functional programming (in this case the aspect
of fp to be emphasised is avoiding assignment or state change), is
almost certainly where this convention originated. In scheme, a !
signifies that a state change may be made (i.e. an internal
assignment). If we carry this through to ruby, which is an OO
language that maintains object state (i.e. routinely modifies that
state) then we are going to have a problem -- there are an awful lot
of method names that should have a ! appended.
Indeed.
Different languages have dealt with this differently. Eiffel, for
example, does not allow methods that return a result to change an
object's state, only method that have no result can do this, and on
top of this you can't silently ignore results -- and so these methods
are easily distinguished in that way. The presumption in eiffel is
that if there is no result that state may change, not that it does
change.
As an example of a language that uses ! but for a completely different purpose,
look no further than Sather, which uses ! to indicate interators.
However, Ruby is not Eiffel. So we use naming conventions and mark
*some* destructive methods, normally only when there is a non-
destructive alternative. Note that 'destructive' means simply that
the object's state is changed, there shouldn't be any negative
connotations understood beyond that -- in particular, 'destructive'
does not imply 'dangerous'.
Not if you know what you're doing indeed. If you don't, the bets are off! 
Given my druthers, I'd have considered a convention where when two
methods are provided, one destructive the other not, to mark them
both. There would be no marker if there is no choice. So we'd have
something like 'action!' and 'action+' (or whatever, that second
marker is another debate) and no method simply called 'action'.
The problem I see with this proposal is that it would decrease the signal/noise
ratio, by adding yet another symbol convention. Also, as someone with somewhat
of a linguistic background, I can tell that a situation where both alternatives
are marked, and the unmarked version just doesn't exist, is very unstable.
People will tend to ignore one of the alternatives and use the unmarked version
for it instead, going back to the current situation (but maybe not as
consistently). It's a convention rather than a language feature, which is why I
think it won't survive if both alternatives are marked.
One of the things I like in Ruby (and I believe others have the same feeling) is
that it "flows" well, a bit like a natural language. I can "speak" Ruby, while
I've never been able to "speak" any other language. But like a natural language
it has a bit of irregularity in its conventions (a very small bit, and only if
you really want to consider it an irregularity). This is not wrong. It's part
of what makes Ruby aesthetically pleasing like a natural language. Changes to
make Ruby's naming conventions to follow stricter rules would likely break this
beauty, and would make the language "flow" much less nicely, I'm afraid.
Matz wrote Ruby to be a programming language for humans rather than for
computers. We humans can't cope with the rigidity of purely logical
("computer-like") conventions. They make things look artificial and cold. Ruby,
on the other hand, is a "warm" language. There's a reason why so many Rubyists
have a strong commitment towards readable, aesthetic, beautiful code. And
there's a reason why people get so worked up about purely aesthetic questions
like the use of -> for lambdas (myself included ). Ruby appeals to our
aesthetic sense, in a way that no rigidly designed language can. The naming
conventions, as imperfect as they may be, help towards this feeling. And that's
why I'm wary of people wanting to modify them to make them more "logical", as if
rigidity was better than warmth. If the downside is to regularly get people on
the list asking why delete doesn't have a !, then I'm happy to do with this
downside. It's better than having Ruby lose its aesthetic appeal.
I'm not advocating anything here by the way. Other than perhaps that
this is going to be a source of ambiguity, or perceived ambiguity (if
there's a difference, and that's another debate 
that keeps coming
up.
Frankly, I prefer it coming up again and again than change the aesthetics of the
language . After all, if we didn't have that, what would we be talking about
all day on Ruby-talk?
···
--
Christophe Grandsire.
http://rainbow.conlang.free.fr
It takes a straight mind to create a twisted conlang.
