When my friend and I were of school age and aspiring to become software developers, we daydreamed of designing some cool stuff together – like a game or a mega-useful app.
I chose to learn C++ and C#, he picked JavaScript. We finished school, graduated from our universities, served in the army and started our jobs. We had a pretty busy time in industrial software engineering, with lots of different jobs and positions, and after it all started to wear on us, we recalled where it all had begun.
Having finally got together as mature developers, we decided to work on our own project – a 2D video game. Since my friend’s domain was front-end and I was a full-stack developer, our immediate choice of development platform was an Internet browser. As I was only used to working with TypeScript when designing front-end, we thought, ok, no problem, after all, TS is just JavaScript at scale. Let’s use it and things will go smoothly. If I only knew how wrong I was! When we started discussing the project, we ran into an extensive chasm of misunderstanding between us.
Here was my vision of the game. I was like, ok, we have such types as game, tool, item, map, location. I have a basic understanding of how they work together, so I describe them, compile the project – and it works. After all, the compiler has verified my code, and I did it right. Next, I start writing code that uses those types. They make my life much easier. My IDE gives me tooltips and checks for any errors. If a project can be compiled, it probably works. I spent some effort on type description and it yielded results. That’s my approach in a nutshell.
My friend had the opposite idea — to jump to code-writing right away without taking any time to describe the types. He was not ready to define the problem as a family of types. He was not keen on using it as a foundation, as he did not see the problem as a set of classes, types, records of anything of the kind. I thought it was inconceivable. We both had a point, it’s just that our points were mutually exclusive.
Seriously, we were talking for hours, yet each was saying his own thing, as if we were speaking different languages. Mind you, I couldn’t blame it on us being stuck in our old ways. Just a year ago, I migrated painlessly from the world of object-oriented programming to the world of functional programming and back. Moreover, I spent quite a while on learning JS, and he — on learning a number of statically typed languages.
However, to any developer the technology they used for their first real job often defines them to the extent that two experienced adults simply lack the patience to listen to each other. Over these years of software engineering, our visions were shaped in such different ways that our approaches to problem solving just didn’t fit well together.
In the end we abandoned the idea of working as a team. Your first response might be that the problem was in our personalities. You may be right, but I also saw this happen to others in the industry.
The fundamental, irreconcilable difference between static and dynamic typing
My code provides the solution to the problem of how to work with it, whereas the code of seasoned dynamic typing advocates solves the problem of how it works. Both mindsets are legitimate and supported by existing toolsets, but only one can have the highest priority at any single moment.
Static typing is good for large-scale projects involving hundreds of developers who work on them for years, whereas dynamic typing is good for smaller teams and projects that often require write-only code. Dynamic typing allows you to save time and efforts at the beginning of the development, whereas static typing gives you a boost at the end of it.
The idea of putting types first has seriously affected my thinking as a developer. Having chosen C# at the beginning of my career, I have hard-coded static typing into my mindset, and I’m paying the price of this inflexibility now. Once I see a task, I try to imagine its solution as a set of types and rules of their relationship. When I’m developing a module, my first step is to define the types it operates and uses to interact with its environment. I just don’t remember how I used to solve problems before that.
The whole process of learning to program in Java is about learning to design and use types. .NET CLR — the C# runtime — is built on types and for types. Static typing stands at the core of the object-oriented programming paradigm (hello, JS classes, I decided to give you a break). The canonical implementations of most OOP patterns are saturated with the Interface keyword, which makes no sense whatsoever in a dynamically typed language.
The design patterns themselves are cross-language concepts, but can anyone tell me why on earth I’d need the State pattern in a dynamically typed language? What about Builder? These patterns have nothing to do with development, they are primarily about types. Types and OOP have a tight link.
You can’t build your business logic on types and yet know nothing about them as you start writing code. That’s why we have front-end developers who arm their code with an incredible number of unit tests which specifically check the code base for any type errors.
We all know that protection based on code coverage is an illusion. Tests are written manually, and they are by definition less reliable than the built-in system of type verification available in the language.
It doesn’t mean that dynamically typed languages don’t make sense (although I confess that I do think they don’t). It means that while using them, you need to step back from OOP as the dominating paradigm. All this unity of data and data-driven operations is for fellows who have static typing.
The developers I’ve come across don’t think that static typing affects the way of coding to any extent, so they just write their code as if they were using a dynamic language, only they add type checking. I believe this is inherently wrong. It is especially obvious in the case of modern front-end.
I know, I know, there is a taboo on criticizing front-end developers. My friend and I once put together an AI bot that trolled Twitter users, and we got Brendan Eich lash out at it. Seriously, the JavaScript creator had a back-and-forth with our neural network in comments.
For some reason, these guys are just not ready to live in a world where their vision has tangible deficiencies. That’s why I criticize only those of them who tampers with my definitely-typed project to rework it in their relaxed, “Any“ way.
We would keep dwelling in our tiny worlds, but TypeScript brought us together
Take me for example: because of the type restrictions, my code is impossible to use improperly. When I’m working on a project, I rely on others to use types too. Then my code will work just as designed. So I deliberately don’t cover all the cases in which this code can be used incorrectly (because typing makes it impossible). But then a JS developer joins my project, takes my type, wraps it up in Any and starts using it incorrectly, which results in hard-to-replicate bugs.
JavaScript developers are confident that TypeScript is the same old JS, but with an option to add static type checks should they need them. This is wrong. TypeScript is a hundred times more powerful, yet they are only interested in a fraction of its potential.
Their killer argument is that TypeScript is just a superset of JS. In practice, one cannot ignore the fact that TypeScript is an independent language, even if one is a freaking king of front-end. Because it requires a different approach – the one of static, not dynamic, verification.
The major benefit of static typing is that it gives you guarantees. If you use it in one module and choose to not use it in another, then you just waste your time and energy on describing and designing those types, without getting any guarantees whatsoever.
Many think that TypeScript is a compromise of type systems between JS and Java. Well, it is not a compromise of any kind, it’s got a special type system of its own.
Worst of all, today one in two front-end positions requires proficiency in TypeScript. This spurs JS developers to cast a glance at TypeScript’s features and immediately jump to writing code in it, generating a proliferation of harmful practices. Situations occur when they don’t really need static type checking, but it was kind of imposed on them, so they messed with it. We need to finally acknowledge that approaches to programming with static vs dynamic typing are in conflict with each other and can’t be mixed up.
I see JavaScript as a great tool for writing quick-hack code which provides solutions without working out unnecessary abstractions. The most outrageous example here is the Ice Factory pattern. You can feed it your instances, and it will wrap them in runtime immutability. If I process my object through such factory, it will return its equivalent, but if I try to change one of its properties, it’ll throw an exception. WAT?!?
The pattern emerged because front-end developers heard somewhere about cool immutability, so they decided to drag this shit into their language, which needs it like a hole in the head. In TypeScript, I can design a similar factory, but with a compile-time restriction on mutations and without any exceptions.
On the other hand, I hardly need this because there is the pure functional programming. Take F#, Haskell, OCaml, Clojure, ReasonML for example — they have an out-of-the-box prohibition of mutability. But something tells me that if a front-end developer gets his hands on a functional language, he will be willing to upgrade it to make its behavior similar to that of JavaScript’s.
That’s because choosing your typing religion is a one-way ticket. All in-between solutions provide but an illusion of compromise. You either rely on types or you don’t. I don’t know whether my life would be different had I started learning C# and JavaScript in parallel. Today I’m so hopelessly identifying myself with my mindset that I just don’t see any advantages of dynamic typing (and have no wish to see them). They exist, only outside of my range of visibility, so all I can do is close my eyes to them as I do to any phenomena I have to put up with in this world. I know I’m in the wrong, but I have to work here and now, and I don’t have the budget to keep sitting on the fence.
So I don’t want to look for compromises, instead I’ll put it straight. If you’re just making your first steps in development, start with static typing!
Автор: fillpackart
