Why do I need dynamic typing?

The fact is that the absence of types kills many birds with one stone. The main ones are the readability of the code, and improving the simplicity of programming in general. The first is very important strategically, so that with a large amount of code, long development, the project is still readable and extensible, the second-tactically-to quickly solve problems. But an adherent of strict typing may not feel these advantages at first, for example, I myself once switched from C++ to JS and PHP-and probably resented it for another year. I'll try to explain..

Brain resources. The presence of types in the code creates an additional significant semantic load, and requires serious brain costs for memorizing the hierarchy, reading the code, and writing these very types at every "sneeze" in the code. In compiled code, types used to carry their main meaning-the maximum speed of the program, the minimum consumption of OP. For scripting languages, such a goal is usually not worth it (and modern compilers are no longer available). too much is eaten away in the absence of types), and therefore the decisive factors of language typing are precisely the perception of types by the brains of programmers in the context of the tasks of a scripting language.

Structural complexity. The scripts focus on the possible complexity of the script, with high readability. And here JS succeeded - reading any JS code, you can see how attention is diverted from the object-type component, and focuses on the structural component: nested closures, functional programming, asynchronous programming. And if there were types in JS , there would certainly be no such effect of code perception.

Readability. If you correctly name the variables in the JS code , the code will read like a book, despite the structural complexity. But when types are added to variables, the readability loses a lot: the reading programmer gets a lot of unnecessary information. Here in everyday life we say Убери яблоко в холодильник and not Убери красное круглое яблоко в большой серебристый холодильник, since the first is easier to perceive. For example, I would compare reading the JS code of any widely distributed library to reading Pushkin's poems, whereas reading typed C++ code is like reading Homer's Illiad (now).

About the simplicity of programming without types. It turns out that without types, and with developed functional tools: half of the patterns are not needed, the second half of the patterns are written in three lines instead of 15. The classic implementation of old GoF patterns in typed languages today is more similar on crutches, which are simply there to compensate for the lack of flexibility in the presence of strict typing-accordingly, they are unreadable, you need to deal with them more seriously, fill your head with questions "why is this?" "is it a facade or an adapter?", etc.In JS, there are also completely different approaches to the old ones, based on closures, encapsulation, and OP. When implementing the same task in the style of OOP classics on TS, and in the style of FP on JS, what comes out in the end:

1. The code in JS is obtained it is 3 times more compact, and more readable than the code with strict typing on the same TS.
2. The programmer implements the task faster, in proportion to the amount of code.

Plus, JS works mainly with a tree-like database called DOM - and its task is basically managing this DOM in dynamics. That is, no serious OOP structures are required, the built-in is more than enough: DOM event processing, asynchronous JS capabilities. This, coupled with the lack of typing, makes the JS code "the quintessence of control logic". "Ease of programming" - this does not mean that JS programmers will have a freebie, it means that a good programmer will have time to do 3 times more.

What does JS lose without types?
The first thing that JS loses is the automatic validation of incoming function parameters - this is almost the main role that types play in modern scripting languages. Parameters can be validated manually in JS, but this is rarely done, except often there are void checks of the form if (!param1) return false;. Why don't they do it? Yes, because JS carries a style of code in which type is not the main characteristic of the variable - and programmers quickly understand this.
The second thing that JS loses is the lack of the ability to build a classic OOP architecture. No, crutches and bicycles can certainly do a strong semblance of OOP-once (far from ES6) this question was asked by the creators of mootools, and today 90% of JS programmers who are faced with mootools consider it the worst framework of all time) Why? Yes, because JS has a wealth of functionality, including with regard to encapsulation(so necessary for large projects), a lot of ways to make" safe "extension points for the program, a lot of" its own patterns", it does not need OOP to make a high-quality extensible program of any scale. Typing, especially strict-there is a locomotive of the "grandfather's OOP" - and, accordingly, the oppressor of flexible ways of building programs.
The last is when working in the IDE, autocomplete and "transition to class" work poorly. This happens, but if you still decide to write OOP-like code in js, then use JSDoc to help the IDE. At the same time, poor navigation is a problem of the IDE itself, for example, PhpStorm(WebStorm) - works well with navigation in JS and without JSDoc, and promises that it will be fine soon.

I described it in my own words as best I could, but it is difficult to explain the many advantages of absence types to a programmer in strongly-typed languages: it's almost like telling a Buddhist that Christianity is cool :)

UPD but in order not to turn the answer into a malicious holivar, it should be noted that types are also useful for the same code readability, for example, in function arguments. But when types are used sometimes, not in 100% of the code. But if you allow only types in arguments in JS (for example, as in TS), programmers will immediately start abusing OOP, and kill the established style the language, and with it all the advantages of JS-I think this is the reason for the ideology of typing ECMAScript. Strict typing is useless and even harmful, but only if we are not talking about maximum performance: then there is no question, strict typing will win.

The compactness of the code, basically. Let's say we have several classes that occupy a completely different place in the inheritance hierarchy, but are united by the presence of a common SaveToFile method that takes a single string argument (the path to the file). Then we want to write a function that will save all the elements from an array of arbitrary objects to a file.

In a statically typed language, we will need to declare the interface, mark all classes with the SaveToFile method as implementing it, and use type casting:

interface ISaveable{
  void SaveToFile(string path);
}

void SaveAll(object[] array, string path){
    for(int i=0; i<array.Length; i++){
       ((ISaveable)array[i]).SaveToFile(path + '_' + i.ToString());
    }
}

In a language with dynamic typing, everything will be much shorter:

function SaveAll(array, path){
    for(i=0; i<array.length; i++){
       array[i].SaveToFile(path + '_' + i);
    }
}

Code brevity is not always welcome, but for scripting languages that often write programs "at a time", or when saving on the size of the source code is important (browser-based JavaScript), this advantage can come to the fore.

Learn more about comparing dynamic and static typing: Is there a real advantage to dynamic languages?

High-level languages are invented in order to speed up the process of achieving the final result.

Quote from here. Languages with dynamic typing are needed for exactly the same thing: to get a working result faster.

Working means earning money. After all, programming is a practical discipline, which means that in one way or another it comes down either to saving the user or developer time, or to earned or saved money. money.