Ruby

(No longer the Heretical Page)

Ged has ported FærieMUD to Ruby from Perl. This page now stands as an explanation of why, written in the form of a debate over the switch.

Ged's Initial Questions

I am faced with a dilemma -- I have, as Scotus puts it: "fallen for a new mistress", and her name is Ruby. Ruby is a completely object-oriented interpreted scripting language invented by a Japanese hacker named Yukihiro Matsumoto. It has many of the same strengths as Perl, but is much better suited to coding something as ambitious as FærieMUD. So, I must decide whether or not to write this in Ruby.

This page is here to document the decision process. Please feel free to add your thoughts to the fray.

Arguments in favor

  • Built-in metaclasses - We had planned to implement a metaclass system in Perl anyway for the library of objects that populates the world; as a matter of fact, we were testing an alpha version of such. A metaclass system is desirable because it decouples the various parts of a class from each other, and makes it extremely easy to modularize the class heirarchy to such an extent that you can store the entire thing in the database and edit the pieces through a web interface. The perl version was working for the most part, but it was klugy and untested with a massive heirarchy like FaerieMUD's. Ruby already has built-in metaclasses, which eliminates the whole trial-and-error of getting the hacked together Perl one to work.
  • Strict encapsulation - Perl doesn't have any concept of access control in the language. This is sometimes very nice for those rare instances when you want to be able to break encapsulation, but it takes lots of hoop-jumping when encapsulation is part of your security system. You can (mostly) hide data in Perl with closures, tied variables, or our()ed instance tables, but trying to restrict access to methods would have required access checks to be done in every individual method. Not only that, but you can always jump into someone else's package for one call in Perl, which makes it necessary to traverse the call stack on every call. This could be made a bit more sane with the Safe module (or at least I'm assuming it has some way to disallow the 'package' function -- I never found the opcode for it), and by using code wrappers around the actual code in method objects, but it's much cleaner if the language supports access control natively.
  • Powerful reflection - Because everything in Ruby is an object, getting information about objects is as easy as calling methods on them (usually), and the operators work nicely with the class heirarchy so you can determine things like consanguinity with ease.
  • Pure object-orientedness (everything's an object) - This isn't so crucial to the implementation of the game; it just makes coding much more expressive and fun. Or at least I think so.

Arguments against

  • Ruby's app archive is no CPAN (yet). Some of the modules we would have to port or would sorely miss if not ported:
    • Parse::RecDescent? (Recursive descent parser)
    • Most of the Lingua::EN::* modules (English Language modules)
    • Lingua::WordNet and Lingua::LinkParser (front ends for WordNet and LinkGrammar?)
    • The BXXP SpaceKit? - This isn't such a tragedy, as we'd probably have ended up recoding much of the Perl-ish one, anyway, as it's fairly Blocks-specific stuff
  • Must rewrite all existing code - Most of what I've already written can be ported, but I am a ways off from being able to code at the level I'll need to in Ruby. Not that I mind the learning, mind you.

  • Other coders (if there ever are any) will be more likely to know Perl than Ruby. Scotus has a point, too -- the meta-object system would have been nearly as non-trivial to learn as Ruby.

[More later]

Subverse shun by Scotus

Arguments in favor

  • Built-in metaclasses (very well done, but needs hacks to get around the fact that the Class metaclass cannot be subclassed)
  • Strict encapsulation without kludginess or loss of efficiency
  • Pure object-orientedness (everything's an object)
  • Better property objects (with full power to bring along an interface)
  • Better exception modules

Arguments against and rebuttals

  • Ruby's app archive is no CPAN But what are we going to use from CPAN for:
    • DBI?
    • Special-purpose linguistic modules? Perhaps these can be left in Perl using the distributed-services model: a Linguistics server?
    • Parse::RecDescent?? This is perhaps the most troubling problem from missing CPAN, since parsing is one of the most common activities of a MUD. Even if we could re-code Parse::RecDescent? in Ruby, the added efficiencies of 2.0 will probably be wanted.
  • Must rewrite all existing code Coding is an iterative process and it gets better with each iteration
  • Other coders (if there ever are any) will be more likely to know Perl than Ruby Learning the metaclass system is a bigger step, anyway. And we can even hope Ruby programmers will understand it better. At any rate, the system which monitors outside contributions will have to be pretty sophisticated anyway. Maybe it can be language-independent...well, it's a worthy goal anyway.

Adept Stillflame's POV

For Ruby

  • It makes me think, and i do like thinking. Not to say perl doesn't make me think, but Ruby was built with all these advanced programming concepts at its core, so i get to learn them in the process of learning the language. Speaking of which, i should get back to learning things :)

— GedTheGreysHain - 25 Oct 2000
— Scotus - 28 Oct 2000
— Stillflame - 02 Apr 2001
— GedTheGreysHain - 02 Apr 2001 [Corrected Stillflame's rank. Silly modest adepts.]
— Scotus - 14 Nov 2002