Showing that fear of mediocrity can make the world a better place.

TypeScript: It’s not about dynamic vs. static

I have to say I actually like TypeScript as an idea. The idea of type safety and static type checking as an optional compile feature in a language is pretty amazing. That means I can use the types when I need to enforce a hard boundary and still use dynamic programming to get all the benefits that it offers. But that doesn’t matter as much. For me it’s about discover-ability and growth.

Slow developer growth

Static languages (Java, C#, etc) tend to focus on the interfaces and what the IDE can tell you via Intellisense. Your class, method, or property has to have enough type information to tell the client developer how it should be used and how things work. By it’s nature it’s an authoritarian method of information dispersal. Your static code tells the client they need to pass in this type of object (string or int maybe) and you will process it. The client developer doesn’t know how it is implemented or what you going to do with it. Since the IDE is the major source of information for the developer it shouldn’t be a surprise that the C# or Java developer tends to be IDE-dependent and in many cases is stereotyped as being less “clever” than their dynamic programming counterparts. The inability and even the reduction in need in most cases to dig into the source and see what is going on slows the client developers growth. They don’t get to learn from your amazing library. Opensource can help to mitigate this but many companies that use static languages also tend to have a poor policy when it comes to opensource.

Rapid developer growth

Dynamic languages (JavaScript, Python, etc) tend to focus on exploratory interfaces. Your class, method, or property does not have type information so the names have to be much clearer. When working in dynamic languages I find myself exploring the code I am consuming more. Since I don’t have types or a compiler to check on things for me I end up looking into the code I am calling to see what will happen with the variables I pass in. This is a very democratic method of information dispersal as the library developer generally lets me browse the source to learn what I need to consume it. This has a tendency to reward well written code with loyal users since it is readable and it doesn’t make them feel stupid. It actually makes them feel smarter. They can read the code and understand it and even learn new tricks. It’s a sneaky way of turning normal development into a learning and reading exercise and reading code makes you a better programmer. Since you are constantly understanding the code you consume a little deeper than the top level abstraction (I like Scott Hanselman’s sink faucet and drain metaphor for this) you reduce the risk of becoming the dreaded cargo cult programmer.

Pick your poison

This isn’t meant to incite an us versus them or a decry static programming as evil. There are not so flattering stereotypes of programmers in both static and dynamic languages and there is a grain of truth to them. They both have their place and if you think you are a great /(static|dynamic)/ programmer but you haven’t tried the other then you are missing out. You could be a static programmer with a dynamic programmer’s inquisitive barrier-less mindset. Or you could be a dynamic programmer with an ability to scale large codebases in a clean, modular, and error-free way.

There is no one true way. There are many paths to but you need to be open to them. Become the programming equivalent of the martial arts quote by Bruce Lee “Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.”


6 responses

  1. Great post. I was skeptical of dynamic programming languages until I wrote my first application in Python. It was by no means a large application, but I never had any problems with messing up function signatures or the like. On the contrary, I felt very productive because of the terseness and flexibility of the language.

    That being said, I can see why teams working on large systems need the type safety and performance gains of static typing.

    They both have their place, as you said.

    October 4, 2012 at 10:39 pm

    • Thanks for the kind words and thoughtful comment.

      October 5, 2012 at 7:48 am

  2. After writing very little PHP as a hobbyist, I have been writing C# professionally for about 8 years. I tried Python and Ruby and had my likes and hates with each, but none was enough to switch.

    However, as a web developer, I found myself writing more and more JavaScript over the years. The more I do it, the more I appreciate all sorts of things the language can do (and hate the usual things, non-human-friendly maths sometimes, non-standard date interactions, various browsers feature-compatibility and VM-performance areas).

    I like TypeScript more as a C# developer who like JavaScript, and to me it’s more like how I’d like to see the next version of C#. Leaving all that aside, your argument on the difference between developers used to static languages and those used to dynamic ones (being a developer who did both long enough myself) is the best IMHO.

    I have never bought this argument like I do now. Static languages don’t restrict looking at the code while in-the-IDE (at least in C#, some features have been added especially to Visual Studio for this like Symbol Source support for package-manager downloaded libraries and .NET framework’s own code), but they sure offer documentation (declarative comments, AKA XML comments) and public interfaces as the “recommended” way of exploring APIs (again, even though they don’t restrict other options, but do work to enable them). This sure affects the way a developer thinks when looking for “the shortest path” to solving a problem. Great writing.

    October 6, 2012 at 12:02 pm

    • Thanks for the comments. Nice point in that you can do a source browse in many places of C#. Unfortunately, it’s not the default approach and the API is still the classic way to get info.

      Interesting comment on the next version of C#. Now that Microsoft added some static to the LISP-y JavaScript it would be great if they added more dynamic LISP-y to C#.

      October 8, 2012 at 8:24 am

  3. Hello,

    As someone who started out coding flash/actionscript > then html + css + javascript > then silverlight. And now mainly focusing on rich .net components written in C# & JavaScript (now using TypeScript mostly), I have to say that i find alot of your arguments completely invalid.

    @interfaces: IDE’s such as Visual Studio are a developers best friend, with next to no setup you can compile, debug and ship your code and intellisense/code-hinting is a great way to learn a new language or use other developers code. The only downside is that its not free-to-use, which in return means that they can afford the best minds of the industry to develop their technology.

    @static vs. dynamic: As you progress with your learning of a static language and get more comfortable with it, certain tools (Resharper/Reflector in the case of .Net) will let you get under the hood and learn what makes it all tick.

    Dynamic languages will always be harder to maintain and debug without enforcing strict coding-conventions that your team/group/company decides on, in which case you might aswell choose a static language to gain the benefits that you are missing out on.

    November 14, 2012 at 5:07 am

    • I agree with your points on static v. dynamic and Visual Studio is hands-down the best IDE I’ve used. However, I was trying to avoid static vs. dynamic arguments and focus more on the developer process of discovering the API. It’s interesting to hear how other people get the info they need to get the job done and how much of it depends on where people started out. I started in PHP and wound up in .Net with a few other dynamic languages in between which might be very different from someone who started in C++ or Java.

      November 14, 2012 at 8:57 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s