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

Posts tagged “static

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.”