RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Ruby for C# Geeks : Page 2

As good as C# is, it's not always the best language for simple tasks. Enter Ruby, an interpreted, dynamically typed language that enables simple tasks with simple code.

Same Results, Simpler Code
Every programming language tutorial I've ever read has what is (often sardonically) known as the "obligatory Hello World! example." I'm not very fond of that terminology, so I've spruced up the sample application for this article to the "slightly interesting Hello Foo! example." The snippets to follow show two programs (one in C#, the other in Ruby) that produce exactly the same output for my Hello Foo! example.

First, here's the C# version:

// Hello Foo! in C# 

using System ; namespace TestCSharp { class MainClass { public static void Main(string[] args) { Console.WriteLine("Hello Foo!"); //say hello } } }

As you can see, C# requires you to specify a lot of structure and actually tell the compiler that you're going to write a class. Specifically, here you tell it you're going to write a class with a well-known method called Main that a console application will use as the first method to call (known as an entry point) when the program executes. The required verbosity is somewhat mitigated by Visual Studio or any other syntax-helping editor that allows for templates and IntelliSense; however, the level of code complexity is still there regardless of whether or not you have to actually type every letter.

First, compile the C# program (If you're using Visual Studio or MonoDevelop, you can simply press F5.), and then you can run it:

# Hello Foo! in Ruby

puts "Hello Foo!" # say hello

Running this little snippet requires that you simply invoke the interpreter and then provide the name of the script file (hellofoo.rb):

C:\>ruby hellofoo.rb
Hello Foo! 


Since the Ruby interpreter assumes all of the structural information is there, you don't have to write it like you would in C#. The interpreter assumes that the first bunch of code you write without an enclosing class or module declaration is analogous to it appearing within the Main method of the entry point class. Very handy.

Note the differences in syntax between the languages as well:

  • Semi-colons aren't used to delimit the end of a statement in Ruby.
  • Ruby's built-in puts method is actually like C#'s Console.Writeline in that it will display the result of the .to_s method of the parameter object, which in C# you would write as .ToString().
  • Parentheses are optional for method calls in Ruby. Most of the time, you simply omit them—particularly when you don't pass any parameters.
  • The // style of commenting in C# is replaced by the # notation in Ruby. Authors Note: Because its syntax is regarded as self-explanatory, a common belief is that Ruby rarely requires comments. I'm a little skeptical of this idea, but I will admit that it's often notably easier to understand Ruby code as a human reader than it is the C# equivalent.

Dynamically Typed Means Faster Coding
Not only is Ruby an interpreted (i.e., dynamically evaluated) language , it is also dynamically typed. So the variables in Ruby do not require the specification of their types before you use them. The interpreter will infer variable types as they are assigned values. To add another twist, you don't have to declare variables at all! This is a common feature of many interpreted languages, and even a few compiled languages. To see what I'm talking about, consider the following Ruby snippet:


abc = 1  #abc is a Fixnum (integer)
puts abc

abc = "Rubber Baby Buggy Bumpers"  # now it's a string!
puts abc

You can see that you have to declare neither the variables nor their types in Ruby, and you can change the type by assigning it a different value—right in the middle of the running program. Very dynamic! If you tried to do something like that in C#, the program wouldn't even compile. C# requires statically defining types for variables, which allows the compiler to catch any errors that may arise when types don't match the ways in which they are used. However, it's faster and easier to throw together a script that doesn't go to all of this trouble in Ruby. Both approaches may have a time and a place, but you can choose the one that best suits the problem you're trying to solve.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date