any-language – Why do we need dynamic typing?

Question:

There is a class of languages ​​where typing is dynamic, for example JavaScript, VB, etc.

As an adherent of strict typing, I do not understand the sacred meaning of this.

Well, yes, it seems cool to build a class in JavaScript on the fly. However, what's the point? After all, I can declare everything here and now and build the necessary models, because I must know in advance what I will have to work with.

In T-SQL, dynamic queries are justified, but again it all boils down to a finite set of some sort of filter filters.

In my opinion, there are some disadvantages:

  1. IDE, as a rule, cannot immediately issue errors during startup
  2. Auto-substitution of variants works crookedly, since the variable is dynamic
  3. Yes, and in your head you need to remember that this variable has such and such a type, and here it changed its type to another …

Answer:

The fact is that the absence of types kills many birds with one stone. The main ones are the readability of the code, and the increase in the ease 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 is tactically – in order to quickly solve problems. But the adherent of strong typing may not feel these advantages at first, for example, I myself once switched from C ++ to JS and PHP – and probably for another year I was indignant. I will try to explain ..

Brain resources . The presence of types in the code creates an additional non-weak semantic load, and requires serious brain expenditures for memorizing the hierarchy, for reading the code, so that these same types are written with 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 RAM. For scripting languages, such a goal, as a rule, is not worth it (and modern compilers no longer eat too much in the absence of types), and therefore the decisive factors in typing a language are precisely the perception of types by the brains of programmers in the context of the tasks of a scripting language.

Structural complexity . In scripts, emphasis is placed on the possible complexity of the script, with high readability. And here JS has succeeded – reading any JS code, you can see how attention is diverted from the object-type component, and attention is focused on the structural component: nested closures, functional programming, asynchronous programming. And there would be types in JS – of course, there would be no such effect of code perception.

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

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 is written in three lines instead of 15. The classic implementation of the old GoF patterns in typed languages ​​today is more like crutches, which are simply there to compensate for the lack of flexibility in the presence of strong typing – accordingly they are unreadable, you need to deal with them more seriously, bother yourself with questions "why is this?" "is this a facade or an adapter?", etc. In JS, plus to the old ones, completely different approaches based on closures, encapsulation, and FP appear. When implementing the same task in the style of OOP classics in TS, and in the style of FP in JS, the result is:

  1. The JS code is 3 times more compact, and more readable than the strongly typed code 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 the DOM – and its task is mainly to manipulate this DOM over time. That is, no serious OOP structures are required, the built-in is more than enough: handling DOM events, asynchronous JS capabilities. This, coupled with the lack of typing, makes JS code "the quintessential control logic". "Simplicity of programming" 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 manually validated in JS, but this is done extremely rarely, except that there are often empty checks like if (!param1) return false; … Why don't they? Because JS carries a style of code in which type is not the main characteristic of a 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, with crutches and bicycles, of course, you can do a strong semblance of OOP – once (far from ES6) the creators of mootools asked this question, and today 90% of JS programmers dealing with mootools consider it the worst framework of all times and peoples) Why? Yes, because JS has the richest functionality, including with regards to encapsulation (so necessary for large projects), many ways to make extension points "safe" for a program, a lot of "own patterns", he does not need OOP to make a high-quality extensible program of any scale. Typification, the more strict – is the locomotive of the "old-fashioned OOP" – and, accordingly, an oppressor of flexible ways of building programs.
The latter is that when working in the IDE, the autocomplete and "transition to the class" do not work well. It happens, but if you do 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) – it works well with navigation in JS without JSDoc, and promises that it will be fine soon.

He described in his own words as best he could, but it is difficult to explain the many advantages of the lack of types to a programmer in strongly typed languages: this is almost to convey to 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 readability of the code, for example, in function arguments. But when types are used sometimes, and not in 100% of the code. But if you allow only types in arguments in JS (for example, as in TS), programmers will immediately begin to abuse OOP, and kill the formed style of the language, and with this all the advantages of JS – I think this is the reason for the ideology of EcmaScript typing. Strong typing is useless and even harmful, but only if we are not talking about maximum performance: then there are no questions, strong typing will win.

Scroll to Top