Dynamic vs. static typing is an old debate that will not go away any time soon. However, I’ve noticed that most of the debate seems to focus on the same things: whether static typing reduces the amount of bugs in your code by preventing type errors, whether dynamic typing is more open, and so forth.
For a while, I didn’t have a strong preference between the two. The only “typing” advantage I could see in my day-to-day life was the amount of typing you’d save not having to declare your variables in Python. However, over the last few years I have come down strongly in favor of static typing, followed closely by dynamically typed languages with type hinting (if used consistently). And the reason for this is partly the arguments I alluded to above, but mostly it’s because of an underrated benefit: when combined with a decent IDE or sufficiently smart editor, it keeps me from having to play an excruciating guessing game with the code I’m writing.
I have little patience for people who claim that “real” programming must be done using an editor, and that IDEs are for the weak or somehow make you soft. Programming is a complex task that involves keeping track of a lot of things in your mind at one time, and the more things that you can safely offload onto your extended mind, the easier your life will be, and the less human error will creep into your code. Even the biggest IDE skeptics probably wouldn’t want to give up syntax highlighting, for example, because when your editor knows something about the language you’re writing, it can help you quickly find the bits of code you’re interested in, identify typos when they happen, and generally improve code quality.
One thing that IDEs (though generally not editors1) do that really improves my quality of life is intelligent code completion. Sure, a basic editor can guess what you might want to type next using some sort of probabilistic model, but it can’t replicate my favorite thing about using an IDE to program Java or C# (or, I guess, any statically typed, object-oriented language): when I type a variable name followed by “.”, I get a tooltip showing me all the possible methods I can call on that object. This is especially useful if the object in question comes from a library I didn’t write and am maybe not the most familiar with, as it actually helps me learn the library in question.
Sure, it’s possible to look up the documentation for a method to find out what its return type is and what methods are available on it – provided, of course, that said documentation exists, and is still up-to-date. And if the documentation doesn’t exist, and I have access to the source code, I can always try to figure out what it’s doing. But having to look up documentation or source code when I just want to figure out if a method that intuitively should exist on some object actually exists takes me away from the task at hand and out of my flow. Being able to rely on intelligent code completion to find the method I need and let me get back to work is worth more to me than any supposed flexability2 or parsimony of keystrokes.3
I will admit that lately I’ve switched my main workflow to neovim plus coc.nvim, mainly because I don’t think graphics actually adds anything to an IDE 99% of the time, and even the simplest GUI applications these days seem to guzzle about five gigabytes of RAM just sitting there doing nothing, and man I miss the days of old-school Borland C++ when people understood that even in text mode you can craft a beautiful and intuitive user experience, and why is it even the lean, mean alternative to full-blown IDEs these days is essentially just a pre-packaged version of the same memory hog web browser that’s probably already eating up most of your RAM and back in my day people cared about optimization because when you only had a megabyte of memory to play with you damned sure made it count and why won’t these crazy web developers just stay off my lawn? Anyway, I think that once you throw in all the niceties like language servers and language-specific refactoring plugins, a sufficiently advanced editor basically is an IDE, so my point still stands. ↩︎
In case you didn’t see me link to it above, I’ll link again to this excellent essay by Alexis King, which makes the case better than I ever could that dynamic type systems aren’t inherently more flexible or better at dealing with unknown data. ↩︎
If you’re really trying to reduce typing (the hands-on-keyboard kind), you might be interested in languages with good type inference, such as the ML family (I’m including Haskell since it’s ML-inspired) or Crystal. These make it possible to get the benefits of static typing while letting you leave out explicit type declarations for the most part. ↩︎
Last modified on 2021-03-08