Ten Things Every Java Programmer Should Know About Ruby

ruby-talk
1

Lähettäjä: "Jim Weirich" <jim@weirichhouse.org>
Aihe: Ten Things Every Java Programmer Should Know About Ruby

We will be introducing Ruby to our XP Users group in Cincinnati next week.
I thought it would be fun to create a list of "Ten Things Every Java
Programmer Should Know About Ruby" to help the transition. I've got a
number of things in my head, but would love to hear ideas from the mailing
list.

So go ahead and submit your ideas. What things should a Java programmer
be aware of when starting out in Ruby?

Here's the list so far:

···

-------------------------------------------------------------------
Ruby classes are Objects (therefore String.new, not new String())
Everything is an Object
Compared to Java, XML is agile. Compared to Ruby, XML is Heavy.
Ruby does not have type casting.
Don't worry about interfaces, enjoy Duck Typing.
No method overloading
Enjoy closures and blocks
Don't worry about early performance optimization
Web-development is possible with other languages besides Java.
Ruby has O/R mappers, so find your Ruby "hibernate", but drop any preconceptions.
Ruby has MVC and OO programming and libraries, but drop any preconceptions.
Ruby is a language to be used everywhere. You use it even in templates. No need for "Velocity/JSP."
Ruby is not a Silver Bullet, unlike Java, right? :slight_smile:
In Ruby data is strongly typed, but variables are *not*
you can have variable number of parameters, and multiple return values
Once you start coding Ruby, going back to Java is painful.
"." (dot) is a method call operator. "::" (colon-colon) is a scope operator.
Java static methods do not (quite) translate to Ruby class methods.
CamelCase for class names, names_with_underscores for methods and variables.
Everything is an expression.
That you can write Ruby in Java (http://jruby.sourceforge.net)
stop writing so much code
@local_variable, $global_variable, Constants, (and @@class_variables)
ri is your friend. irb is your other friend.
Reflection in Ruby is much easier than in Java, and more deeply into the language than the java.lang.reflect tack-on.
eval
the builtin classes are much faster because they're written in C and not Ruby
Boolean methods end in ?. Dangerous methods end in !
Avoid external utility classes
Use class methods to define pseudo-compile directives
You probably don't need Factories
Enumerable is your friend
No external configuration files
method_missing
Typing is the enemy
C extensions/wrappers are *much* easier in Ruby than JNI interfaces in Java
Ruby classes are always "open".
Singleton methods
no semi-colons, optional parenthesis
Ruby packaging vs Java packaging
you can use string interpolation, ex: "x: #{@myvar}" instead of having to say "x:" myvar'
ruby has multiple inheritance through mixins (this is sooo nice to have)
ruby has shortcuts for accessor methods which reduces alot of redundant coding in java
writing code in ruby, can improve the code you write in java
-----------------------------------------------------------------

If there's one thing to be said it's that these are clearly items
from current users and I'm afraid they're maybe too specific. To
summarize some of these points:

* Ruby is pure OO. Everything is an object. 'Hello' is an object,
1 is an object, Class is an object and so on. Ruby's OO is structured
in such a way that it assists you in writing good OO code and allows
you to think about the problem in a more natural manner. Multiple
inheritance is allowed through mixins.

* Ruby is dynamic. You can add, remove and modify objects, classes and
methods at runtime, and that also applies to built-in and standard
classes. Ever wanted to add a method to class String? Now you can.
Ruby has extensive reflection capabilities. One could go as far as
to say that Java doesn't have reflection.

* Ruby is agile, perfectly suited for XP. It's easy to prototype in
but surprisingly even such fast code ends up being easy to build on.
Coding time decreases dramatically and bugs are infrequent.

* Ruby is strongly typed, not statically typed. Each variable has a
strict type that it represents, but a type declaration is not needed
in e.g. method definitions. The result of this is that you don't treat
and classify objects based on what their type is, you do it based on
what that particular object can do. This concept is called 'duck
typing': "If it walks like a duck and it quacks like a duck, it's a
duck".

* Ruby offers many, many syntactic enhancements to make your job
easier. You write very concise, clear and elegant code without
sacrificing functionality. Indeed, you gain some. One of the most
favourite features of Ruby programmers are code blocks, which are
often used in place of iterators.

* Ruby is plenty fast for everyday applications. If, after you've
written a program, you profile it and find a certain bottleneck,
you can easily drop down to C to rewrite that portion. This is usually
not necessary.

* Ruby can be extended with C very easily. The API is clean and
easy compared to JNI, Python or Perl. Extensions are usually used
to bridge existing libraries to Ruby.

When's this meeting, anyway? :slight_smile:

-- Jim Weirich jim@weirichhouse.org http://onestepback.org

E

2

E S wrote:

Here's the list so far:
-------------------------------------------------------------------
Ruby classes are Objects (therefore String.new, not new String()) Everything is an Object

I'd emphasize this for Java ppl. Many of them think that Java is fully object oriented, but they then have to deal with the problems if "int" vs. Integer.

I'd make this fully clear to them by using one of the really cool things like:

5.times { puts "Everything is an object!" }

Everything is an expression.

A great example of this is:
language = case(name)
            when "John", "Jane", "Mike"
              "English"
            when "Yukihiro", "Maiko"
              "Japanese"
            else
              "Unknown"
            end

ri is your friend. irb is your other friend.

I'd say irb is your best friend. ri is cool and all, but nothing beats being able to fire up irb and see for yourself what happens.

method_missing

Show off the roman numerals example from the pickaxe for this one, that's always impressive.

ruby has shortcuts for accessor methods which reduces alot of redundant coding in java

And, ruby has no public members, so all access *must* be through accessors. That's a major deal for Java ppl, who are used to having to have a "foo" member variable, and then a getFoo() and setFoo() method.

Start with the default accessor, then if/when needed, add bounds checking and whatever else you'd like.

Ben

3

E S <eero.saynatkari@kolumbus.fi> writes:

Everything is an Object

I have never liked this over-generalised slogan. Without qualifying
it, then the sentence 'expression is an Object' would be true, yet
that is not true.

It should be qualified as: every object is an Object. The word
'object' there has two senses. The first and obvious one is instances
of Object or its descendants. The second meaning is data entity.

* Ruby is pure OO.

I also have never liked this proclamation as everyone has their own
definitions of what OO is. This proclamation is worth not much more
than proclaiming the assembly language is 'pure OO'.

YS.

4

What is the point of strong typing then?

Thanks,
Navin.

···

E S <eero.saynatkari@kolumbus.fi> wrote:

* Ruby is strongly typed, not statically typed. Each variable has a
strict type that it represents, but a type declaration is not needed
in e.g. method definitions. The result of this is that you don't treat
and classify objects based on what their type is, you do it based on
what that particular object can do. This concept is called 'duck
typing': "If it walks like a duck and it quacks like a duck, it's a
duck".

5

Yohanes Santoso wrote:

E S <eero.saynatkari@kolumbus.fi> writes:

Everything is an Object

I have never liked this over-generalised slogan. Without qualifying
it, then the sentence 'expression is an Object' would be true, yet
that is not true.

It should be qualified as: every object is an Object. The word
'object' there has two senses. The first and obvious one is instances
of Object or its descendants. The second meaning is data entity.

* Ruby is pure OO.

I also have never liked this proclamation as everyone has their own
definitions of what OO is. This proclamation is worth not much more
than proclaiming the assembly language is 'pure OO'.

Certain descriptions are more useful for catchy buzz phrases than technical discourse. If you are addressing a group of developers, Show, Don't Tell might be a good approach.

James

6

E S <eero.saynatkari@kolumbus.fi> writes:

> Everything is an Object

I have never liked this over-generalised slogan. Without qualifying
it, then the sentence 'expression is an Object' would be true, yet
that is not true.

It should be qualified as: every object is an Object. The word
'object' there has two senses. The first and obvious one is instances
of Object or its descendants. The second meaning is data entity.

While, "Everything is an Object" may be an exxageration,
I think there's enough truth to it for it not to be a
meaningless statement. In how many languages that
claim to be OO are all data types, even integers, floats,
and strings, Objects? And in how many are Classes themselves
first-class Objects? In my admittedly limited experience,
(Perl, Python, C++, Objective C, Java, Smalltalk), just one
language. Oh, and ruby. Two languages. :slight_smile:

> * Ruby is pure OO.

I also have never liked this proclamation as everyone has their own
definitions of what OO is. This proclamation is worth not much more
than proclaiming the assembly language is 'pure OO'.

Clearly[1], a language is OO if Alan Kay says it is. :slight_smile:
Since ruby borrows significantly from Smalltalk's object
model, there's a good chance ruby is OO, too. <grin>

[1] http://c2.com/cgi/wiki?HeInventedTheTerm

Happy Rubying,

Regards,

Bill

···

From: "Yohanes Santoso" <ysantoso-rubytalk@dessyku.is-a-geek.org>

7

Hello Navindra,

* Ruby is strongly typed, not statically typed. Each variable has a
strict type that it represents, but a type declaration is not needed
in e.g. method definitions. The result of this is that you don't treat
and classify objects based on what their type is, you do it based on
what that particular object can do. This concept is called 'duck
typing': "If it walks like a duck and it quacks like a duck, it's a
duck".

What is the point of strong typing then?

Good question.

Thinking a little bit about it i would say that in fact then ruby is untyped
not strong typed. It's just that out of history with untyped you mean
that you can do byte operations in the address space with pointer
arithmetics or other ultra low level operations.
And the consequences in the history was an uncontrolled crash now it
is a controlled crash (aka exception).

If i can add and remove methods and instance variables whenever i
want, how is this diffent from a C typecast ?

···

E S <eero.saynatkari@kolumbus.fi> wrote:

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

8

Pig aPig = Pig.new()
Bird aBird = Bird.new()

aFlyingPig = (Bird) aPig

Doesn't make it so.

Cheers

···

On Jan 29, 2005, at 18:13, Navindra Umanee wrote:

What is the point of strong typing then?

--
PA, Onnay Equitursay
http://alt.textdrive.com/

9

In Ruby, objects pass for different types all the time. In my own
recent Ruby code I've mistakenly passed in the wrong types but didn't
notice because the types responded to the same methods.

Even though the type didn't change, effectively the problem and bug
shadowing was identical to the case you describe.

Cheers,
Navin.

···

Florian Gross <flgr@ccan.de> wrote:

Not having your Objects changing types all the time without you
noticing. If you forget to initialize a field in PHP it will be
converted to zero or an empty String if necessary thus shadowing your
bug. Strong typing usually is a requirement for languages where OOP
works well.

10

Hello PA,

···

On Jan 29, 2005, at 18:13, Navindra Umanee wrote:

What is the point of strong typing then?

Pig aPig = Pig.new()
Bird aBird = Bird.new()

aFlyingPig = (Bird) aPig

Doesn't make it so.

A Bird is a Bird if it can "drink" and if it can "eat".
Then isn't the typecast maybe correct ?

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

11

This looks more like Java than Ruby... I don't see your point.
In Ruby you would get:

class Pig def what_am_i p "pig" end end
class Bird def what_am_i p "bird" end end

pig = Pig.new
bird = Bird.new

method_expecting_pig_but_given_bird(bird)

Makes it so.

Cheers,
Navin.

···

PA <petite.abeille@gmail.com> wrote:

On Jan 29, 2005, at 18:13, Navindra Umanee wrote:

> What is the point of strong typing then?

Pig aPig = Pig.new()
Bird aBird = Bird.new()

aFlyingPig = (Bird) aPig

Doesn't make it so.

12

Hi,

> Not having your Objects changing types all the time without you
> noticing. If you forget to initialize a field in PHP it will be
> converted to zero or an empty String if necessary thus shadowing your
> bug. Strong typing usually is a requirement for languages where OOP
> works well.

In Ruby, objects pass for different types all the time. In my own
recent Ruby code I've mistakenly passed in the wrong types but didn't
notice because the types responded to the same methods.

Even though the type didn't change, effectively the problem and bug
shadowing was identical to the case you describe.

Yes, because the type is not checked for most of the operations.

Well, we work on high-level objects, not with memory pointers. The
high-level objects get created and recreated on demand by the
language, so one change in a determined variable won't break the code
somewhere else, as it probably is working on a local copy of the
object (the data and methods, not the memory pointer.)

When objects get "passed by value" it helps a lot the general
stability of the system. That's why even in Java you pass by value.
Though when you want a bullet proof library, you need extra-work to
avoid the user from messing up with the internal code (in Java.)

In Ruby, we are freer from the "static typing" checks, and as freedom
is something (generally,) good, we have more features which allow us
to be freer than with other languages.

This article talks about languages and tools:
http://osteele.com/archives/2004/11/ides

So yeah, we don't have everything that other languages have. It's good
or bad depending if you require those features/tools. The problem is
that we don't have a definitive answer to whether there is a God, as
well as we don't have a definitive answer on whether dynamic languages
(that are not Smalltalk) can be as tool enabled as the static typed
languages. Maybe not. Can we do ok even without certain tools? Maybe,
depending on some factors.

Our memory allocated "objects" have strong types, but they aren't
enforced on the operations, because we don't add types to our coding,
like in Java. If Ruby was to be more like Java, it would lose its
"sparkness." If type could be infered and pre-checked, then at least
it would be an improvement over Java's approach. And any investment on
Ruby should not try to take it over from the community. :slight_smile:

Cheers,
Joao

···

On Sun, 30 Jan 2005 03:22:21 +0900, Navindra Umanee <navindra@cs.mcgill.ca> wrote:

Florian Gross <flgr@ccan.de> wrote:

13

Navindra Umanee ha scritto:

Not having your Objects changing types all the time without you noticing. If you forget to initialize a field in PHP it will be converted to zero or an empty String if necessary thus shadowing your bug. Strong typing usually is a requirement for languages where OOP works well.

In Ruby, objects pass for different types all the time. In my own
recent Ruby code I've mistakenly passed in the wrong types but didn't
notice because the types responded to the same methods.

Even though the type didn't change, effectively the problem and bug
shadowing was identical to the case you describe.

not quite the same.
compare:

method sum(a,b)
  return a+b

strongly typed language:
a='yo'
b=2
sum(a,b) #error

weak typed:
a='yo'
b=2
method sum(a,b) # 2 with 'yo' converted to 0? "yo2" with 2 stringified?

the former has much less potential to hide an error.

···

Florian Gross <flgr@ccan.de> wrote:

14

It could indeed be perfectly correct if Pig is derived from Bird. Then you could easily have flying pigs.

I would love to see such taxonomy though 8^)

Cheers

···

On Jan 29, 2005, at 19:23, Lothar Scholz wrote:

A Bird is a Bird if it can "drink" and if it can "eat".
Then isn't the typecast maybe correct ?

--
PA, Onnay Equitursay
http://alt.textdrive.com/

15

Sorry. Forgot to reboot in Ruby mode:

aMethodExceptingToFlyABirdButGivenAPigInstead( aPig )

And what would happen to this mythical flying pig now? aPig.fly()? EXC_BAD_ACCESS (aka method_missing).

Cheers

···

On Jan 29, 2005, at 19:27, Navindra Umanee wrote:

This looks more like Java than Ruby... I don't see your point.

--
PA, Onnay Equitursay
http://alt.textdrive.com/

16

Ob Javascript reference:

In Javascript, the same sort of thing happens. Take a JS-HTML example:

myObject.background = 'red';
myObject.style.background_color = 'red';

Both will 'work' (not throw an error), but not do what you wanted. JS silently creates a new property on the fly, all helpful-like.

JS is loosely typed. With ruby, you get a convenient blend of dynamism with strong typing. Not as ridiculously rigid as a strongly-typed language, not as loose as something like JS.

···

Florian Gross <flgr@ccan.de> wrote:

Not having your Objects changing types all the time without you
noticing. If you forget to initialize a field in PHP it will be
converted to zero or an empty String if necessary thus shadowing your
bug. Strong typing usually is a requirement for languages where OOP
works well.

In Ruby, objects pass for different types all the time. In my own
recent Ruby code I've mistakenly passed in the wrong types but didn't
notice because the types responded to the same methods.

17

Right. So aPig.fly() would work if method_missing() was defined or if
a method Pig.fly() happened to be defined as an alias for
Pig.eat_fly().

In Java, on the other hand, you would clearly get the advantage that
you seek here.

Cheers,
Navin.

···

PA <petite.abeille@gmail.com> wrote:

> This looks more like Java than Ruby... I don't see your point.

Sorry. Forgot to reboot in Ruby mode:

aMethodExceptingToFlyABirdButGivenAPigInstead( aPig )

And what would happen to this mythical flying pig now? aPig.fly()?
EXC_BAD_ACCESS (aka method_missing).

18

Hi --

···

On Sun, 30 Jan 2005, PA wrote:

On Jan 29, 2005, at 19:27, Navindra Umanee wrote:

This looks more like Java than Ruby... I don't see your point.

Sorry. Forgot to reboot in Ruby mode:

aMethodExceptingToFlyABirdButGivenAPigInstead( aPig )

That's not Ruby mode. That's camel case :slight_smile:

David

--
David A. Black
dblack@wobblini.net

19

Hmm... not sure if I understand that last part... but one thing is very clear though... in Javaland, you simply cannot make pigs fly. In other words, aFlyingPig = (Bird) aPig will not fly. The compiler will just segfault laughing while cursing profanities at you.

Cheers

···

On Jan 29, 2005, at 19:51, Navindra Umanee wrote:

In Java, on the other hand, you would clearly get the advantage that
you seek here.

--
PA, Onnay Equitursay
http://alt.textdrive.com/

20

PA wrote:

Hmm... not sure if I understand that last part... but one thing is very clear though... in Javaland, you simply cannot make pigs fly.

In (non-evil) Ruby it's not possible either, to transform pigs into birds.

In other words, aFlyingPig = (Bird) aPig will not fly. The compiler will just segfault laughing while cursing profanities at you.

To have some fun at run-time try this:

Bird flyingPig = (Bird) (Object) pig;

···

--
Florian Frank