Get best of the week

Dynamic typing is not a development tool. This is nonsense (lousy)



There are a lot of things in programming that I understand very poorly. So many that sometimes they ask me - what are you even good at?

I understand the types and design of a convenient and reliable API. But for a good half of developers, these things mean nothing. Because they use dynamic typing, and they have no idea what problems and why I solve.

For most of my life, I just waved at them and passed by. These fools do not understand obvious things, and I did not undertake to explain to each js-nickname why his code is not development, but toy prototyping. But time goes on, and the number of idiots around does not even think of decreasing, instead of moving their entire front-end industry to a static time script at last, these donkeys begin to use all sorts of stuff, write tons of tests, and go to any imaginable tricks - just not to understand types.

There are a lot of controversial things in the world when, depending on what you want to get, the truth is transferred from one scale to another, leaving no place for any ultimate truth in the last resort. A couple of years ago I already wrote about typing, but then I was young, stupid and cowardly - I had a position, but in order not to seem like an idiot, I carefully hid it behind philosophical discussions about how complicated everything is and how difficult it is for adherents to work different typing models together.

But today I came here to say:

Dynamic typing is infernal shit, and engineers who believe in such an approach are seriously mistaken.


Take a look. Static typing is such a thing that allows me to express some of the conditions under which the code cannot work as additional instructions for the compiler. That is, I know that this function only works with such objects, I describe them in its signature and get a guarantee - an object of a different type will not be transferred to the function. In addition, types let me tell the compiler how my code works. The compiler will be able to use this information to carry out optimizations and, for example, to give me hints. Different development tools can use type information to automatically refactor, do it safely, and with the guarantee that the fuck does not break. The type code itself makes the code base understandable, and brings your instruction sets closer to the processes that you describe with this code.

Opponents of static typing say all these things are unnecessary. They tell me that

Bugs that catch types are not worth the effort to write code for these types.


Seriously? Seriously? Are we too lazy to write characters? Bro. You think for five hours, and you print ten minutes. You're an engineer, so try to figure out what kind of etfort you're talking about. And do not forget that with or without static typing, you will more than once describe in your code base the structures of objects with which you will work. But if you use statics, the compiler and the IDE can do the job for you. And check your code for errors describing these objects. If you are too lazy to write type annotations to functions - use the language of type inference, or generate them using extensions to the IDE.

If you stomp that annotations inflate the code base - remember, damn it, all our principles about the fact that the explicit is better than the implicit, that one of the important tasks of the code base is to be understandable and readable, both by a person and by a machine. If you are too lazy to work in your dumb head to understand what types of applications your application will work on, then I have bad news for you. To write something working, you still have to do this work. Just do it you will not be determined, but on demand. As a result, you will describe the process, but you will not put it in your head, and the quality of your code will respond. Bugs, incoherence and crutches.

Opponents of static typing say that early catching errors is not so important.


Alo. Your task board is packed with bugs that developers allowed. Repairing bugs is a big part of all the work in the industry. We spend billions of human hours to fix ridiculously ridiculous mistakes. Do you write code without bugs? or do you only have smart bugs? Yes, hell swam there. If the compiler did not check for you that you closed the curly brace, believe me, we would have hundreds of bugs with an open brace.

When you think about where the bug can potentially occur and where not, a dangerous illusion appears that you are in control of the situation and foresee all the cases. I have been working for seven years, there has never been such a thing that I foresaw all the cases. Because this is a special case of the traveling salesman problem - you NEVER can foresee all cases. You cannot even consider the most common and probable. When, who and in what situation will write the code with a critical bug, in which module and how he will do it - you, damn it, have no idea. All you can do is reduce the chance of a bug. So reduce it, you get paid crazy money for this.

Opponents of static typing contrast types with tests.


I will not say that they are idiots, I will say that they simply did not think about it well. Here is the obvious truth for you - tests record that the existing code works under certain conditions. And types guarantee that code that has not yet been written will be written under certain conditions. Tests are needed. Types are needed. You still reduce the chances that everything will fall. In a world where we have a budget to discuss with the team for five hours what is wrong with our Edge, there will be time to add annotations and a couple of tests.

Nerds from the dynamic world say that static typing deprives code of flexibility.


I don’t understand what kind of flexibility they are talking about. Even in the impoverished C #, the type system allows me not to have control over data types whose type does not matter to me. I can always prove to the language that here, they say, listen here, I can’t describe what this thing is, but I know for sure that it has such a field, of this type or of this type. And I will only work with him. Any statically typed language allows this. And flexibility and the freedom to write code that just can't work - I don't need such flexibility.

JS teens say static typing shifts the focus from task to type description.


And I say that the description of types is the description of the process that you automate. In object-oriented programming, in functional programming, in any other programming, we describe things from the real world, and our code contains the knowledge about them, without which it cannot work. You will still be doing this work.

If the type system of a specific language does not allow you to describe your domain correctly and securely - this is a problem of a particular language, and not of static typing in general. This is normal, and specifically in this language you use all kinds of object and dynamic in places, but wherever you can get guarantees, you get them.

I wrote code with both dynamic typing and static. With strict and non-strict, with structural and nominative.

Only the dynamic one made me feel strongly that I was writing a child pseudo-code that would work only if the stars converged.


Dynamic typing is a toy, a thing that will work when you decide to code something into one and forget about it. When you are planning to develop, when other people will work with your code, when the code comes out on the prod and starts solving user problems, updating once a week - dynamic typing is absolutely unacceptable. Just remember this and go change the extensions of your files from .js to .ts.


And look at my podcast - there’s a new issue

More articles:


All Articles