July 2009 Archives

Here's a little gotcha that people probably aren't aware of in the RB community. Operator_Convert has a dangerous side-effect.

Class Class1

  Dim mData as Integer


  Sub Operator_Convert( rhs as Class2 )

    mData = Val( rhs.mData )

  End Sub

End Class

Class Class2

  Dim mData as String

End Class

Dim c1 as Class1

Dim c2 as Class2

c1 = c2

MsgBox Str( c1.mData )

It's a tricky one -- the problem is that we never instantiated Class2, so it is nil. When we make the c1 = c2 assignment, we are passing in a Nil object. c1's convert doesn't test for it, and so we get a NilObjectException. But you probably expected that. But wait, there's more! (RIP: Billy Mays)

Let's say you check for Nil in the Operator_Convert function and get rid of the exception. Now what? No more unhandled exceptions! Doesn't that strike you as a bit odd? I would expect an exception on MsgBox Str( c1.mData ), yet one doesn't happen!

That's the true scary problem of the convert to operator. Aside from throwing exceptions, there is no way for the call to fail. So even though c1 should be Nil, it won't be.

Thankfully, the Nil chameleon type doesn't act as a Class2 instance in the compiler when it comes to conversion operators. So if you say c1 = Nil, it will be Nil, regardless of the conversion operator. However, I don't recall that as being something explicitly enforced by the compiler so much as it just happening to work that way. I certainly hope that behavior doesn't change, as it would make a bad situation much worse!

Regardless of the behavior of Nil, this insidious problem can still sneak up to bite you if you're not careful. It certainly isn't intuitive behavior that an assignment from a nil object will create a non-nil object when Operator_Convert exists, but create a nil object when Operator_Convert doesn't exist!

I had an enlightening discussion with one my coworkers today about JavaScript. He's been a good resource when I want practical knowledge about how JavaScript programmers work. All of my knowledge of the language has come from the specification and is from a compiler writer's perspective, which makes it easy to miss concepts that are obvious to anyone who actually works in the language.

I've been having an incredibly hard time wrapping my mind around why anyone would want to use JavaScript. To me, it's truly a horrible language that was obviously thrown together with very little refinement. It's not that I don't know how to get work done in it. It's that I don't know why I'd want to do work in it in the first place.

During our discussion, I came to a realization. There are short-term programming languages, and long-term programming languages. In some languages, you write code intending it to be used for decades. In other languages, you write code without that intention. A convenient split for these time frames is web programming versus desktop or server programming. When you write a desktop or server application, it is expected to live for a long time. You expect to refactor the code, evolve the functionality, etc. You don't expect to have to rewrite it for a while. However, when you write a web application, it's implicitly understood that it only needs to work for a short while.

If you don't believe me, check out the totally off-the-cuff timeline I came up with. 15 years ago, we were all writing static HTML web pages. 12 years ago we started adding dynamic information via Perl. 10 years ago we began using applets written in Java. 7 years ago we started to switch our Perl code over to PHP and JavaScript. 5 years ago we started to ditch the PHP code for Ruby and Python. 2 years ago we started building up AJAX frameworks. By and large, every few years "the next big thing" comes along in the web space and we rewrite our code.

That's not to say that mistakes aren't made on both sides. We've all seen web applications that seem to live forever and evolve like desktop applications. Similarly, what desktop programmer hasn't produced terrible code which barely lasted a few months before being rewritten entirely? But the generalization holds true -- web applications are typically more short-lived than desktop applications.

This is why I have a hard time wrapping my mind around why people use JavaScript. The language doesn't support access control, or type safety and I find that to be a flaw. However, I'm looking at it from a long-term perspective as a desktop programmer which is incorrect. I should be looking at the fact that it's blindingly easy to just blast some code onto the page and hack it together to work. That's the "web way!" That's also why I would make a terrible web programmer.