Some Random Blog

I love programming languages. Learning a new one is one of my favorite computer-related activities to do. Right now my favorite is Ruby for reasons I'll get into at another time. There are a few others, though, that have caught my attention lately:

• Erlang: There's something really powerful about a language where remote procedure calls are built into the language. I also realized (again) how cool tail recursion can be. I don't have any ideas trying to get out of my head that would find Erlang useful now, but I really want to play with it more.
• Scala: Scala is an interesting language. It's strongly typed with type inference, which I find very cool and wish more languages would try. It also supports the actor model (like Erlang) and some really crazy generic programming constructs. To me it seems like magic. It also runs on the JVM, which means I get every library people can think of right off the bat. Score!

I also found the article by Stostroup here to be really interesting. It's about 50 pages long, but well worth reading if you're interested in or (are forced to) use C++ at all.

Jeff Atwood's Coding Horror has recently become one of my favorite blogs (although he seems to be more of a Code Complete guy while I'm more of a Pragmatic Programmer guy).

One of the recent posts on the blog made the point that "the best code is no code at all." This is something I completely agree with, but I get into arguments on this topic pretty regularly. This particularly comes up when I discuss static vs. dynamic languages. When I talk about Ruby being my favorite language (for now), many people who come from a C++/C#/Java mindset wonder how correct the code I write can be if the compiler isn't doing any compile-time checks. After all, errors are much cheaper to catch early, and compile-time checking is really early, right?

In theory, they have a point, but in practice, it hasn't been a problem. I was thinking about this recently, and I think there are two main reasons I haven't had noticeably more bugs in my dynamic programs than I do in my static programs:

The first is what Jeff refers to in his blog: Dynamic languages, as a whole, require less code to be written. I don't care how "correct" the compiler thinks my code is, I am smart enough (in a way) to write broken code that the compiler can't catch. When the broken code is a single line hidden in a ton of boilerplate C++/C#/Java style class/method/etc. definitions, it takes a little longer for me to wrap my head around what I need to do to fix the problems. In Ruby, I find that my mistakes are much easier to catch and fix, because my code _is_ my intent. Part of it is because less code = less room to make mistakes, and the other part is less code = easier to find the mistakes I do make.

The other reason, which branches off from the first, is that the dynamic programs are (again, in my experience) easier to test. When you can torture every object in the system at runtime, it becomes unbelievably easier to mock, isolate, and test the exact functionality that exists in a part of the program. Not only does this hit most of the dumb mistakes that compile-time checks will notify you about, it also will tell you when another dumb mistake breaks logic errors that the compiler could never tell you about.

This leads me to an interesting fact that I just recently discovered: Not only does the code I write in C++/C# not have fewer (discovered) errors than my Ruby code, my Ruby code is, on the whole, easier to fix when things do go wrong. Less code provides a lot of benefits when it comes to agility, avoiding needless multitasking, and verifying code correctness, and that's one of the many reasons I've been moving much more toward more dynamic languages lately (and been much a much happier developer for it).