Ruby and Java – Similarities and Differences

 News  Add comments
Oct 032006
 

The recent hype around Rails has led to the Ruby language shooting into prominence. Satish Talim who has been working with Java for over a decade, has also been trying out Ruby.

Based on his experience, he has now
put down free study notes on the Ruby language, titled Come Learn Ruby with Satish Talim. Here’s an excerpt from the section about Ruby for Java developers.

Similarities between Java and Ruby

As with Java, in Ruby…
* memory is managed for you via a garbage collector.
* there’s public, private, and protected methods.
*
you’ve got embedded doc tools (Ruby’s is called RDoc). The docs
generated by rdoc look very similar to those generated by javadoc. RDoc
can produce fairly good content even if the source contains no comments.

Differences between Java and Ruby

Unlike Java, in Ruby…
* you don’t need to compile your code. You just run it directly.
* there’s different GUI toolkits. Ruby users can try WxRuby, FXRuby, or the bundled-in Ruby Tk for example.
* you use the end keyword after defining things like classes, instead of having to put braces around blocks of code.
* you have require instead of import.
* all member variables are private. From the outside, you access everything via methods.
* parentheses in method calls are usually optional and often omitted.
*
everything is an object, including numbers like 2 and 3.14159. Classes
are objects! For example, Array is a constant name that is bound to the
Array class object. To create a new object, we call new on the class
object as in a = Array.new
* there are no primitives or data types
* variable names are just labels (not objects). They don’t have a type associated with them.
* there’s
no type declarations. You just assign to new variable names as-needed
and they just “spring up” (i.e. a = [1,2,3] rather than int[] a =
{1,2,3};).
* it’s foo = Foo.new(“hi”) instead of foo = new Foo( “hi” ).
* the constructor is always named initialize instead of the name of the class.
* you have “mixin’s” instead of interfaces.
* YAML tends to be favoured over XML.
* it’s nil instead of null. Also, nil is a normal object; you can never get a null pointer error!
* there is no method overloading.
* it’s much more common to put many classes in the same file.

Do check out the entire guide to Ruby.

If you have used both Ruby and Java, please add your comments below.

Related
Sun Embraces Ruby
Let Java retire from the spotlight of web applications in dignity
Groovy bridges the scripting and the enterprise Java worlds


  • kailashdhar.ch@rediff.com
    nice
  • taw
    Actually there aren’t.

    Ruby ‘private’ means ‘calls to self only’, works with subclasses (like Java protected), doesn’t make method final, and doesn’t put it in a different namespace.

    Ruby protected is broken and nobody uses it.

    Ruby public is actualy public.

    Anyway, this aspect of Ruby is completely different from Java, not similar.

  • ‘Guest’
    [list]
    [*] in Ruby, the constructing and initializing phases of an object are separate and both overridable. The initialization is done via the ‘initialize’ instance method while the construction is done via the ‘new’ class method. [B]Initialize is not a constructor![/B]
    [*] Mixins are examples of implementation inheritance, they are [b]not[/b] equivalent to Java interfaces
    [*] Ruby has first-class functions and closures with the so-called ‘blocks’
    [*] Ruby uses the interal iterator pattern a lot (instead of java’s external iterator)
    [*] And Ruby overall uses blocks a lot to send operations to methods, which means that the methods themselves handle and automate housecleaning: you usually don’t clean after yourself in Ruby, because that’s handled by the class/method implementations you’re using
    [*] Ruby doesn’t use getters and setters, it uses ‘properties’ which look and feel like public attributes, but are really methods under the hood. You can’t create true public attributes, but Ruby has shortcuts to auto-generate properties if you need.
    [*] Strings are mutable, unless you freeze them, and nobody freezes them
    [*] Symbols are immutable interned strings, they’re used to name objects of the language (methods, …)
    [*] While Java nearly has none, Ruby has [b]a lot[/b] of litteral objects: litteral ranges [I](a..b)[/I] or [i](a…b)[/i], litteral regular expressions [i]/foo/[/i] (à la Perl), litteral arrays [i][a,b,c][/i], litteral hashes/maps [i]{:foo => ‘bar’, :baz => ‘buzz’}[/i] etc…
    [*] Ruby’s Arrays are [i]not[/i] Java’s arrays. Ruby’s arrays are equivalent to Java’s ArrayList: they’re mutable, variable-length, O(1) random access containers.
    [*] Constants are either PascalCased or UPPERCASED (a constant starts with an uppercase, and yes a class is a constant), class attributes are prefixed with @@, instance attributes are prefixed with @, globals are prefixed with $.
    [*] method/function names are not camelCased, Ruby’s method names are underscore_separated_words.
    [*] Ruby favours unit testing. In fact, the standard Ruby distribution provides a unit testing framework out of the box (Test::Unit)
    [*] Ruby favours third-party modules in the form of [i]gems[/i]. Gem is like apt-get for Ruby, if you’re looking for a third party module (say… Rails), just gem install it and it’ll usually be found and installed for you. No more tedious installation. Furthermore, distributing your own packages as gems (even inside your own team) allow you to gracefully handle dependencies on first and third-party packages.
    [*] Compared to Java, XML is agile and flexible. Compared to Ruby, XML is a ball-anchor-and-chain bundle. This is why you use either Ruby or YAML to configure your applications. Use XML only when it’s required, not when you think it’d somehow be a good idea (which it isn’t).
    [*] There is almost no compile-time checking in Ruby, because there is almost no compilation. This means that your programs will err only at runtime. This means that you need to unit-test.
    [*] Ruby is a child of Perl. Ruby includes a lot of perlisms ($`, $_, $., …). Perlisms are fine for 5-line shell scripts. Perlisms are not fine for anything above that. Don’t use perlisms, they make code unreadable.
    [/list]
%d bloggers like this: