Dynamic typing. Likbez by typing in programming languages \u200b\u200bDynamic typing is better than strict

This article contains the necessary minimum of those things that you just need to know about typing, so as not to call the dynamic typing by evil, the LISP is a busty language, and C language with strict typing.

In the full version there is a detailed description of all types of typing, seasoned with examples of code, references to popular programming languages \u200b\u200band explicit pictures.

I recommend reading first a brief version of the article and then with desire and complete.

Brief version

Typification programming languages \u200b\u200bare made to divide into two large camps - typed and non-type (busty). To the first, for example, C, Python, Scala, PHP and LUA include, and the second is the assembler language, Forth and Brainfuck.

Since "conventional typification" is inherently simple as a traffic jam, then it is not divided into any other species. But typed languages \u200b\u200bare divided into several other intersecting categories:

Static / dynamic typing. Static is determined by the fact that the final types of variables and functions are set at the compilation stage. Those. Already the compiler is 100% sure which type where is located. In dynamic typing, all types are found already during the execution of the program.
Examples:
Static: C, Java, C #;
Dynamic: Python, JavaScript, Ruby.
Strong / weak typification (also sometimes say strict / non-stroke). Strong typing is allocated by the fact that the language does not allow you to mix different types in expressions and does not automatically implicit conversions, for example, you cannot deduct from the string set. Languages \u200b\u200bwith weak typisation perform a variety of implicit transformations automatically, even if the loss of accuracy or the conversion may occur in ambiguously.
Examples:
Strong: Java, Python, Haskell, Lisp;
Weak: C, JavaScript, Visual Basic, PHP.
Explicit / implicit typification. Explicit-typed languages \u200b\u200bare distinguished by the fact that the type of new variables / functions / their arguments should be specified explicitly. Accordingly, languages \u200b\u200bwith implicit typisation shift this task on the compiler / interpreter.
Examples:
Explicit: C ++, D, C #
Implicit: PHP, LUA, JavaScript

It should also be noted that all these categories intersect, for example, C language has static weak explicit typisation, and Python language is a dynamic strong implicit.

However, no less than languages \u200b\u200bfrom static and dynamic typisations at the same time. Although running forward, I will say that I am here, they really exist, but about it later.

Detailed version

If a brief version seemed not enough, good. No wonder I wrote a detailed one? The main thing is that in a brief version it was simply impossible to fit all the useful and interesting information, and the detailed would be too long that everyone could read it, not straining.

Basic typification

In the breasted programming languages \u200b\u200b- all entities are considered simply bit sequences, different lengths.

Bestipa typification is usually inherent in low level (assembler, forth) and esoteric (Brainfuck, HQ9, Piet) languages. However, she, along with disadvantages, have some advantages.

Benefits

Allows you to write on a maximum low level, and the compiler / interpreter will not interfere with any types of types. You are free to produce any operations on any data types.
The resulting code is usually more efficient.
Transparency of instructions. With the knowledge of the language, there is usually no doubt that one or another code represents.

disadvantages

Complexity. Often there is a need to present comprehensive values, such as lists, rows or structures. There may be inconveniences.
No checks. Any meaningless actions, such as subtraction of a pointer to an array of the symbol, will be considered completely normal, which is fraught with employment errors.
Low abstraction. Working with any complex type of data is no different from working with numbers, that of course will create a lot of difficulties.

Strong prickly typification?

Yes, it exists. For example, in the assembler language (for the X86 / X86-64 architecture, I do not know others) You can not assemble the program if you try to upload to the CX register (16 bits) data from the RAX register (64 bits).

mOV CX, EAX; Error assembly time

So it turns out that there is still typing in the assemser? I believe that these checks are not enough. And your opinion, of course, depends only on you.

Static and dynamic typing

The main thing is that distinguishes static (static) typing from dynamic (dynamic) that all types of types are performed at the compilation stage, not the execution stage.

Some people may seem that static typing is too limited (in fact, it is, but it has long been getting rid of some methods). Some same way that dynamically typed languages \u200b\u200bare a game with fire, but what features are they allocated? Do both species have a chance of existence? If not, why there are many more than statically and dynamically typed languages?

Let's figure it out.

Benefits of static typing

Type checks occur only once - at the compilation stage. And this means that we will not need to constantly find out if we are trying to divide the number on the string (and either give the error or to transform).
Performance speed. It is clear from the previous point that statically typed languages \u200b\u200bare almost always faster than dynamically typed.
With some additional conditions, it allows you to detect potential errors at the compilation stage.

Advantages of dynamic typing

Easy to create universal collections - a bunch of all and all (it rarely arises such a need, but when dynamic typing arises to help).
Ease of describing generalized algorithms (for example, sorting an array that will work not only on the list of integers, but also on the list of real and even on the list of lines).
Easy in development - languages \u200b\u200bwith dynamic typilation are usually very good in order to start programming.

Generalized programming

Well, the most important argument for dynamic typing is the convenience of describing generalized algorithms. Let's imagine a problem - we need a search function for several arrays (or lists) - by the array of integers, according to the array of real and array of characters.

How will we solve it? I solve it on the 3rd different languages: one with dynamic typing and two with static.

Search algorithm I will take one of the simplest - bust. The function will receive the desired element, the array itself (or list) and return the index of the element, or, if the item is not found - (-1).

Dynamic solution (Python):

Def Find (Required_element, List): For (Index, Element) in Enumerate (List): If Element \u003d\u003d Required_element: Return Index Return (-1)

As you can see, everything is simple and no problem with the fact that the list can contain at least numbers, even though there are no other arrays. Very good. Let's go further - I decide this task on C!

Static solution (C):

Unsigned int find_int (int order_element, int array, unsigned int size) (for (unsigned int i \u003d 0; i< size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_float(float required_element, float array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_char(char required_element, char array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); }

Well, each function is individually similar to the version of Python, but why are there three? Is it really static programming?

Yes and no. There are several programming techniques, one of which we now consider. It is called generalized programming and C ++ language supports it well. Let's look at the new version:

Static solution (generalized programming, C ++):

Template. Unsigned int Find (T Required_element, Std :: Vector array) (for Unsigned int i \u003d 0; i< array.size(); ++i) if (required_element == array[i]) return i; return (-1); }

Okay! It looks not much more difficult than the version on Python and at the same time did not have to write a lot. In addition, we got the implementation for all arrays, and not just for the 3rd needed to solve the problem!

This version seems to be exactly what you need - we get at the same time pluses of static typing and some advantages are dynamic.

It's great that it is generally possible, but maybe even better. First, generalized programming can be more convenient and more beautiful (for example in Haskell). Secondly, in addition to generalized programming, it is also possible to apply a polymorphism (the result will be worse), the overloading of functions (similarly) or macros.

Statistics in dynamics

It is also necessary to mention that many static languages \u200b\u200ballow you to use dynamic typing, for example:

C # supports pseudo-type dynamic.
F # supports syntax sugar in the form of an operator?, On the basis of which the imitation of dynamic typing can be implemented.
Haskell - Dynamic typing is provided by the Data.dynamic module.
Delphi - through a special type of Variant.

Also, some dynamically typed languages \u200b\u200ballow you to take advantage of static typing:

COMMON LISP - Types Declaration.
Perl - from version 5.6, quite limited.

Strong and weak typisius

Languages \u200b\u200bwith strong typing do not allow mixing the essence of different types in expressions and do not perform any automatic transformations. Also they are called "Languages \u200b\u200bwith strict typing". English term for this - Strong Typing.

Weakly typified languages, on the contrary, in full fat, so that the programmer mixes different types in one expression, and the compiler itself will result all to a single type. They also call "Languages \u200b\u200bwith non-starting typisation." English term for this is weak typing.

Weak typisation is often confused with dynamic, which is completely incorrect. A dynamically typed language can be weak and strongly typed.

However, few who attaches the value of the rigor of typing. It is often claimed that if the language is statically typed, you can catch a lot of potential errors when compiling. They lie you!

The language should have more and strong typing. And truth, if the compiler, instead of an error message, will simply add a row to a number, or what is even worse, the deduction of one massif is another, what is the use of the types that all the "checks" will be at the compilation stage? That's right - weak static typing is even worse than strong dynamic! (Well, this is my opinion)

So what about weak typisius do not have enough plus? Perhaps it looks like this, but despite the fact that I should agree with a thorough supporter of strong typing, it also has advantages.

Want to know what?

Benefits of strong typing

Reliability - you will get an exception or error of compilation, instead of incorrect behavior.
Speed \u200b\u200b- instead of hidden transformations that can be quite expensive, with strong typing it is necessary to write them clearly, which causes a programmer at least to know that this section of the code can be slow.
Understanding the work of the program - Again, instead of impregnated types of types, the programmer writes everything myself, which means roughly understands that the comparison of the string and the number does not happen by itself.
Note - When you write conversion manually, you know exactly what you convert and what. You will also always understand that such transformations can lead to loss of accuracy and incorrect results.

The advantages of weak typing

Ease of use of mixed expressions (for example, from integers and real numbers).
Abstraction from typing and focusing on the task.
Brief recording.

Okay, we figured out, it turns out to have a weak typification, too, there are advantages! Are there any ways to move the pros of weak typification into strong?

It turns out that even two.

Implicit clarification of types, in unambiguous situations and without data loss

Wow ... quite a long item. Let me continue to cut it to the "limited implicit transformation" so what does the unambiguous situation and loss of data mean?

An unambiguous situation is a transformation or an operation in which the essence is immediately understood. For example, the addition of two numbers is a unambiguous situation. And the transformation of the number into an array is no (it is possible to create an array from one element, possibly an array, with such a long, filled with default elements, and the number may be converted into the string, and then into an array of characters).

Loss of data is even easier. If we convert a real number 3.5 to the whole - we will lose part of the data (in fact, this operation is also ambiguous - how will rounding? Also? In a smaller way? Drop the fractional part?).

Transformations in ambiguous situations and conversion with data loss are very, very bad. There is nothing worse in programming.

If you do not believe me, learn the PL / I language or just look for its specification. It has rules for transformation between all types of data! It's just hell!

Okay, let's remember the limited implicit conversion. Are there such languages? Yes, for example, in Pascal, you can convert an integer into a real one, but not vice versa. Also similar mechanisms are in C #, Groovy and Common Lisp.

Well, I said that there is still a way to get a couple of advantages of weak typification in a strong language. And yes, it is and called the polymorphism of the designers.

I will explain it on the example of a wonderful language Haskell.

Polymorphic designers appeared as a result of observation, which most often safe implicit transformations are needed when using numerical literals.

For example, in the expression PI + 1, I do not want to write PI + 1.0 or PI + Float (1). I want to write just pi + 1!

And this is done in Haskell, due to the fact that the literal 1 does not have a specific type. This is neither nor real nor complex. It's just a number!

As a result, when writing a simple SUM XY function, moving all numbers from x to Y (with increment in 1), we get several versions - SUM for integers, SUM for real, SUM for rational, SUM for complex numbers and even SUM for all These numeric types that you themselves have identified.

Of course, this reception is saved only when using mixed expressions with numeric literals, and this is only the top of the iceberg.

Thus, it can be said that the best output will be balancing on the verge, between strong and weak typing. But while the perfect balance does not hold any language, so I'm more inclined to strongly typed languages \u200b\u200b(such as Haskell, Java, C #, Python), and not to weakly typed (such as C, JavaScript, Lua, PHP).

Explicit and implicit typification

The language with explicit typisation assumes that the programmer must specify the types of all variables and functions that announce. English term for this - Explicit typing.

The language with implicit typisation, on the contrary, offers you to forget about the types and shift the task of outputting types to the compiler or interpreter. English term for this - implicit typing.

In the beginning, it is possible to decide that implicit typing is equivalent to dynamic, and explicitly static, but then we will see that it is not.

Are there any advantages from each species, and again, are there any combinations and is there languages \u200b\u200bwith the support of both methods?

Advantages of explicit typification

The presence of the signature function (for example, int ADD (int, int)) allows you to determine without any problems that the function does.
The programmer immediately writes how the type of value can be stored in a specific variable, which removes the need to memorize it.

The advantages of implicit typing

Record reducing - DEF Add (x, y) is clearly shorter than int x, int y).
Resistance to changes. For example, if the temporary variable function was the same type as the input argument, then in an explicitly typed language when the type of argument is changed, the type of temporary variable will also be changed.

Well, it can be seen that both approaches have both the pros and cons (and who expected something else?), So let's find ways to combine these two approaches!

Explicit typification

Without explicitly specifying type ADD (x, y) \u003d x + y - explicit indication of the type ADD :: (Integer, Integer) -\u003e integer add (x, y) \u003d x + y

Note: I intended to use a non-marked function, and also intends to record a private signature instead of more general add :: (num a) -\u003e a -\u003e a -\u003e a, because I wanted to show the idea, without explaining the Haskell syntax "a.

Hmm As we see, it is very beautiful and short. The function record takes only 18 characters on one line, including spaces!

However, the automatic output of the types is quite complex thing, and even in such a cool language as Haskell, it sometimes does not cope. (as an example, the monomorphism limit can be obtained)

Are there languages \u200b\u200bwith explicit typisation of the default and implicit necessity? Kon.
eony.

Implicit typification

In the new C ++ language standard called C ++ 11 (previously called C ++ 0x), the AUTO keyword was entered, thanks to which you can make the compiler output, based on the context:

Let's compare: // manual indication of the type unsigned int a \u003d 5; unsigned int b \u003d a + 3; // Automatic output of the type unsigned int a \u003d 5; AUTO B \u003d A + 3;

Not bad. But the record was not much reduced. Let's see an example with the iterators (if you do not understand, do not be afraid, the main thing is to notice that the recording is very much reduced by the automatic conclusion):

// manual indication type STD :: Vector Vec \u003d RandomVector (30); For (std :: vector :: const_terator it \u003d vec.cbegin (); ...) (...) // Automatic output of type AUTO VEC \u003d RandomVector (thirty); For (AUTO IT \u003d vec.cbegin (); ...) (...)

Wow! This is a reduction. Okay, but is it possible to do anything in the Haskell spirit, where the type of return value will depend on the types of arguments?

And again the answer is yes, thanks to the keyword decltype in combination with AUTO:

// manual indication of the type int divide (int x, int y) (...) // Automatic output of the type AUTO Divide (int x, int y) -\u003e decltype (x / y) (...)

It may seem that this form of recording is not very good, but in combination with generalized programming (Templates / Generics), implicit typing or automatic output of types are creating wonders.

Some programming languages \u200b\u200bfor this classification

I will give a small list of popular languages \u200b\u200band write how they are divided by each category of "typisations".

JavaScript - dynamic / weak / implicit Ruby - dynamic / severe / implicit Python - dynamic / severe / implicit Java - static / severe / explicit PHP - dynamic / weak / implicit C - static / weak / explicit C ++ - static / semi-syl / explicit perl - dynamic / weak / implicit Objective-C - static / weak / explicit C # - static / severe / explicit Haskell - static / strong / implicit Common Lisp - dynamic / severe / implicit

Maybe I was wrong somewhere, especially with CL, PHP and OBJ-C, if you have a different opinion in any language - write in the comments.

Conclusion

Okay. It will soon be light and I feel that there is nothing more about typication. Oh how? Theme bottomless? Is there a lot of unreliable? I ask in the comments, share useful information.

This article tells about the difference between statically typed and dynamically typed languages, considers the concepts of "strong" and "weak" typing, and compares the power of typing systems in different languages. Recently, a clear movement is observed towards more stringent and powerful typification systems in programming, so it is important to understand what we are talking when they talk about types and typing.

Type is a collection of possible values. An integer may possess the values \u200b\u200bof 0, 1, 2, 3, and so on. Boolean can be true or false. You can come up with your type, for example, the type "Daipe", in which the values \u200b\u200bof "give" and "5" are possible, and nothing else. This is not a string and not a number, it is a new one, a separate type.

Statically typed languages \u200b\u200blimit the types of variables: the programming language can know, for example, that X is an integer. In this case, the programmer is prohibited to do x \u003d true, it will be an incorrect code. The compiler will refuse to compile it, so that we can not even run such a code. Another statically typed language can have other expressive capabilities, and no of the popular types of types can express our type of dive (but many can express other, more sophisticated ideas).

Dynamically typed languages \u200b\u200bmark values \u200b\u200blike: The language knows that 1 is Integer, 2 is an Integer, but it cannot know that the variable x always contains an integer.

The runtime environment checks these tags at different times. If we try to fold two values, it can check whether they are numbers, rows or arrays. Then she will fold these values, gluits them or give an error, depending on the type.

Statically typed languages

Static languages \u200b\u200bcheck types in the program during compilation, before the program is launched. Any program in which types violate the rules of the language is considered incorrect. For example, most static languages \u200b\u200bwill dismiss the expression "a" + 1 (C language is an exception to this rule). The compiler knows that "a" is a string, and 1 is an integer, and that + works only when the left and right part belongs to one type. So he does not need to run the program to understand that there is a problem. Each expression in a statically typed language refers to a specific type that can be determined without starting the code.

Many statically typed languages \u200b\u200brequire a type. The function in Java Public Int Add (int x, int y) takes two integers and returns the third integer. Other statically typed languages \u200b\u200bcan determine the type automatically. The same function of addition in Haskell looks like this: ADD X Y \u003d X + Y. We do not inform the types of types, but it can define them yourself, because it knows that + works only in numbers, so x and y should be numbers, then the AD function takes two numbers as arguments.

This does not reduce the "staticness" of the types of types. The type system in Haskell is famous for its static, severity and power, and in all these fronts Haskell is ahead of Java.

Dynamically typed languages

Dynamically typed languages \u200b\u200bdo not require specify type, but also do not determine it. Types of variables are unknown to the moment when they have specific values \u200b\u200bwhen starting. For example, a function in Python

DEF F (X, Y): Return X + Y

it can fold two integers, glue strings, lists, and so on, and we cannot understand what exactly happens until we start the program. Perhaps at some point the function f will be caused with two lines, and with two numbers at another moment. In this case, X and Y will contain values \u200b\u200bof different types at different times. Therefore, it is said that the values \u200b\u200bin dynamic languages \u200b\u200bhave a type, but variables and functions - no. The value of 1 is definitely an Integer, but x and y can be anything.

Comparison

Most dynamic languages \u200b\u200bwill issue an error if the types are used incorrectly (JavaScript is a certain exception; it tries to return the value for any expression, even when it does not make sense). When using dynamically typed languages, even a simple error of the type "A" + 1 may occur in a combat environment. Static languages \u200b\u200bprevent such errors, but, of course, the degree of prevention depends on the power of the type system.

Static and dynamic languages \u200b\u200bare built on fundamentally different ideas about the correctness of the programs. In the dynamic language "A" + 1, this is the correct program: the code will be launched and an error will appear in the execution environment. However, in most statically typed languages, the expression "A" + 1 is not program: It will not be compiled and will not be launched. This is an incorrect code, as well as a set of random characters! &% ^ @ * &% ^ @ * - This is an incorrect code. This is an additional concept of correctness and incorrectness has no equivalent in dynamic languages.

Strong and weak typification

The concepts of "strong" and "weak" are very ambiguous. Here are some examples of their use:

Sometimes "strong" means "static".
It's simple here, but it is better to use the term "static", because most use and understand it.

Sometimes "strong" means "does not make an implicit type conversion."
For example, JavaScript allows you to write "a" + 1, which can be called "weak typisation". But almost all languages \u200b\u200bprovide one or another level of implicit conversion, which allows you to automatically proceed from integers to the floating-point numbers like 1 + 1.1. In reality, most people use the word "strong" to determine the boundary between an acceptable and unacceptable transformation. There is no generally accepted border, they are all inaccurate and depend on the opinion of a particular person.

Sometimes "strong" means that it is impossible to circumvent strict rules for typing in the language.

Sometimes "strong" means safe for memory (Memory-Safe).
C is an example of unsafe for language memory. If XS is an array of four numbers, then si will be happy to execute the XS or XS code, returning some value from the memory immediately for XS.

Let's stop. This is how some languages \u200b\u200bmeet these definitions. As you can see, only Haskell is "strong" in all parameters. Most languages \u200b\u200bare not so clear.

("When as" in the "implicit conversion" column means that the separation between the strong and weak depends on which transformations we consider acceptable).

Often, the terms "strong" and "weak" refer to an indefinite combination of different definitions above, and other definitions not shown here. All this disorder makes the words "strong" and "weak" practically meaningless. When you want to use these terms, it is better to describe what exactly meaning. For example, we can say that "JavaScript returns a value when the string is folded with the number, but Python returns an error." In this case, we will not spend our strength on attempts to come to an agreement on the many values \u200b\u200bof the word "strong". Or, even worse: we will come to unresolved misunderstanding due to terminology.

In most cases, the terms "strong" and "weak" on the Internet are unclear and poorly defined opinions of specific people. They are used to call the language "bad" or "good", and this opinion turns into a technical jargon.

Strong typification: the type system that I love and with which I comfortable.
Weak typification: type system that bothers me or with which I am not comfortable.

Gradual Typing (Gradual Typing)

Can I add static types to dynamic languages? In some cases - yes. In others it is difficult or impossible. The most obvious problem is EVAL and other similar possibilities of dynamic languages. Performing 1 + Eval ("2") in Python gives 3. But what will give 1 + Eval (read_from_the_network ())? It depends on the fact that on the network at the time of execution. If you get a number, the expression is correct. If the string is not. It is impossible to learn before starting, so it is impossible to analyze the type statically.

The unsatisfactory solution in practice is to specify an EVAL () type Any, which reminds Object in some object-oriented programming languages \u200b\u200bor Interface () in GO: This type to which any value satisfies.

Any values \u200b\u200bare not limited to anything, so it disappears the possibility of a type system to help us in the EVAL code. Languages \u200b\u200bin which there are both EVAL and type system must refuse type security with each EVAL use.

In some languages, there is optional or gradual typing (gradual typing): they are dynamic by default, but allow you to add some static annotations. Python recently added optional types; TypeScript is an add-in over JavaScript, which has optional types; Flow produces a static analysis of the old good code on JavaScript.

These languages \u200b\u200bprovide some of the advantages of static typing, but they will never give absolute guarantees, as truly static languages. Some functions will be statically typed, and some will be dynamically typed. The programmer always needs to know and fear the difference.

Compilation of statically typed code

When a compilation of a statically typed code is compiled, the syntax is checked first as in any compiler. Then the types are checked. This means that the static language first can complain to one syntactic error, and after it is fixed, complain to 100 typification errors. Correction of the syntax error did not create these 100 errors of typing. The compiler simply did not have the ability to detect type errors until the syntax was corrected.

Compilers of static languages \u200b\u200bcan usually generate faster code than dynamic compilers. For example, if the compiler knows that the ADD feature takes integers, it can use the native instruction of the ADD central processor. Dynamic language will check the type when executing, choosing one of the plurality of add functions depending on the types (fold integers or floats or glue the strings or, maybe lists?) Or you need to decide what an error occurred and the types do not correspond to each other. All these checks occupy time. In dynamic languages, different tricks are used to optimize, such as JIT compilation (Just-in-Time), where the code will be recompiled when performing after receiving all the necessary information about the types of information. However, no dynamic language can be compared at speeds with a gentially written static code in the language like RUST.

Arguments in favor of static and dynamic types

Supporters of the static type system indicate that without type of types, simple errors can lead to problems in production. This, of course, is true. Anyone who used a dynamic language experienced it.

Supporters of dynamic languages \u200b\u200bindicate that in such languages, it seems, it is easier to write code. This is definitely fair for some types of code, which we write from time to time, like, for example, the code with EVAL. This is a controversial solution for regular work, and here it makes sense to remember the uncertain word "easily". Rich Hicks spoke perfectly about the word "easily", and his connection with the word "simply". After seeing this report, you will understand that it is not easy to use the word "easy". Fuck "ease".

The pros and cons of static and dynamic typification systems are still poorly studied, but they definitely depend on the language and the specific task being solved.

JavaScript is trying to continue working, even if it means a meaningless conversion (like "A" + 1, giving "A1"). Python in turn tries to be conservative and often returns errors, as in the case of "a" + 1.

There are different approaches with different security levels, but Python and JavaScript are both dynamically typed languages.

Haskell will not allow the addition of integer and float without explicit conversion before that. SI and Haskell are both statically typed, despite such great differences.

There are many variations of dynamic and static languages. Any unconditional statement of the type "Static Languages \u200b\u200bis better than dynamic when it comes to x" is almost guaranteed nonsense. It may be true in the case of specific languages, but then it is better to say "Haskell is better than Python when it comes to x".

A variety of static typing systems

Let's take a look at the two famous examples of statically typed languages: Go and Haskell. In the TIP system, GO has no generalized types, types with "parameters" from other types. For example, you can create your own type for Mylist lists, which can store any data we need. We want to be able to create a mylist integers, mylist strings and so on, without changing the source code of MyList. The compiler must follow the typing: if there is a mylist integers, and we will accidentally add a string there, the compiler must reject the program.

GO was specifically designed in such a way that it was impossible to set the types like myList. The best thing is possible to do is create a mylist "empty interfaces": MyList can contain objects, but the compiler simply does not know their type. When we get objects from myList, we need to tell the compiler of their type. If we say "I'll get the string", but in reality, the value is a number, then there will be an execution error, as in the case of dynamic languages.

There are also many other features that are present in modern languages \u200b\u200bstatically (or even in some of the 1970s). The creators of the GO had their own reasons for these solutions, but the opinion of people on the part of this occasion can sometimes sound sharply.

Now let's compare with Haskell, which has a very powerful type system. If you specify the Mylist type, the type of "list of numbers" is just a Mylist Integer. Haskell will not give us a chance to add a string to the list, and make sure that we will not put an element from the list into the string variable.

Haskell can express much more complex ideas directly by types. For example, Num a \u003d\u003e MyList A means "MyList values \u200b\u200bthat relate to one type of numbers." This may be a list of Integer "OB, Float" OB or decimal numbers with fixed accuracy, but this will definitely never be a list of rows, which is checked when compiling.

You can write the ADD function that works with any numerical types. This feature will be the type Num a \u003d\u003e (A -\u003e A -\u003e A). It means:

a may be any numerical type (num a \u003d\u003e).
The function takes two arguments of type A and returns type A (A -\u003e A -\u003e A).

The last example. If the function type is String -\u003e String, it takes the string and returns the string. But if it is String -\u003e Io String, it also makes some kind of input / output. It may be accessing the disk to the network, reading from the terminal and so on.

If the function is in the type not Io, we know that it does not make any I / O operations. In the web application, for example, you can understand whether the function of the database changes simply by looking at its type. No dynamic and almost no static languages \u200b\u200bon such. This is a feature of languages \u200b\u200bwith the most powerful typing system.

In most languages, we would have to deal with the function and all the functions that are called from there, and so on, in trying to find something changing the database. This is a tedious process in which it is easy to allow an error. And the Haskell type system can answer this question simply and guaranteed.

Compare this power with GO, which is not able to express a simple idea of \u200b\u200bmyList, not to mention the "function that takes two arguments, and they are both numerical and one type, and which makes the input / output."

The Go approach simplifies writing tools for programming on GO (in particular, the compiler implementation may be simple). In addition, it is required to learn less concepts. How these advantages are comparable with significant restrictions - a subjective issue. However, it is impossible to argue that Haskell is harder to explore than GO, and that the type of type in Haskell is much more powerful, and that Haskell can prevent much more bug types when compiling.

Go and Haskell are so different languages \u200b\u200bthat their grouping in one class of "static languages" can be misleading, despite the fact that the term is used correctly. If you compare the practical advantages of security, then go closer to dynamic languages \u200b\u200bthan to Haskell "y.

On the other hand, some dynamic languages \u200b\u200bare safer than some static languages. (Python as a whole is considered much safer than C). When I want to make a generalization of static or dynamic languages \u200b\u200bas groups, then do not forget about the huge number of differences between languages.

Specific examples of differences in the possibilities of typing systems

In more powerful typing systems, you can specify restrictions on smaller levels. Here are some examples, but do not dwell on them if the syntax is incomprehensible.

In Go, you can say "The Add function takes two Integer" A and returns Integer ":

FUNC Add (X INT, Y INT) INT (RETURN X + Y)

In Haskell, you can say "feature takes any Numerical type and returns the number of the same type ":

F :: Num a \u003d\u003e a -\u003e a -\u003e a add x y \u003d x + y

In iDris, you can say "The function takes two Integer" and returns Integer, but the first argument should be less than the second argument ":

Add: (X: Nat) -\u003e (Y: Nat) -\u003e (Auto Smaller: LT X Y) -\u003e NAT Add x Y \u003d X + Y

If you try to call the ADD 2 1 function, where the first argument is greater than the second, then the compiler will dismiss the program during compilation. It is impossible to write a program where the first argument is greater than the second. A rare language has such an opportunity. In most languages, this test occurs when performing: we would write something like if x\u003e \u003d y: raise someerror ().

In Haskell, there is no equivalent to such a type as in the example with iDris above, and in GO there is no equivalent to experiment with Haskell, or an example with IDRIS. As a result, IDRIS can prevent many bugs that will not be able to prevent Haskell, and Haskell will be able to prevent many bugs that GO will not notice. In both cases, additional features of the typing system are needed, which will make the language more complicated.

Systems of typing some static languages

Here is a rough list of systems of typing some languages \u200b\u200bin increasing power. This list will give you a general idea of \u200b\u200bthe power of the systems, you do not need to treat it as an absolute truth. Languages \u200b\u200bcollected in one group can differ much from each other. Each typification system has its own problems, and most of them are very complex.

C (1972), GO (2009): These systems are not at all powerful, without the support of generalized types. It is impossible to set the type of myList, which would mean the "list of integers", "List of strings", etc. Instead, you will have to make a "list of unambiguous values." A programmer must manually report "This List of List" every time the string is extracted from the list, and this may result in error when execution.
Java (1995), C # (2000): Both languages \u200b\u200bsupport generalized types, so you can say myList And get a list of lines, about which the compiler knows and can monitor the observance of the types of types. Elements from the list will have the String type, the compiler will forcing the rules when compiling as usual, so that errors are less likely.
Haskell (1990), Rust (2010), SWIFT (2014): All these languages \u200b\u200bhave several advanced features, including generalized types, algebraic data types (ADTS), and types of types or something similar (types of classes, features (traits) and protocols, respectively). RUST and SWIFT are more popular than Haskell, and large organizations are promoted (Mozilla and Apple, respectively).
AGDA (2007), IDRIS (2011): These languages \u200b\u200bsupport dependent types, allowing you to create types like "a function that takes two integers x and y, where y is greater than x". Even the limit "y is greater than x" is forced when compiling. When performing y, it will never be less than or equal to X, whatever happens. Very subtle, but important properties of the system can be checked statically in these languages. They are studying very few programmers, but these languages \u200b\u200bcause their huge enthusiasm.

There is a clear movement towards more powerful typification systems, especially if you judge the popularity of languages, and not by the simple fact of the existence of languages. A well-known exception is GO, which explains why many supporters of static languages \u200b\u200bconsider it a step back.

Group Two (Java and C #) are mainstream languages, mature and widely used.

The group three is on the verge of entrance to Mainstream, with great support from Mozilla (Rust) and Apple (SWIFT).

Group Four (IDRIS and AGDA) are far from the mainstream, but it may change with time. Languages \u200b\u200bof the group three were far from the mainstream ten years ago.

This page is invited to combine with

Explanation of the reasons and discussion - on the Wikipedia page: To Union / October 28, 2009.
The discussion lasts one week (or longer if it goes slowly).
Discussion date - October 28, 2009..
If the discussion is not required (obvious case), use other templates.

Strict typification - One of the options for working with data types, which is used in programming languages.

Strict typing implies the following mandatory conditions:

Any data object (variable, constant, expression) in the language always has a strictly defined type that is fixed at the time of the compilation of the program (static typing) or is determined during the execution (dynamic typing).
It is allowed to assign a variable only a value having a strictly the same data type as the variable, the same limitations apply to transmit parameters and return the results of functions.
Each operation requires the parameters of strictly defined types.
Implicit type conversion is not allowed (that is, the translator perceives any attempt to use the value of the wrong type that was described for a variable, parameter, functions or operation, as a syntax error).

With accurately follow the requirements of strict typing, even the same amounts of values \u200b\u200band permissible data types are incompatible. If the program needs to assign a value of one type of variable of another type, this can be done, but only by explicitly applying a special type transformation operation, which in such cases is usually part of the programming language (although it may not be formally, and provided by standard libraries) .

The only practically used programming language with strict typing is hell. A fairly large number of common programming languages \u200b\u200buse non-static static typing. Such languages \u200b\u200binclude, for example Pascal, Module-2, Java. They are sure to describe the types of variables, parameters and functions, but implicit types of types are allowed - if the value of one type is assigned to the variable of the other, the compiler automatically generates the code to convert the value to the desired type if only such a conversion leads to data loss. For example, an integer can be assigned by a variable declared as a floating point number, and the reverse assignment without explicit type clarification is prohibited, since with a high probability will result in an error. Some languages \u200b\u200bformally having the concept of data type, in reality can be considered inepitis. These languages \u200b\u200binclude classic C, in which, although the declaration of types is required, in reality all types of data are compatible assignment (modern C compilations limit this freedom and issue at least warnings with hazardous types of types).

In the theory of programming, strict typing is an indispensable element of ensuring the reliability of the developed software. With proper use (implied that the program is announced and separate data types for logically incompatible values) It protects the programmer from simple, but difficult errors associated with the sharing of logically incompatible values \u200b\u200bthat occur sometimes simply due to the elementary clock. Such errors are revealed at the program compilation stage, whereas with the ability to implicitly bring almost any types to each other (as, for example, in the classical SI), these errors are detected only when testing, and not everything is not immediately. On the other hand, many professional programmers do not like strict typication due to its inconvenience - it increases the volume of the program and the time of its writing, requires a more thorough study of the code, which seems unnecessary.

Brief version

Typization programming languages \u200b\u200bare customary to divide into two large camps - types and netipelays (basic). To the first, for example, C, Python, Scala, PHP and LUA include, and the second is the assembler language, Forth and Brainfuck.

Static / dynamic Typification. Static is determined by the fact that the final types of variables and functions are set at the compilation stage. Those. Already the compiler is 100% sure which type where is located. In dynamic typing, all types are found already during the execution of the program.
Examples:
Static: C, Java, C #;
Dynamic: Python, JavaScript, Ruby.
Strong / weak Typification (also sometimes say strict / non-stroke). Strong typing is allocated by the fact that the language does not allow you to mix different types in expressions and does not automatically implicit conversions, for example, you cannot deduct from the string set. Languages \u200b\u200bwith weak typisation perform a variety of implicit transformations automatically, even if the loss of accuracy or the conversion may occur in ambiguously.
Examples:
Strong: Java, Python, Haskell, Lisp;
Weak: C, JavaScript, Visual Basic, PHP.
Explicit / nonavid Typification. Explicit-typed languages \u200b\u200bare distinguished by the fact that the type of new variables / functions / their arguments should be specified explicitly. Accordingly, languages \u200b\u200bwith implicit typisation shift this task on the compiler / interpreter.
Examples:
Explicit: C ++, D, C #
Implicit: PHP, LUA, JavaScript

It should also be noted that all these categories intersect, for example, C language has static weak explicit typisation, and Python language is a dynamic strong implicit.

However, no less than languages \u200b\u200bfrom static and dynamic typisations at the same time. Although running forward, I will say that I am here, they really exist, but about it later.

Detailed version

Basic typification

In the breasted programming languages \u200b\u200b- all entities are considered simply bit sequences, different lengths.

Bestipa typification is usually inherent in low level (assembler, forth) and esoteric (Brainfuck, HQ9, Piet) languages. However, she, along with disadvantages, have some advantages.

Benefits

Allows you to write on a maximum low level, and the compiler / interpreter will not interfere with any types of types. You are free to produce any operations on any data types.
The resulting code is usually more efficient.
Transparency of instructions. With the knowledge of the language, there is usually no doubt that one or another code represents.

disadvantages

Complexity. Often there is a need to present comprehensive values, such as lists, rows or structures. There may be inconveniences.
No checks. Any meaningless actions, such as subtraction of a pointer to an array of the symbol, will be considered completely normal, which is fraught with employment errors.
Low abstraction. Working with any complex type of data is no different from working with numbers, that of course will create a lot of difficulties.

Strong prickly typification?

MOV CX, EAX; Error assembly time

So it turns out that there is still typing in the assemser? I believe that these checks are not enough. And your opinion, of course, depends only on you.

Static and dynamic typing

The main thing is that distinguishes static (static) typing from dynamic (dynamic) that all types of types are performed at the compilation stage, not the execution stage.

Let's figure it out.

Benefits of static typing

Type checks occur only once - at the compilation stage. And this means that we will not need to constantly find out if we are trying to divide the number on the string (and either give the error or to transform).
Performance speed. It is clear from the previous point that statically typed languages \u200b\u200bare almost always faster than dynamically typed.
With some additional conditions, it allows you to detect potential errors at the compilation stage.
Acceleration of development with IDE support (sifting options, obviously not suitable by type).

Advantages of dynamic typing

Easy to create universal collections - a bunch of all and all (it rarely arises such a need, but when dynamic typing arises to help).
Ease of describing generalized algorithms (for example, sorting an array that will work not only on the list of integers, but also on the list of real and even on the list of lines).
Easy in development - languages \u200b\u200bwith dynamic typilation are usually very good in order to start programming.

Generalized programming

How will we solve it? I solve it on the 3rd different languages: one with dynamic typing and two with static.

Dynamic solution (Python):
Def Find (Required_element, List): For (Index, Element) in Enumerate (List): If Element \u003d\u003d Required_element: Return Index Return (-1)

Static solution (C):
unsigned int find_int (int order_element, int array, unsigned int size) (for (unsigned int i \u003d 0; i< size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_float(float required_element, float array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_char(char required_element, char array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); }

Well, each function is individually similar to the version of Python, but why are there three? Is it really static programming?

Yes and no. There are several programming techniques, one of which we now consider. It is called generalized programming and C ++ language supports it well. Let's look at the new version:

Static solution (generalized programming, C ++):
Template. Unsigned int Find (T Required_element, Std :: Vector array) (for Unsigned int i \u003d 0; i< array.size(); ++i) if (required_element == array[i]) return i; return (-1); }

This version seems to be exactly what you need - we get at the same time pluses of static typing and some advantages are dynamic.

Statistics in dynamics

It is also necessary to mention that many static languages \u200b\u200ballow you to use dynamic typing, for example:

C # supports pseudo-type dynamic.
F # supports syntax sugar in the form of an operator?, On the basis of which the imitation of dynamic typing can be implemented.
Haskell - Dynamic typing is provided by the Data.dynamic module.
Delphi - through a special type of Variant.

Also, some dynamically typed languages \u200b\u200ballow you to take advantage of static typing:

COMMON LISP - Types Declaration.
Perl - from version 5.6, quite limited.

So, go on?

Strong and weak typisius

Languages \u200b\u200bwith strong typing do not allow mixing the essence of different types in expressions and do not perform any automatic transformations. They also call "Languages \u200b\u200bwith strict typing". English term for this - Strong Typing.

Weakly typified languages, on the contrary, in full fat, so that the programmer mixes different types in one expression, and the compiler itself will result all to a single type. Also they are called "Languages \u200b\u200bwith non-starting typisation." English term for this is weak typing.

Weak typisation is often confused with dynamic, which is completely incorrect. A dynamically typed language can be weak and strongly typed.

However, few who attaches the value of the rigor of typing. It is often claimed that if the language is statically typed, you can catch a lot of potential errors when compiling. They lie you!

The language should have more and strong typing. And truth, if the compiler instead of an error message will simply add a row to the number, or what is even worse, the deduction from one array is different, what is the use of that all the "checks" of the types will be at the compilation stage? That's right - weak static typing is even worse than strong dynamic! (Well, this is my opinion)

So what about weak typisius do not have enough plus? Perhaps it looks like this, but despite the fact that I should agree with a thorough supporter of strong typing, it also has advantages.

Want to know what?

Benefits of strong typing

Reliability - you will get an exception or error of compilation, instead of incorrect behavior.
Speed \u200b\u200b- instead of hidden transformations that can be quite expensive, with strong typing it is necessary to write them clearly, which causes a programmer at least to know that this section of the code can be slow.
Understanding the work of the program - Again, instead of impregnated types of types, the programmer writes everything myself, which means roughly understands that the comparison of the string and the number does not happen by itself.
Note - When you write conversion manually, you know exactly what you convert and what. You will also always understand that such transformations can lead to loss of accuracy and incorrect results.

The advantages of weak typing

Ease of use of mixed expressions (for example, from integers and real numbers).
Abstraction from typing and focusing on the task.
Brief recording.

Okay, we figured out, it turns out to have a weak typification, too, there are advantages! Are there any ways to move the pros of weak typification into strong?

It turns out that even two.

Implicit clarification of types, in unambiguous situations and without data loss

Wow ... quite a long item. Let me continue to reduce it to the "limited implicit transformation" so what does the unambiguous situation and data loss mean?