What is the difference between a static and dynamic programming language?

I'm going to talk here in a way that people understand. If you go to study type theory you will see that some things there are different from this.

There is some confusion in several terms on this subject. In some cases there is no universally accepted formal definition.

Popularly languages are classified by their typing, so static languages are formally languages that have static typing. And dynamic languages have typing dynamic.

Some languages can be classified as dynamic because they have other characteristics. They allow arbitrary code execution(eval) or the transformation of existing codes at runtime. It is increasingly common for modern languages to allow these flexibilities. It does not matter the typing, so formally there are languages that are dynamic by this definition and static by typing.

Definition

Static

A basic definition of static typing that a programming language can have as a characteristic is that there is a check of the types used in data and variables to ensure that a type is always being used that is expected in all situations. This check is done in the source code by the build process. This analysis helps in calling type safety in the use of data by the program allowing the programmer to worry less about this issue. We compiler provides guarantees that some problems may not occur after the program goes through this check, i.e. errors are detected right before the program is actually run.

A variable cannot change its type.

However static typing can cause a false sense of security. Only a part of the errors can be discovered in advance.

Example (it's in C# but it could well be pseudocode):

var x = 1;
x = "1"; //erro de compilação, não pode trocar o tipo da variável

Dynamics

In dynamic typing this check also occurs but it is done on top of the data itself, since variables can contain any type of data. Of course, at a given time a variable can only contain one type of data and this is verified. But the main difference is that this check is done at runtime. This is done through an auxiliary infrastructure (a virtual machine or a library usually called a runtime ). It is common for the programmer to have to do their own checks on the program or on external test codes to ensure that all types are correct at the right times. The programmer has to worry more about types although in simple solutions it may seem that worry is not necessary.

What is dynamic effectively is the type of the variable. Understanding and documenting the types are still needed. There are languages that encourage documentation in the code with Hungarian notation .

Data needs to be represented concretely on the computer. variable is a design pattern (variable ). So it's an abstraction. Data cannot take multiple forms, at most it can be interpreted in different ways in specific cases. Variables can refer to different types. Therefore dynamic typing is usually a special case of static typing. Second Bob Harper ,one of the creators of the standard ML language, "a dynamically typed language is a statically typed language with only one static type".

In practice dynamic typing is an abstraction as well. There is an illusion that you can refer to a data that has different types but in practice there is only one marker and there is a pointing to a different static data.

The most common techniques to achieve this illusion is the use of a union type (union in C / C++) and / or pointers without type specification(void * in C / C++). All data will have some overhead of memory.

Example (it is in JavaScript but could be pseudocode, note that the syntax is identical to the previous example but the semantics are different)

var x = 1;
x = "1"; //operação normal, o tipo que era um number passa ser string

Performance

Another big difference is in relation to performance. Although it is possible to make optimizations in a program written with "dynamic language" to approaching or even exceeding the performance of programs written in "static languages", because of the difficulty of achieving this is usually not done effectively. In theory a JIT compiler has more conditions to optimize code with accurate information of how the program will run and even in practice can even achieve some better result in isolation.

On the other hand if you already know what you're going to deal with, you don't need to have anything in the generated code helping the operation in the program and the program itself does not need to have certain checks written by the programmer. If the check is done before execution a program with static typing does not need to have this job during execution.

Also does not help the fact that most dynamically typed programs will run on a virtual machine as this facilitates language development and allows some extra flexibilities normally desirable in "languages dynamics".

In practice languages are not usually 100% anything. Pragmatic tools know when to run away a bit from a concept to give better advantage to the programmer.

Hybrid languages

There are hybrid languages. In practice it is not possible to have both forms of typing but it is possible to use part of one or the other concept.

Static language with dynamic types

When a language is considered static, formally it has static typing, it may have the necessary infrastructure to store different data in a variable . But the data is saved in a different way than the other types. You'll have a static type that can store data dynamically, but the language still has static typing at its core.

Roughly speaking the language uses an extra data structure to store its type and indicate where the actual data is. It is usually done in the library and it usually has compiler help only to indicate that the check normally done should be relaxed since the check will be done by this library to a certain extent and also by the programmer to avoid that certain errors will be generated in runtime through this library.

Dynamic language with static types

Language with dynamic typing cannot effectively be partially static. After all a dynamic language, formally that the typing be dynamic, should always expect any type. If it starts waiting for a specific type and does the check before execution, it turns into "static language". It is not possible to reduce the level of abstraction.

It is even possible to provide a previous Type check as an additional feature of the language but it does not make much sense if it is not accompanied by the change in the way data is managed in memory. If the program needs to have its fixed types and guaranteed in advance it would be a waste to use a structure that allows to have several types. This structure has memory cost (tag of type, references to type in all situations^*) and processing (extra indirection, selection of the specific data/Method to be used).

Doesn't make sense, but languages are doing this, almost all mainstream languages are adopting a form that approaches, without being, typing static.

Manifest typing

It is possible for a "dynamic language" to use manifest typing without changing its dynamic typing characteristic. The advantage is small or even questionable.

But there are also cases of languages that can compile parts of code with static typing and parts with dynamic typing. The interface between the parts need to be normalized one way or another. Interestingly, some prefer to define themselves as static or dynamic to try to instill one predominant culture and use the other as an exception. Purists, for better or for worse, consider it a bad choice. In fact there are two very similar languages in this case and not just one.

^*some static languages have references for types when data is stored in the heap . And even in the stack the information will still exist in the code to allow reflection, but there will be no memory consumption in the stack to save the type.

Inference

Static typing does not mean that all types need to be explicitly declared. It is common, in most situations, for the compiler to be able to infer the type of a variable according to its assignment or even its use (less common).

The great advantage of static typing is more in the fact that the variable cannot change its type. This really helps development a lot. Having to write the type explicitly helps little or nothing. Some think it gets more readable when the type is written, others think it's just compiler deficiency.

Then it is possible to have a "static language" that uses implicit typing by partially reducing the ceremony that these languages usually have.

Hack

PHP has the possibility to do a type check before execution but this helps little because the language is usually executed from form interpreted and mainly because it can not check all types, all situations, so you have no security at all. Security is defined by the weakest link. During execution everything is dynamic.

I don't know the Hack language enough to tell you how it works but it looks like it has static typing.

Eventually one can use the type mixed which is that data structure that will allow any data to be stored there. It is likely that the compiler treats this type differently. The program treats data dynamically by exception, the programmer says that there anything can happen because this is what he wants.

For several reasons it seems that Hack is PHP that drinks in the water of C#, it seems to me that mixed behaves like the dynamic of C#.

Advantages and disadvantages

Often the advantages and disadvantages vary according to the eyes of the beholder. Programmers disagree on what is really a advantage, not least because almost everything is a matter of trade-off, so [it's easier to talk about differences. Some of them can be:

The main advantages of" static languages " are security, performance and development time support (refactoring, code completion, auxiliary information, code coverage, etc.).

"dynamic languages" are flexible , rapid prototyping, concise .

It is good to understand that the more complicated bugs remain complicated equally in both types.

There is certainly an advantage to "dynamic languages" when thinking about the development of the language itself. Defining the language and creating a basic implementation is much simpler than a "static language". But to create a powerful implementation that can solve some of your disadvantages, it becomes a difficult job. To date, no one has solved all the disadvantages.

Strong and weak typing

Sometimes these concepts are confused with strong and weak typing. This is partly because the strength of typing is not well defined and is not universally accepted.

Strong typing is usually the characteristic that does not allow the same data to be treated as if it were of another type. It is very common for static languages to have strong typing. But there are exceptions.

This gives the code more robustness.

C, for example, allows one data to be accessed/interpreted as if it were another. Can, for example:

• write a int and access it as if it were a pointer.
• write a float and access as if it were a int. True, the result will be catastrophic in this case, but it is possible.
• get a 0 and be considered false or other numbers (no matter what type) to be interpreted as true in operations that require a boolean.
• write two short in sequence and read as one int. Probably nothing useful will be obtained but it is possible.
• record "SOpt" and read this as if it were a int, I don't know why.

C is a weak typing language. C++ too, although it tries to reinforce a style where this is not so used.

C / C++ compilers try to prevent this from being used abusively.

Hence we conclude that type security is not an inherent feature of so-called static languages. Security can be broken by other factors. type safety is another different concept that can be mistakenly confused with strong typing and static typing.

Many "dynamic languages" have strong typing, but others have weak typing, typically creating implicit coercions. Coercion is common in some situations under defined rules. Example: "1" == 1 is true and 1 + "1" gives "11".

Implicit coercion has the advantage of making the code slightly shorter. This is often characteristic of script languages, where code size makes a difference. So, languages made to develop applications, as opposed to scripts, should not have this feature (Hello PHP).

The definition of these terms do not help much and say that a language is weakly or strongly typed in an exclusive way is also not usually true.

In general we can say something like this:

• variable has type = > typing static
• variable without type = > typing dynamic
• value has type = > typing strong
• value without type = > typing weak

Languages of script

It becomes increasingly difficult to define script languages. They are usually dynamic but nothing prevents them from being static.

Dynamic typing gives more flexibility and helps make small applications quickly. These languages often require little ceremony and dynamic typing provides little ceremony in typing. But it is more a matter of adequacy than a requirement.

Dynamic languages usually perform more form interpreted than compiled and is another indirect factor that helps to be used to make scripts. But it's just a facilitator, again, it's not a requirement.

No Language wants to lose space so more and more static (typing) languages allow dynamic typing characteristics, reflection, conciseness, and simplified execution (illusion of interpretation). Thus they can be considered from script as well, although it is not his main focus.

In addition to adequacy, the characteristic of script is more tied to the implementation than to the language itself.

A reflection

If a language allows its static types to have values that are invalid or do not match what is expected in this type, a null for example, does it still have static typing? It seems so, but there is doubt whether they should. Breaks the security of types and in a certain way can be interpreted as the given it could have two types. It forces a check on the runtime to ensure that there will be no problems with the type.

Which is better?

The question you don't want and probably will never shut up is: which is better?

It is obvious that there is not universally one better than the other. We can always talk the cliché that there is a better tool for a problem.

In practice I see that the choice falls, most of the time, on taste and experience. And this is good. I often say that before you choose the best tool for the problem, choose something that you know and feel comfortable using: "the best tool is the one you know how to use". It is the old dispute between engineers who want everything to be perfect and administrators who want the best result to come. An electric saw cuts wood faster and more accurately. A weekend Joiner can get hurt with a saw electric.

Of course there are cases that technically one is better than the other but this is getting more and more subtle.

My personal observation is that "dynamic language" programmers often think less about the problem and create overly simplified designs that bring future problems. But there are cases that a better design is not advantage.

On the other hand I see that programmers of "static languages" tend to think too much about the problems and they create overly complicated designs without bringing many future advantages and not solving all future problems.

Note that this does not define the quality of the programmer and let alone that 100% of programmers are so in 100% of cases. There are cases that the opposite happens. And it really should. When programming in "dynamic languages" early planning is often more important.

I cannot say that typing itself is responsible for the trend (if it is true). It may be the kind of programmer that typing attracts. It is the surfer going to the sea with waves and not the sea with waves making the subject turn surfer. Maybe people choose typing for the wrong reasons.

What I see happening a lot is that programmers who use "static languages" do not use the dynamic facilities existing in these languages unless there is no other way. And programmers of "dynamic languages" think that checking the contracts should never be made within code (in fact these languages do not usually provide facilities for this). I don't know if it should be like this.

PDF with something more formalized to read . And a very complete publication and apparently very well founded.

See also: what is typing style?.