A couple of questions/statements from a Ruby neohacker

[Dave Bettin]

I started my programming career off with PHP and ColdFusion. I loved the
feedback loop with these languages but quickly favored building a
maintainable application over a pile of spaghetti that was often
engendered by these languages. Entered java, I programmed in java for 5
years and then the noise and bloat got to me. I have been programming in
C# for the last three years (Mono/CLR) and this language still sits atop
my favorite static language list. But there is something about Ruby that
makes my inner geek giddy. I think I finally found a language that hits
the sweetspot. Ruby makes both the hacker and developer in me happy.

With that said, I have an agenda; I want to see ruby make it. And it
looks like Rails is quickly becoming the evangelist for Ruby.

But there are three items that concern me about the Ruby platform and
not necessarily the language.

1) Consistency in naming/coding conventions. The standard library module
and class list is not the prettiest thing to look at. Is there a
standard for naming/coding conventions in Ruby? I believe it is very
important for Ruby to have consistency with its conventions.

2) A solid/sophisticated VM. Speed/scalability/virtualization is
crucial. And I am not sure that the CLR or JVM is the answer, I believe
it will cause much more pain then gain for Ruby. I know there is YARV
but is it really going to see the light of day?

3) Finally, the unixisms in the library. Face it we live in a
heterogeneous world and these libraries must face this reality. I
understand the ancestry of Ruby is unix but will we see better system
abstractions for the libraries in the future? Maybe the answer to number
will this question too.

I am not so worried by the lack of enterprise level libraries or
documentation.. this will come (maybe from Commercial backing).

Thanks,
Dave
"Ruby for the Masses!"

 

[James Edward Gray II]

1) Consistency in naming/coding conventions. The standard library
module and class list is not the prettiest thing to look at. Is
there a standard for naming/coding conventions in Ruby? I believe
it is very important for Ruby to have consistency with its
conventions.

We generally use snake_case for methods and variables and CamelCase
for classes and modules.

Hope that helps.

James Edward Gray II

 

[Timothy Hunter]

2) A solid/sophisticated VM. Speed/scalability/virtualization is
crucial. And I am not sure that the CLR or JVM is the answer, I believe
it will cause much more pain then gain for Ruby. I know there is YARV
but is it really going to see the light of day?

Koichi gave a presentation about YARV at the Ruby Conference this past
weekend. You can build a test version of Ruby with YARV today. There is
no reason to believe that it won't "see the light of day."

 

[Christophe Grandsire]

1) Consistency in naming/coding conventions. The standard library modul= e
and class list is not the prettiest thing to look at. Is there a
standard for naming/coding conventions in Ruby? I believe it is very
important for Ruby to have consistency with its conventions.

Classes/modules are in CamelCase, methods are with_underscores. For the r=
est, I
find personally that the standard library looks quite nice. To each his o=
wn.

2) A solid/sophisticated VM. Speed/scalability/virtualization is
crucial. And I am not sure that the CLR or JVM is the answer, I believe
it will cause much more pain then gain for Ruby. I know there is YARV
but is it really going to see the light of day?

Given that it actually *already* works (just not for all of Ruby), it's m=
ore
than just vaporware. You can check its advancement here:
http://www.atdot.net/yarv/ , and even look at what it actually does here:
http://www.atdot.net/yc/ !

I believe it is now in the phase of the "10% that take 90% of the time" :=
) .

3) Finally, the unixisms in the library. Face it we live in a
heterogeneous world and these libraries must face this reality. I
understand the ancestry of Ruby is unix but will we see better system
abstractions for the libraries in the future? Maybe the answer to numbe= r
will this question too.

I don't know what you're talking about. Before I moved to Linux I used Ru=
by
exclusively on Windows and have never seen anything unixist that prevente=
d me
to do what I want (except iconv, but that has been solved since then, and=
will
be built-in in Ruby2). So I don't believe it's a problem.

I am not so worried by the lack of enterprise level libraries or
documentation.. this will come (maybe from Commercial backing).

That on the other hand worries me, although I've seen encouraging signs l=
ately
on this very list.

"Ruby for the Masses!"

"Wine and Ruby!"
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

Classes/modules are in CamelCase, methods are with_underscores. For
the rest, I find personally that the standard library looks quite
nice. To each his own.

Well, that's probably because you got used to it. But there are more
conventions and some of them are violated even by the std lib:

- boolean query method identifiers end with a question mark "?"
([].empty?)

- destructive method identifiers end with an exclamation mark

a=[1,2,3] => [1, 2, 3]
b=a.reverse => [3, 2, 1]
a => [1, 2, 3]
a.reverse! => [3, 2, 1]
a => [3, 2, 1]
a.delete! 2

NoMethodError: undefined method `delete!' for [3, 2, 1]:Array
from (irb):14

Ooops!
=> [3, 1]

Ah!

See also recent threads here.

I don't know what you're talking about. Before I moved to Linux I
used Ruby exclusively on Windows and have never seen anything unixist
that prevented me to do what I want (except iconv, but that has been
solved since then, and will be built-in in Ruby2). So I don't believe
it's a problem.

I'm also interested in hearing which Unixisms are present and what things
they make harder / prevent.

Kind regards

robert

 

[Sean O'Halpin]

I'm also interested in hearing which Unixisms are present and what things
they make harder / prevent.

Off the top of my head, here are some unixisms present (though they
have never really bothered me):
- fork
- chmod
- inode numbers
- popen3 (though there is a Win32 version available)
- curses

Regards,
Sean

 

[Christophe Grandsire]

- boolean query method identifiers end with a question mark "?"
([].empty?)

And? Are there some that aren't?

- destructive method identifiers end with an exclamation mark

No! The exclamation mark indicates *dangerous* methods, i.e. methods that=
have
any kind of dangerous behaviour (modifying the object they apply to is ju=
st one
of those dangerous behaviours), *when it's not clear from their name that=
they
are dangerous.* So if the name of the method already indicates a dangerou=
s
behaviour (a destructive behaviour for instance), there is *no* need to a=
dd an
exclamation mark.

a=3D[1,2,3] =3D> [1, 2, 3]
b=3Da.reverse =3D> [3, 2, 1]
a =3D> [1, 2, 3]
a.reverse! =3D> [3, 2, 1]
a =3D> [3, 2, 1]
a.delete! 2

NoMethodError: undefined method `delete!' for [3, 2, 1]:Array
from (irb):14

Ooops!
=3D> [3, 1]

Ah!

And that is *correct* use of the exclamation mark, because delete, by
definition, can *only* be destructive. Since it is clear from its name th=
at it
is a dangerous method, the ! is unnecessary and unused. It's not a case o=
f a
broken convention, but of you misunderstanding the convention.

Now you may disagree with that convention, and argue it should change. Bu=
t you
can't call that a convention break when it is not.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Christophe Grandsire]

- curses

In this case, it's just a library, and one that is *very* useful in Unix.=
To me
it's like saying that the Win32OLE library is a windowsism and as such sh=
ould
be replaced with a cross-platform abstraction. Some things just can't be
abstracted away.

For the other ones I don't know. I've never had a problem with them at le=
ast.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Sean O'Halpin]

In this case, it's just a library, and one that is *very* useful in Unix.= To me
it's like saying that the Win32OLE library is a windowsism and as such sh= ould
be replaced with a cross-platform abstraction. Some things just can't be
abstracted away.

For the other ones I don't know. I've never had a problem with them at le= ast.

Sure - as I said, I'm not complaining (though it would be nice to have
a cross-platform console library).

Regards,

Sean

 

[Robert Klemme]

- boolean query method identifiers end with a question mark "?"
([].empty?)

And? Are there some that aren't?

- destructive method identifiers end with an exclamation mark

No! The exclamation mark indicates *dangerous* methods, i.e. methods
that have any kind of dangerous behaviour (modifying the object they
apply to is just one of those dangerous behaviours), *when it's not
clear from their name that they are dangerous.* So if the name of the
method already indicates a dangerous behaviour (a destructive
behaviour for instance), there is *no* need to add an exclamation
mark.

a=[1,2,3] => [1, 2, 3]
b=a.reverse => [3, 2, 1]
a => [1, 2, 3]
a.reverse! => [3, 2, 1]
a => [3, 2, 1]
a.delete! 2

NoMethodError: undefined method `delete!' for [3, 2, 1]:Array
from (irb):14

Ooops!

a.delete 2 => 2
a

=> [3, 1]

Ah!

And that is *correct* use of the exclamation mark, because delete, by
definition, can *only* be destructive. Since it is clear from its
name that it is a dangerous method, the ! is unnecessary and unused.
It's not a case of a broken convention, but of you misunderstanding
the convention.

Now you may disagree with that convention, and argue it should
change. But you can't call that a convention break when it is not.

I'm not so sure: the history of this list / ng has shown that this issue
has irritated people over and over again. So the convention that was
followed in implementing this might be a different one from the publicly
observed one. One reason for this might be that the term "dangerous" in
this context is much broader and less precise than the term "destructive"
(changing the receiver's state). Also "dangerous" is very context
sensitive (even IO#puts might be regarded as dangerous in certain
situations) which adds to the difficulty. It might be an interesting
philosophical debate which of the two conventions is more adhered to, as a
convention is a social thing...

Regards

robert

 

[Christophe Grandsire]

I'm not so sure: the history of this list / ng has shown that this issu= e
has irritated people over and over again.

And it has also shown that many people agree with the convention as I hav=
e
stated it. And from the mouth of the master himself (from:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/2331):

"Unlike Scheme, not all change-in-place functions are named with
exclamation mark. In Ruby, exclamation mark means `MORE dangerous',
or `may cause surprise' than non-bang counterpart, i.g. in-place
modification by `gsub!' may let you surprise, comparing copying
`gsub'."

As long as matz himself keeps with this convention (and he has shown no s=
ign of
wanting to change it, especially since it would cover Ruby with !'s - che=
ck the
rest of the that thread -), I don't think we should either. ! is *not* fo=
r
destructive methods. It's for methods that already exist in a non-bang fo=
rm,
and which do something similar to them but in a dangerous way. There are =
plenty
of destructive methods that don't have a bang (because they don't have a
non-destructive version), and I don't believe it would be a gain to add a=
! to
all of them, especially since it would in my opinion break the aesthetics=
of
Ruby.

So the convention that was

followed in implementing this might be a different one from the publicl= y
observed one. One reason for this might be that the term "dangerous" i= n
this context is much broader and less precise than the term "destructiv= e"
(changing the receiver's state). Also "dangerous" is very context
sensitive (even IO#puts might be regarded as dangerous in certain
situations) which adds to the difficulty.

But in this case it's simple: to get a !, a method has to have a counterp=
art
that does about the same work, and be more dangerous (destructive, unsafe=
,
etc...) than the other one.

It might be an interesting

philosophical debate which of the two conventions is more adhered to, a= s a
convention is a social thing...

I believe the convention that bang methods always have a non-bang alterna=
tive,
and that destructive methods without a non-destructive alternative don't =
have
one, is pretty well followed.

I made a cursory look at about 4 years of the history of the Ruby-talk li=
st, and
everything I read seems to indicate that the convention is pretty well fo=
llowed.
In any case, I don't believe any other convention would be better. Just r=
emember
that if you think of putting a ! on your method you need one without the =
bang.
If it doesn't make sense to have such an alternative, your method doesn't=
need
a bang.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

And it has also shown that many people agree with the convention as I
have stated it. And from the mouth of the master himself (from:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/2331):

"Unlike Scheme, not all change-in-place functions are named with
exclamation mark. In Ruby, exclamation mark means `MORE dangerous',
or `may cause surprise' than non-bang counterpart, i.g. in-place
modification by `gsub!' may let you surprise, comparing copying
`gsub'."

As long as matz himself keeps with this convention (and he has shown
no sign of wanting to change it, especially since it would cover Ruby
with !'s - check the rest of the that thread -), I don't think we
should either. ! is *not* for destructive methods. It's for methods
that already exist in a non-bang form, and which do something similar
to them but in a dangerous way. There are plenty of destructive
methods that don't have a bang (because they don't have a
non-destructive version), and I don't believe it would be a gain to
add a ! to all of them, especially since it would in my opinion break
the aesthetics of Ruby.

Certainly. And compatibility would suffer. Agreed.

So the convention that was

But in this case it's simple: to get a !, a method has to have a
counterpart that does about the same work, and be more dangerous
(destructive, unsafe, etc...) than the other one.

I never looked at it that way. Thanks for that hint!

It might be an interesting

I believe the convention that bang methods always have a non-bang
alternative, and that destructive methods without a non-destructive
alternative don't have one, is pretty well followed.

Anomalies I can think of off the top of my head:

- Hash#update and Hash#merge: those do the same but #merge creates a new
instance while #update doesn't.

- Even for Array#delete it would make sense to have two variants - one
that returns a copy with selected elements removed and another one that
modifies in place.

I made a cursory look at about 4 years of the history of the
Ruby-talk list, and everything I read seems to indicate that the
convention is pretty well followed. In any case, I don't believe any
other convention would be better. Just remember that if you think of
putting a ! on your method you need one without the bang. If it
doesn't make sense to have such an alternative, your method doesn't
need a bang.

Makes sense.

Cheers

robert

 

[Kevin Ballard]

Anomalies I can think of off the top of my head:

- Hash#update and Hash#merge: those do the same but #merge creates a new
instance while #update doesn't.

You do know that there exists a Hash#merge! as well, which Hash#update
is an alias of, yes? I don't find this an anomaly. The name #update to
me implies that the existing hash will be updated with the new keys,
while #merge implies the two hashes will be merged to form a new one.
And that's exactly what happens.

- Even for Array#delete it would make sense to have two variants - one
that returns a copy with selected elements removed and another one that
modifies in place.

Except Array#delete returns the deleted element, so if you turned it
into Array#delete! and added a new non-destructive Array#delete, then
you'd have to change the return value, and the method would now be a
completely different method. After all, an Array#delete that's
non-destructive and returns the deleted element would be completely
useless

Granted, it would be nice to have a non-destructive method that returns
the array minus the passed element. Feel free to correct me if such
a method already exists, but I couldn't find one the other day when I
wanted it.

 

[Bob Hutchison]

I'm not so sure: the history of this list / ng has shown that this
issue
has irritated people over and over again. So the convention that was
followed in implementing this might be a different one from the
publicly
observed one. One reason for this might be that the term
"dangerous" in
this context is much broader and less precise than the term
"destructive"
(changing the receiver's state). Also "dangerous" is very context
sensitive (even IO#puts might be regarded as dangerous in certain
situations) which adds to the difficulty. It might be an interesting
philosophical debate which of the two conventions is more adhered
to, as a
convention is a social thing...

This has been debated for years. I'll make a suggestion near the
bottom of this post that I don't remember seeing on this list (but I
wasn't paying close attention for a few years in there).

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.

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.

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'. It is conceivable that there is a
connotation of 'surprise' here, but I think that is a mistake (one
might even argue that the most surprising version is the non-
destructive one). I think that there is no systematic way to deal
with this, with just one marker, so that objections are never raised.
Delete is the perfect example its non-destructive alternative --
which isn't defined in ruby -- would be something from enumerable,
maybe reject with an equality test -- but no matter, it isn't named
'delete' and so there is no ! required.

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

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.

Cheers,
Bob

 

[Austin Ziegler]

1) Consistency in naming/coding conventions. The standard library
module and class list is not the prettiest thing to look at. Is there
a standard for naming/coding conventions in Ruby? I believe it is very
important for Ruby to have consistency with its conventions.

"That's the nice thing about standards. There's so many to choose from!"
(Attributed to various people over the years.) There are definite
*conventions* in Ruby: CamelCase for classes, CONSTANT_NAMES for
constants, and snake_case for methods. The standard library is supposed
to, I believe, be 2sp indentation, but not all modules are that way.
Most are.

2) A solid/sophisticated VM. Speed/scalability/virtualization is
crucial. And I am not sure that the CLR or JVM is the answer, I believe
it will cause much more pain then gain for Ruby. I know there is YARV
but is it really going to see the light of day?

Yes. See the RubyConf 2005 presentation slides just posted.

3) Finally, the unixisms in the library. Face it we live in a
heterogeneous world and these libraries must face this reality. I
understand the ancestry of Ruby is unix but will we see better system
abstractions for the libraries in the future? Maybe the answer to number
will this question too.

Honestly, I think that most of these are good things. However, I have
promised Matz that I will be doing some work in the Windows side of the
filesystem support when M17N strings are added. Daniel Berger is also
doing a lot of work with respect to that, and I suspect we will see very
strong work in this area leading up to Ruby 2.0.

-austin

 

[Christophe Grandsire]

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 pu=
rpose,
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 som=
ewhat
of a linguistic background, I can tell that a situation where both altern=
atives
are marked, and the unmarked version just doesn't exist, is very unstable=

 

[Bob Hutchison]

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.

You might be right. I don't know that the two marker idea would be
necessarily better in the face of evolving software... might be that
conventions just don't work in general. Imagine how much would break
if 'delete' is eliminated at this stage of the game... the cost would
prohibit the convention.

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.

There's nothing wrong with precision, if you are aware of the costs.