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