Archive for the ‘Ruby’ Category

In search of a Ruby IDE

Tuesday, August 2nd, 2005

I’ve been looking for a good Ruby IDE as I continue to learn Ruby on Rails. So far the one that stands out the most is the Arachno Ruby IDE, it looks very full featured, relatively polished, and includes an Apache server (only on Windows) which you can run from the IDE.

The other two that looks interesting are:

1. The Mondrian Ruby IDE
2. RDT or Ruby Development Tools which is an Eclipse plugin, nice for us Java types.

I’ve also heard of a lot of people using TextPad for the the purpose or Vim and Emacs but those are a little too low level for my day to day programming taste.

If you’re doing any kind of development in Ruby, what are you using?

Update: I’ve started using the Ruby Plugin for Jedit which has nice IntelliJ like code completion features and API integration. It’s a bit of a hassle to install but otherwise very nice!

Two additional Ruby features I wish were in Java

Wednesday, July 13th, 2005

I’ve been tinkering with Ruby a little, mainly so I know what I’m missing since a lot of people really seem to dig it. Ruby has a lot of nice features that I like including mixins, closures, Rails scaffolding, active record ORM, etc…

The things I don’t like about Ruby are that it’s weakly typed which I’ve written about before and has a very terse syntax that makes it hard to understand at times if you don’t “know” Ruby. For example when I first started looking at Ruby code these constructs left me wondering: variable, :variable, *variable, @variable, |variable|, and @@variable.

While playing with Ruby over the weekend I found two more language features that Ruby has that I really wish we had in Java:

1. Immutability: you can freeze objects so that any attempt to change an immutable object will result in TypeError exception reporting “can’t modify frozen TYPE”. I would love to have this in Java.

2. Native getter/setter support: declaring a list of variables as attr_reader or attr_writer allows getter/setter functionality of a variable without writing/maintaining any redundant getter/setter code, yet if necessary, you can override the default getter/setter behaviour without affecting the API. In Java it drives me crazy that we waste time and clutter our classes unnecessarily with hundreds of lines of getter/setter methods that all do the same thing. Java really needs a construct for default getter/setter behaviour on selected variables that can be overriden when necessary.

The only other feature that neither Ruby nor Java have that I’ve written about before is language support to guarantee that a method variable cannot be passed as null such as public boolean doSomething(notnull Object foo)

What features do you wish you had in Java that you’ve seen in other languages?

Static typing increases productivity and reduces errors

Wednesday, March 23rd, 2005

I’m going to come right out and say that I have a strong preference for static typing in a programming language, especially as it applies to medium and large sized applications with multiple developers. Here’s why:

1. Refactoring: IDE’s make huge refactoring jobs much easier largely because of static typing.
2. Catching errors at compile time rather than runtime: In a larger organization where unit test coverage can vary a bit it’s nice to know these more basic errors will be caught by the compiler.
3. Readability: I like seeing what classes are expected in a method signature, it makes figuring out a poorly documented API vastly easier, and lastly I like using my IDE to click on a method argument and hit a hot-key to jump over to that arguments class.

For me static typing is one more level of protection where I incur only a slight penalty in extra keyboard strokes for a huge time savings in refactoring, readability, and catching basic errors in out of the way places in the code base. Sure, I can develop slightly faster in a dynamically typed language but I can maintain and refactor the code faster in a statically typed language.

In most organizations it’s been my experience that unit test coverage will vary between departments. It certainly won’t exercise every single line of code in the system. When a developer refactors class X there will be those classes that use X that don’t get every line of code exercised in a unit test (MVC controllers seem to suffer from this a lot). If they’re in a lesser used area of a system and using a dynamically typed language, they’ll breeze right through QA and into production. I’ve never had this issue with a statically typed language but I’ve definitely seen several production code issues due to a refactoring of a project in a dynamically typed language.

I’ve heard the argument that dynamically typed languages are more productive, however, in my experience it’s more so that interpreted languages are more productive and less so because of static typing.

Anyhow, despite my bias for statically typed languages I’m itching for a project to use Ruby, its extremely compact syntax and great libraries just might make up for it’s lack of static typing ;-)