Weiqi Gao's Observations - scripting tag

Unit Tests Are Not Enough

Thu, 27 Sep 2007 04:20:16 GMT

The new and improved It's Just a Bunch of Stuff That Happens—which went off the air briefly, as I noted 37 days ago—is back with renewed, focused energy and is as penetratingly insightful as ever.

In a post yesterday, Eric gave a concrete example of the drawback of lack of static typing in Ruby:

The second bug took me far longer to understand and was more insidious. In Ruby you don’t even have to say “return” at the end of a method. Instead, the result of whatever expression happened last is automatically returned. Invisible magic is the quintessential example of a feature that saves the original coder a few extra keystrokes but makes every downstream programmer pay the continuous tax for years to come.

I made the problem worse by adding a simple “if” statement to the end of the method, thinking I could explicitly change a bogus error message to nil. But now the method didn’t even return a string any more…I inadvertently changed the return type from a string to a boolean.

To which I commented without too much thinking:

Had you made a similar return-type-altering change in Java, the compiler would have caught it as an error. In that regard, the static typing works just like unit tests—it prevents you from breaking your code.

This post became the topic of discussion at OCI North this morning. Brian mentioned that he has been bitten by the same problem in a Ruby script he wrote recently. He also pointed out that no amount of unit tests will guarantee that a function will return data of a specific type.

Suppose you want to write a function that takes a string and return a boolean in a dynamically typed language, and you want the function to return true for inputs like "yes", "true" and for inputs like "no", "false". So you write your unit tests stating these requirements. And you may choose to implement this function like this (in pseudo-code):

def foo(input) {
  if input is "yes" return true
  if input is "true" return true
  if input is "no" return false
  if input is "false" return false
}

However, you cannot write a unit test that will make sure this function always returns a boolean. You can write a specific test that prevents the following code from spoiling the function:

  if input is "weiqi" return "gao"

But that test cannot prevent the next spoiler, and the next, and the next, ...

In this sense, a statically declared return type of boolean for the function can be thought of as the equivalent of an infinitely many unit tests.

The conclusion:

If unit tests are good, static typing is better!

Widening The JVM Language Group: They Need Us!

Thu, 09 Aug 2007 12:54:56 GMT

(Via Tim Bray)

Widening the JVM Languages Group: We Need You!

Charles Nutter: We need diversity in the JVM Languages group, and it's been brought to my attention that some popular/key/interesting languages may not have representation. So we need to change that.

If you are interested in the future of non-Java languages on the JVM, you should be on this list. Yes, we talk about a lot of JVM lanuage implementation challenges, we discuss compilers and stack frames and call-site optimizations, but we also talk about features peripheral to language implementation like package indexing and retrofitting Java 5+ code. We need your help.

Once you've joined, or if you're already member, you have a second task

I respectfully request that each of you search out one individual you think would be interested in the list and try to get them involved. Toss them a quick email, invite them to describe their project or language or implementation to us, and promise them they're joining a very interesting and entertaining community. History will thank you, and so will I.

I joined the JVM Language Group project when Charles announced it the first time around 74 days ago. Although language design and implementation is not my specialty, watching others discuss it is still a lot of fun.

One thing I noticed, for a long time now, is Charles's healthy respect for the other JVM languages, especially Jython, which has been around for more than ten years now. That is so unlike the other Ruby guys that I encounter online.

The goal of the group is to come up with something, some sort of a library or <shudder>framework</shudder>, that would aid the implementation of JVM languages, as well as a forum for other discussions.

I think you want to join even if you are not a language guy. After all, JRuby, (or Jython, or Groovy, or whatever), is just a big Java program.

Kawa 1.9.0 Released

Mon, 22 Jan 2007 16:25:33 GMT

Per Bothner on the Kawa mailing list: I've released Kawa 1.9.0, and updated the web pages. Please try the .tar.gz and/or .jar and let me know of any problems. Here is the list of recent (and not-so-recent) changes. http://www.gnu.org/software/kawa/news.html

For people who are not familiar with it, Kawa is language development framework for the JVM together with an implementation of the Scheme programming language and an implementation of the XQuery language. It compiles these languages into Java bytecodes.

It is in Kawa that I first saw the technique of compiling scripts from the interactive shell into Java bytecode and then load and execute them.