Paul Barry

Testing in a statically-typed language

December 19, 2008

One of the many “fringe” languages that has been on my radar for some time now is Haskell. Haskell has what looks to be a pretty good book available online and a local book club forming, which presents a great opportunity to study it. What is interesting to me about Haskell is that it is a statically-typed language, like Java, not a dynamically-typed language like Lisp, Ruby, Python, JavaScript, etc. I have really become fond of dynamic typing while programming in Ruby, but I always like studying languages that challenge your fundamental beliefs about programming.

Incidentally, this is one of the reasons I have been really interested in Clojure. It challenges the validity of object-oriented project in a very serious way. In Clojure, you don’t define new classes, instead your program is simply comprised of functions that takes input, possibly call other functions, and return values. Studying functional languages helps you to see the benefits and weaknesses of object-oriented programming. Read more about this idea of studying programming in Glenn Vanderburg’s article about Koans.

So anyway, back to Haskell, and the paradigm here that is worth studying is static typing versus dynamic typing. I must admit, after moving from Java (a statically-typed language) to Ruby (a dynamically-typed language), I’m currently a big fan of dynamically-typed languages. So I’m trying to keep an open mind in studying this, but this passage from Chapter 2 of Real World Haskell I have to object to:

Programs written in dynamically typed languages require large suites of tests to give some assurance that simple type errors cannot occur. Test suites cannot offer complete coverage: some common tasks, such as refactoring a program to make it more modular, can introduce new type errors that a test suite may not expose.

In Haskell, the compiler proves the absence of type errors for us: a Haskell program that compiles will not suffer from type errors when it runs. Refactoring is usually a matter of moving code around, then recompiling and tidying up a few times until the compiler gives us the “all clear”.

One thing I learned when moving from Java to Ruby is that developers often rely on the compiler as a false sense of security. The notion that you can refactor a bunch of code, get it to the point where it compiles and then feel that your code works is dangerous. You code can still contain all sorts of runtime and logic errors, therefore if you want to have any degree of certainty that your code is free of bugs, you need to have some sort of test suite, regardless of if you are using a dynamic and statically typed language.

I’ve also heard the argument made that statically-typed languages allow you to write less tests, but I have also not found this to be the case. Most syntax and type errors will be found with the same tests you use to test the logic of the program. In other words, you don’t have to write one suite of tests to check for syntax errors, one for type checking and another for testing the logic of your program.

So the moral of the story is that regardless of whether you are writing your code in a statically or dynamically typed language, you still have to TATFT.

Stripes Book from the Pragmatic Programmers

July 23, 2008

It’s really good to see a book being published by the Pragmatic Programmers on the Stripes, even if it is too little, too late. I wrote an article on Stripes a few years ago, and actually, I still like how Stripes handles mapping request parameters to an object graph, but since then I have discovered the benefits of dynamic languages like Ruby, so I would never consider using a framework like Stripes, just because it means programming in Java. When I was doing Java, I felt that Stripes was a much better framework than WebWork/Struts, but for some reason flew under the radar. In fact, this blog is built using Stripes. Stripes’ creator Tim Fennell always did an excellent job answering questions on the mailing list and deserved more recognition from the Java community as a whole.

It’s surprising to see this book coming out now. Frankly, straight Java as a web development language is yesterday’s technology, the Cobol of our generation. The JVM is still alive an well, with many great options, such as JRuby, Groovy, Scala and the best of them all, Clojure. I would love to see a Pragmatic Programmer book on Clojure, just to give some more attention to Clojure, because it is such a great language. Anyway, congrats to Tim Fennell, Frederic Daoud and the Stripes team on finally getting some acknowledgment for building a great framework and a great community.

Posted in Technology | Topics Stripes, Java, Clojure | 8 Comments

Means of Abstraction

June 25, 2008

Today I was working on a Rails site where users have profiles that anyone can view, but if you are viewing your own profile, there are links on the page to edit various parts of the profile. I want the links to show up if you are viewing your own profile, but not be there if you are viewing someone else’s profile. To implement this is trivial, as any Rails developer would tell you. I simply added a helper method:

def link_to_if_owner(title,url,options={})
  if current_user == @user
    link_to title, url, options

And changed the occurrences of <%= link_to "Edit", edit_something_path %> to <%= link_to_if_owner "Edit", edit_something_path %>. This probably took 15 seconds, and could not be more clear and succinct. When I compare this to doing Java/J2EE development, this task would probably have involved a custom JSP tag and would have been a complicated solution with much ceremony.

This is what is referred to as the means of abstraction in SICP. They assert that the power of a programming language or framework should be measured by its means of abstraction. The means of abstraction is how you take a set of operations and build a smaller operation that you can build on top of. This is just one example of many that shows why Ruby/Rails is a more powerful combination than Java/J2EE.

Posted in Technology | Topics J2EE, Ruby, Java, Rails

Calling Methods During Class Definition

April 17, 2008

One of the features I like most about Ruby is the ability to execute code during the definition of a class. Here’s a simple example:

class Foo
  puts "hi"

A more useful example is that you can call a method and self is set to the class you are defining.

class Foo
  def self.whoami
    puts "You are #{self}"
class Bar < Foo

This prints You are Bar. This is a feature that isn’t common to most languages, for example, you can’t do it in PHP, Python(I don’t think, Pythonistas jump in there if I’m wrong), Java or even Groovy. The reason why this kind of method is so helpful is this how you can write code that writes code. This is the closest thing Ruby has to Lisp macros. You see this used in Ruby in with the attr_accessor method and in Rails with many methods, belongs_to and has_many being the most obvious examples.

This allows you to define the metadata about a class in the most DSL-like syntax. It would be really great to see this kind of thing in Groovy.

Posted in Technology | Topics Python, Ruby, Java, PHP