Ruby Versus C#

Updated: 31 May 2013

Every now and again as I program in C# I think "this would be beautiful in Ruby". I like C# but I like Ruby more. Later, someone always asks me "what's so great about Ruby?" and I can only remember two things, and they go "is that all??".

So I am making a list of a few things to remind me.

RDoc vs. XMLDoc

Intellisense is nice, but XML is not so human readable. And try inserting a newline in your Intellisense! RDoc is much more readable, before and after compilation - and that's what documentation is all about.

Of course Intellisense is a big plus, especially when using huge libraries like OS API's, so this may outweigh the benefits of RDoc. I know that one of my colleagues has said he'd hate to use any language that doesn't have Intellisense... and that gives me a strange, sick feeling in my stomach for some reason.

Some Ruby IDE's are trying some Intellisense but because variables can be any object at any time, much of it can't be done.

Default parameters

Apparently default parameters are not permitted because once they are compiled in, the defaults cannot be changed without recompiling.

Seems silly to me! I can't tell you the reams of code I have to write just to curry parameters just because I can't specify defaults - and once curried, the parameters are unchangeable without compiling anyway. I guess they are trying to force people to put defaults into config files, causing even more bloat.

Bah! Less is more!

The Uniform Access Principle

Method calls have return values. Properties return values. Why the brackets() to differentiate them? If you add the ability to "assign" to a method, methods and properties are the same to the outside world. Method versus property is just another annoying way to increase coupling and there's no difference in Ruby.

For more details, see the uniform access principle, put forth by Bertrand Meyer.

Object

One great thing about C# is that an object of type Object can store any object. This means we can have an ArrayList which stores different types of objects:

  ArrayList a = new ArrayList();
  a.Add("Four");
  a.Add(new Random());

  Console.WriteLine(((String) a[0]).Length);
  Console.WriteLine(((Random) a[1]).Next());

Of course, you can't call any useful methods on your Object-ified objects until you cast them back to their original types.

What could be the reason for that? Obviously in the above code the compiler doesn't know what the type of a [0] until runtime, since it only throws an exception at runtime if it turns out that a [0] doesn't have a Length() method. However, the compiler wants to check at compile time that the type I am casting to (String) has a Length() method. So apart from Intellisense, what purpose could the cast possibly serve? To verify that there is any object in existence that may have a Length() method?

In Ruby:

a = ["four", proc{rand}]
puts a[0].length
puts a[1].call

Enums

In C# you have the wonderful enum type, allowing you to make a variable that can store any of a list of symbols. Unfortunately, if you want to convert one of the options to a number, you once again need to cast.

Even if you tell the compiler that the underlying variable holding the symbol should be of a particular type, it is no less forgiving.

Here is my enum, stored internally as a short:

private enum tag :short { reason = 1, unitStatusFlags = 3, gpsStatusFlags = 4 };

Here is where I have a combination of the Object problem above, and the casting of the enum back to a short:

((UmmpByte)ummp.tagObjects[(short)tag.unitStatusFlags][0]).Byte;

Easy to read, huh?

By the way, Ruby has no built in enum, but it's easy to make one: Simple Ruby Enums

Run Forest Run

C# is catching up, every new revision seems to add more of Ruby's features. One day C# is going to be a half baked, ugly version of Ruby that only runs properly on Microsoft platforms. By then I'll have been using real Ruby for decades!