Tuesday, September 12, 2006

Ruby Hacker Interview: Kevin Tew

Kevin Tew is a software architect and freelance consultant. He recieved a master and bachelor degrees in computer science from Brigham Young University. Kevin's primary interests are programming language theory, large web systems, and virtualization. He has also done academic research in parallel processing, distributed systems, and phylogenetics.


How did you find your way to Ruby?

Kevin: Over the past couple of years I've heard about Ruby but never took more than a cursory look at it. Little over a year ago, I left full time employment to finish my Master Degree in Computer Science. While at Brigham Young University, I met Devlin Daley the current BYU Ruby Users Group president. Being the great proponent of Ruby that he is, he invited me to the BYU RUG and Utah RUG meetings. Since then I've met a bunch of very friendly and helpful Ruby Hackers.

What role does Ruby play in your day to day programming?

Kevin: Ruby definitely has its spot in my tool belt. I have a keen interest in programming language theory (PLT) so I know and use a wide variety of languages.

I'm still exploring Ruby. I use it for a lot of short quick scripts in the same way that I use Perl. I've started to use Ruby in place of Python for medium sized, more architected scripts.

I'm not the type to religiously argue that language A is better than language B. I like what I see in Ruby and hope that it will continue to evolve.

I believe that programming languages should empower the programmer to make greater and greater abstractions. Languages successfully evolve when they continue to introduce better abstractions while minimizing increases in complexity.

How did you get interested in Parrot/Cardinal?

Kevin: My interests are wide spread. I have a lot of background in systems and systems programming. I'm a big fan of Virtualization because it's another abstraction that increases my power and productivity as a technologist. Currently there are two big areas of Virtualization work as I see it. Processor and physical machine virtualization such as VMWare and language virtualization at the compiler/runtime level. I have interests in both areas as both have importance. Parrot is the most mature project attempting to build a virtual machine architecture for dynamic languages.

Parrot aims to be the JVM for dynamic languages. I also am very excited about Perl6. Parrot seemed like the right place for a newbie like me to get involved. One of the best ways to throughly learn a new language is to implement it. So I'm trying to do that for Ruby on Parrot.

So, can you give us an example of what cardinal can do at this point?

Kevin: Not a lot. It can do if, unless, while, until, it can throw a very basic exception and catch it, it can do execute a simple puts such as puts "a" or put 10, it can support functions without any arguments

parrot/languages/cardinal/t/ has the basic test suite that cardinal passes. It fails the BEGIN{}, END{}, class, and function call with args tests.

The suite is very minimal at this point in time

I realize that it's really premature to ask this, but how does cardinal compare to Ruby in terms of speed (for the things it does)?

Kevin: See Great Language Shootout:

Note, that this is parrot not cardinal. Much of parrot is still not optimized for speed. Work is primarily focused on functionality at this point.

Cardinal will run slower than the parrot benchmarks because of its focus on functionality not speed, but the promises for the future are evident.

Are you going to try to get the Cardinal Rubyforge site updated?

Kevin: Haven't thought a lot about that. Cardinal definitely needs a web site and a discussion area. If the current Rubyforge and past cardinal maintainers concur, I see no reason not to host Cardinal's web presence there. Cardinal source is currently hosted inside the parrot subversion repository. Given the pace of change in parrot and integration concerns, it is the right place for cardinal source for the foreseeable future.

What hurdles have you had to deal with in working on Parrot and Cardinal?

Kevin: Lack of formalism and standardization. Ruby could really use a formal grammar standard and a hierarchical test suite. Theses things are hard to do when you have a relatively young language and are volunteer supported. The Perl community is much more mature in years than Ruby and they are just now implementing these ideas. That said, investing time early can save a lot of headache in the future.

The Parrot community has been very accepting and positive about Ruby on Parrot. Parrot is a fast moving target. It is much more stable and feature complete than it has been in the past, but is still developing in a couple key areas. Namespace support has recently been nailed down and exception support is being worked on currently. Parrot has a functional class based object system, which is sufficient for the present. A major revision of the object system is Parrot's last major hurtle from a language implementor perspective. There are still a lot of other issues that parrot needs to address, but Parrot is finally coming to age.

If someone wanted to jump in and help with Cardinal, how should they go about it?

Kevin: Anyone and everyone is welcome to contribute to Cardinal in any way they can. We need code, tests, docs etc. Here are some places people can help:

  • Writing basic tests. This is an easy place to start. We need a huge battery of tests that exercise the most basic parts of Ruby.
  • Implementing core classes and modules such as Float, Fixnum, Array, Hash, String, Enumerable, etc. This requires C programming and learning a little about parrot internals.
  • Implementing language features such as case, classes, modules, method_missing, etc.
  • Writing test harness that compare cardinal output with Matz's Ruby.
  • Writing test that verify cardinal's ability to parse and execute the Ruby standard library.

Writing tests is great way to ease into a project like Cardinal. However the more daring individuals who want to jump in and code are especially welcome.

I'm willing to mentor and help anyone that is interested in cardinal. Distance isn't a problem for me. I'd be happy to help anyone over Skype, SubEthaEdit, Gobby, IRC, screen, instant messenger, etc.

What's your take on the other Ruby reimplementation projects?

Kevin: I'm very impressed. There are obviously some very skilled and intelligent people working on both JRuby, Ruby.Net, and MetaRuby. I'm anxious to meet other Ruby implementors and learn from them. Each platform seems to have it's struggles. In many ways I'm envious of the mature platforms JRuby and Ruby.Net have to build on top of. Parrot doesn't have that maturity. I'm very curious to see the work that both Sun and Microsoft are doing to add better support for dynamic languages. In contract to the JVM and .NET Parrot's primary target is dynamic languages, while static languages take secondary position. This gives parrot advantages such as native supports for continuations. I think all Ruby implementors have advantages and disadvantages presented to them by their platform. I believe tighter cooperation would benefit all involved. Unfortunately time resources are always lacking, especially in volunteer supported projects.

How can you (the various projects) help each other?

Kevin:

  • Standard Grammar Definitions and documentation for both LR and LL parsers.
  • A set of standard documents like Perl6's Synopsis.
  • A hierarchical test suite that has increasing levels of conformance for language re-implementors:
    • a very simple level for minimal interpreters or very early interpreters
    • additional levels where more complex language features are tested
  • A minimal test engine, MetaRuby's BFTS already has an example of this.
  • A sanity test suite, like Perl6 has. A sanity test suite tests only the minimal functionality needed to run the minimal test engine mentioned above. The sanity test suite should be executable using the minimal test engine.

What other projects are you working on?

Kevin: Presently, I'm writing a simple Rails application. I'm also doing some hacking to figure out how the internals of MythTV can be made to work with IPTV. (I'm trying to understand MythTV internals.) I'm looking at future XPath 2.0 functionality in Scheme.

What's next for Ruby?

Kevin: I don't know, I consider myself a newbie, but here are some things:

  • Better and cleaner support for higher order functions (i.e., Procs )
  • I think continuations are important and deserve more attention.
  • A virtual machine. Native Thread support. Get native thread support and build whatever other abstractions you want on top. Not the other way around. This is a must for multiple processor and multiple core support.
  • Software Transactional Support as a alternative to locking.

What's next for Cardinal?

Kevin: Support for functions and very basic class support.

What's next for Kevin?

Kevin:

  • A short rest from School.
  • Finish off backlogged TODO lists.
  • Looking for opportunities to collaborate with motivated individuals on interesting projects.

Thanks for taking some time to talk with me about Parrot, Cardinal, and Ruby.

Kevin: Thanks for taking the time to show interest in cardinal.

Technorati tags:

1 comment:

Anonymous said...

I'm somewhat disappointed that Kevin uses the Alioth shootout to make his points. Micro-benchmarks aren't useful tests for anything except micro-benchmarks, and the methodology and management of the Alioth shootout are so bogus that even if these were good micro-benchmarks, they're not useful since the maintainers don't care about the quality of the results. They only care about self-promotion.

Kevin would have been better off doing his own micro-benchmarks.