Adherents Of Static And Dynamic Typifications Will Never Understand Each Other
When my friend and I were at school and only dreamed of becoming developers, we thought about how we would do together something — a game or a super-useful program.
I started learning the pros and C#, it is Javascript. We finished school, we graduated from university, served in the army, got a job. We were dragged down by industrial development here and here, and when we both got tired of it, we remembered how we started.
- Having gathered already experienced developers, we decided to finally make our project – a two-dimensional video game. Since the friend was a clean front, and I was full, the browser was the obvious platform for us. I used to develop the front only in TypeScript, and we thought there were no problems, TS is just a superset of JavaScript. Take it and everything goes smoothly. As if not so. When we began to discuss the work, we faced an incredible abyss of misunderstanding each other.
So I saw the task of making a game. I am – yeah, we have the type of “game”, the type of “inventory”, the type of “thing”, the type of “map”, the type of “location”. I roughly imagine how they work together, describe them, collect the project and everything works. The compiler checked me, I did everything correctly. Next, I start writing code that uses these types. Due to the fact that they are, it is much easier for me. IDE prompts me and checks for errors. If the project is going to – most likely it works. I spent strength on the type descriptions, and it did the trick. Here is my approach.
My friend wanted to do the opposite – just write the code and not describe any types. He was not prepared to define the problem as a type family. I didn’t want to build on it, I didn’t see the task as a set of classes, types, records or something else like that. It seemed to me simply unthinkable. Both of us were right in many respects, just the rightness of each of us excluded the other.
- Seriously, we talked for hours, but at the same time, everyone talked about his own, as if in different languages. And it’s not hard to say that our brains are not flexible. Just a year ago, I painlessly moved to the functional world from object-oriented, and back. Moreover, I spent a lot of time studying JS, and he spent studying several statically typed languages.
But the technology that became the first “combat” for the developers, defines them so strongly that two adults experienced people are simply not ready to listen to each other. During the years of studying the development, our vision was formed too differently and the approaches to solving problems did not work at all together.
As a result, we abandoned the idea of working with each other. The thought immediately comes to mind that the problem lies only in the two of us. Maybe, but I have seen it in other people in the industry.
Static and dynamic typing have a fundamental irreconcilable difference
My code answers the question “How to work with this,” and how the code of developers accustomed to dynamic typing is “How it works.” Both approaches have the right to life, and there are tools for both, but only one can be at the forefront.
Static is good for large projects that have been made by hundreds of developers over the years, and dynamic for small teams, for tasks where you often need a write-only code. With dynamic, you save time and energy at the beginning of development, and with static at the end.
- The idea of putting types on the head seriously influenced my thinking of the developer. Having chosen C# at the beginning of the journey, I nailed the static typing to my worldview, and now I suffer from it. Having seen any task, I try to present its solution as a set of types and principles of their interaction. When I develop a module, the first thing I do is determine which types it operates on and which interacts with its environment. I do not even remember how I approached solving problems earlier.
All learning Java programming is learning how to design and use types. .NET CLR – runtime C # – built on types and for types. Static typing lies at the center of the design of object-oriented programming (hello, classes from JS, I decided that you are not needed). The canonical implementations of most OOP patterns are full of Keyword Interface, which is completely meaningless in a dynamically typed language.
The patterns themselves are a cross-language thing, but can anyone tell me why we need the “state” pattern in a dynamically typed language? And the builder? These patterns are not about development, they are about types. Types and OOP are inextricably linked.
You can not build your business logic, based on the types, but do not know anything about them in the development process. That is why there are front-endangers who cover their code with an unimaginable number of unit tests that check the code base for type errors.
We all know very well that security through coverage is an illusion. Tests are written with hands, they are by definition less reliable than the type-checking system built into the language.
- This does not mean that dynamically typed languages are not needed (in fact, I really think that we are not needed). This means that when using them, you need to abandon the PLO as the dominant paradigm. All this is the unity of data and operations on them – this is for guys who have a static check.
The developers I dealt with do not consider that the presence of static typing changes the approach to development, and they write the same code as in dynamic languages, adding type checking. I think this is fundamentally wrong. And it is most noticeable in a case with a modern frontend.
We would have lived in our own worlds, but TypeScript pushed us
Here I am writing code that cannot be used incorrectly due to types. In the project, I expect others to use types. Then my code will work as I intended. And I deliberately do not cover all cases of misuse of this code (because typing excludes this). But JS-nick comes to the project, takes this type of mine, wraps it in any, and starts to use it incorrectly, which leads to subtle bugs.
JavaScript developers are convinced that Typescript is still the same JS, but with the ability to sometimes add static type checking if they need it. This is not true. Typescript is a hundred times more powerful, and they are only interested in three percent of its capabilities.
The most destructive argument – TypeScript is only a superset of JS. But in practice, you can’t ignore Typescript as an independent language, even if you are the damn king of frontends. Because we need a different approach – static, not dynamic.
- The main advantage of static typing is the warranty. If you use it in one module, but not in the other, you just spent time and energy on the description and development of types, and you did not receive any guarantees.
Many people think that TypeScript is a compromise of type systems between JS and Java. No, he is not a compromise, his type system is just special.
Everything is aggravated by the fact that today every second vacancy at the front requires knowledge of TS. This leads to the fact that JS-developers are exploring the possibilities of Typescript, and begin to write code on it, creating a huge number of sabotage practices. A situation arises when they do not really need static type checking, but they have imposed it on them, and they have spoiled it. It is necessary to finally recognize that the approaches to the development of dynamic and static typing contradict each other; these are not things that can be mixed.
JavaScript, as I see it, is a very good tool to write code that solves a problem without highlighting unnecessary abstractions. The most egregious case in it is the Ice factory pattern. This thing you can feed your instances, and she daubs them with runtime immunity. If I process my object with this factory, it will give me the same, but when I try to change the value of one of the properties, I will get an exception. Just, WHAT?!
- The pattern arose because the fronts somewhere read about the steep immunity, and decided to drag it into their language, which was in no way intended to be immobility. In Typescript, I can make the same factory, but with a compile-time ban on mutations, and without any exceptions.
On the other hand, this is not necessary, because there is pure functional programming. Take F#, Haskell, OCaml, Cluck, ReasonML – their mutations are prohibited from the box. But I’m afraid that if you give the frontend a functional language, it will immediately begin to modernize it and make the behavior similar to JS.
Because the choice of typing is a non-return path. All compromise solutions give only the illusion of compromise. You either put types at the forefront or not. I don’t know how it all happened, I’ll start learning C# and JavaScript at the same time and parallel to each other. But now I am so firmly nailed to my thinking that I do not see and do not want to see the advantages of dynamic typing. They exist, but outside my field of vision, and all that remains for me is to close my eyes to them, as to any manifestations of the world alien to me with which I have to live. I understand that it is not right, but I have to work here and now, and there is no rush between the poles of the budget.
Therefore, I do not want to look for compromises, but I am speaking directly. If you are just starting to learn development, start with static typing.
