As you know, I’ve been moving from dynamic programming languages to more statically typed languages, the more I code. I can assure you of one thing, it is definitely not a fad. There are good reasons why as I write more complicated software, typed languages have become my goto. Today, we’re going to talk about those reasons and whether a typed language could be for you.
Clarity With Types
Unlike with dynamically typed languages, typed languages tend to provide more code clarity with the types. When I was working with a dynamic language, one issue that always plagued me was knowing the type of the variables I was interacting within functions or in classes. In a dynamic language, the best thing you can do is provide people with an appropriate name for your function parameters. This may help with simple functions, but more complex functions become an issue, especially if the developer who wrote the code beforehand did not use a great naming scheme. I know you all remember those college days or other code bases where everyone used parameter names like l, x, y, z, etc; this just slows down writing code for me.
One thing I notice a lot of programmers who use dynamic languages, but dislike typed languages have in common is a disdain for how locked in you are with a typed system. No longer will you be able to add extra properties on to an object or variable for free. But I can understand where they’re coming from so let’s get into that.
Types Lock In & Verbosity
I remember writing Java and C# code; I hate writing Java and C# code. I’m sure many programmers have been burned by this language in various ways. Being locked into types in your codebase or the verbosity of the language.
Many times when writing code in a statically typed language like Java or C#, I have to write a lot of type information before I get anything done. Once I set up all those types, then I still have to deal with converting them between types whenever the type signature does not match(all I wanted to do was print the contents of the class — no I do not want to write a toString method). I fully understand it sucks; the other part is
Self Documentation and Removing Silly Errors
Improved Code Compilation & Execution Speed
Types Are Not So Bad
At the end of the day, using a language with types is not so bad; the benefits far outweigh the verbosity. The short term gain of writing code quickly at the start usually ends up hurting you later as the code base grows. Having some
So, if you ever decide to start a new project any time soon, try out a language like Typescript, ReasonML, C#, or Java; experience what it is like to know with clarity what each variable and class does in your larger code bases without committing all that information to memory.
Stay tuned, we’ll be talking about the best of both worlds, when we go over type inference.