Confessions of a Static Typing Bigot

by coatta 4/22/2012 12:11:00 AM
I've been a strong typing bigot most of my (programming) life. Pehaps not too suprising for a guy whose favourite saying is "Every thing has it's place, and every place has it's thing." But, like some self-righteous character on a bad TV show whose comeuppance is thoroughly telegraphed, late at night I would sneak off, open up my text editor, and do some JavaScript programming. Sure, I felt guilty, but it was fun, and it didn't seem quite so much like work.

But its not like I was ready to abandon strong typing either. There truly were situations in which is seemed helpful not only to me, but to the developers I worked with as well. So, I thought to myself, maybe dynamic languages are for fun, and statically styped langauges are for "real" work. Of course, I look around me, and people seem to be accomplishing a lot of "real" work with these "fun" languages.

For a number of years, I have eschewed any particular development methodology. It seemed to me that the needs of a given organization and development team could vary substantially from one company or even one project to the next. Simply adopting one methodology and trying to force fit it into every context clearly didn't make sense. You should build up your methodology from elements that matched the needs of the particular team and project.

I'm coming to realize that this seems to apply more broadly. The choice of platform, programming language, architectural patterns, infrastructure components, etc. are all highly context dependent. So, where do dynamic languages work well? My sense, is that they are great when you have small teams with great communication. They work well with what I think of as great developers; those who care about design and are willing to take the time to ensure that it is adhered to. They definitely let you build things more quickly and sometimes with better clarity in the code. And some of my friends on the Queue board made the very convincing argument that they are the best tool for programming against the internet; when you are dealing with various different services that don't adhere to any single well-defined model.

I still find static typing useful. There are situations in which it let's me express my intent in the code more clearly. I think it's helpful to be able to say that the argument to a function I am writing is a List<Integer> rather than just a List. It tells you about the semantics that I am presupposing for the elements of that list, and the compiler will helpfully point out mistakes. I find interfaces incredibly useful for expressing abstractions and helping make sure that the encapsulation boundaries associated with those abstractions are not violated.

So, I'm going to try and avoid being a strong typing bigot from now on. I'll try to stay out of the methodology/platform/language/etc wars, and just choose things that meet the needs I am faced with.

A Rose by Any Other Name...

by coatta 2/25/2012 10:22:00 AM
Actually, in coding names do matter. A few months back we moved our application from one hosting provider to another and everything worked except OpenID authentication. In fact, we had both applications running simultaneously and talking to the same OpenID provider, and one worked and the other didn't.
We were actually getting an error message that indicated a packet had been rejected due to a problem with a "nonce". Here's a definition from Wikipedia: nonce is an arbitrary number used only once to sign a cryptographic communication. That pretty much matches my notion of what a nonce is as well.
I figured this must be due to some peculiar packet duplication that was causing a nonce to be used twice. Seemed like it should be easy to sort out with a network trace, so we slapped one on and collected the traces. They were isomorphic until they weren't. When OpenId failed, it appeared to be because they simply just stopped talking.
OK, so time to dive into the code.
We trace through the code looking for where the nonce was processed. I kept expecting to run into a table that preserved nonce values so the code could check if a nonce had been seen more than once. I couldn't find one. Eventually we got to exact place in the code where the error originated. The "nonce" was actually a timestamp, and the error was because of clock drift between the OpenID provider and the new server we were running on.
Needless to say, this would have all been a lot more straightforward if they had used the right word! An error message along the lines of "the timestamp on message X is out of date" would have made this a lot easier to figure out. Having the field called "timestamp" rather than "nonce" would have made the code a lot easier to understand.


<<  December 2022  >>

View posts in large calendar


My opinions are my own, but you can borrow them if you like.

© Copyright 2022

Sign in