Two Weeks with a Dynamic Language
When I started my new job, I actually didn’t know what I would be doing. My resume is very .NET focused (and C++ 6+ years ago.) In my interview we didn’t really talk specific technology stack. We talked about technology in general and some specific projects they were working on. However, the projects were exciting enough that my wife commented that I had never been excited to go to a company before. What she meant by that, was that the actual project I was working on was never what primarily stoked my fire.
So when I started 2 weeks ago, I figured the learning curve would be with the types of projects they were doing, and there is definitely something to that. However, the past 2 weeks have thrown me into a new world. The primary language they’re using on the 2 projects I’ve been exposed to is nodejs. I had looked at a little nodejs earlier in the year. I had also played with Ruby in the past when I wrote a Sinatra app. But all of my experience with a truly dynamic language could all fall under the category of “hobby projects.” That is, apart from some jQuery work on a website, everything else had been done over a weekend or two.
So far, it’s been a lot of fun. It’s not that there aren’t some rough points for me, it hasn’t all been unicorns and rainbows, but it’s still been fun.
IDE
The first thing I realized is that I depended a lot on my compiler/IDE. I mean A LOT. For programs written in Haskell (another hobby language for me) getting the program to compile typically means that it will run without problem. That’s not true in C# or C++, but that didn’t stop me from relying on it. For example, I never worried about typos because the compiler would always catch that for me. Simply hitting F6 let me see that I typed a variable name “mission” one time and “missoin” the next time.
However, reliance on the IDE goes beyond simply compilation. When I want to see where a method is used, I would either go to the definition or “Find all references.” That would show me the 3-5 places that a class was used in. I could then click through that code and see how other consumers were using that.
With nodejs, I’m not using Visual Studio or another big IDE, I’m using SublimeText, and there is no way of knowing who is using this method apart from searching. I’ve still been able to search the code and find examples of how an object is being used, but it’s taken me a little bit longer.
I’m not sure if dependence on the compiler & IDE is good, bad or neutral. In some cases, it’s bad, because I’m giving over control from the code to the IDE. In some ways, though, it’s good because it’s one less thing I need to worry about. I can consult the IDE.
Testing
The next thing I noticed about working with a dynamic language is the importance of testing. Now, to be completely honest, I think doing TDD is pretty important regardless of static or dynamic language. However, writing some features using a dynamic language the past week has highlighted that need. In some ways this blends with the previous point. I no longer have an IDE that exists to check that I typed everything correctly or that I’m using things in the right manner. However, if I write a test before I write my code, my test will help me to see problems in my code. For example, a simple test will tell me that I mistyped a variable name because it will give me an error stating that it can’t find my mistyped variable.
Additionally, one reason I love doing TDD is because I love refactoring code. I’ve been quoted as saying I’m happiest coding when I’m deleting code. Doing that with a dynamic language can be a bit scary if you don’t have good tests. How do you know that there is no code depending on what you’re deleting? Perhaps you missed the one line in the search results that shows the dependency. With a compiler I can always delete the code and rebuild it, no errors typically means no problem deleting it. (NOTE: This is NOT how I would refactor code. My point is simply there were some safety nets in place.)
Finally, testing a dynamic language is a lot more fun (at least for me so far.) I know “fun” is not a quantitative way of judging the language, but I don’t worry about mocks. For example, this past week I was testing something that wanted to check if a model had a list of properties, it had a method like hasAddresses. Now in C#, I could create a mock that simply returned true, or could create the object then add a bunch of addresses so that when the call was made it would be true. But with node, I simply “overrode” the model I was passing in so that the hasAddresses() function simply returned true.
Summary
Nothing super dramatic so far about the differences between dynamic and static language. I’m sure I could find some things I hate about dynamic languages right now, but that’s not the point of this post. Instead, I’ve taken on this challenge not wanting to do things in the static way — that is I don’t want to force my paradigms onto another language, instead, I want to use the idioms of the language that I’m working on.