Static typing
It is said that the programming language static typing when checking type is performed at compile time as against run time. With static typing, types are associated with variables and not values. Statically typed languages include Ada, C, C ++, C #, JADE, Java, Fortran, Haskell, ML, Pascal, Pearl (with respect to the difference between scalars, arrays, hashes, and routines) and Scala. Static typing is a limited form of verification program (see security type): accordingly, it allows many types of errors, which should be the development cycle. Static type checkers evaluate only the type of information that can be determined at compile time, but you can verify that the conditions being checked are met for all possible program execution, which eliminates the need to repeat type checks every time the program is executed. Program execution can also be more efficient (i.e., faster or lower memory) by eliminating runtime type checks and allowing other optimizations.
Because they evaluate type information at compile time, and because the drawback is the type of information that is only available at run time, the static type of checkers is conservative. They will reject some programs that may be well-behaved at runtime, but this cannot be statically determined as well-typed. For example, even if an expression always evaluates to true at run time, a program containing code
if <complex test> then 42 else <type error>
will be rejected as unassigned because static analysis cannot determine that the else branch will not be accepted. [1] The conservative behavior of static type controllers is beneficial when it incorrectly evaluates false: A static type of check can detect the type of error in rarely used codes. Without checking the static type, even code coverage tests with 100 percent code coverage may not be able to find such types. A code coverage test may not detect such type errors because a combination of all places where values are created and all places where a specific value is used should be taken into account.
The most widely used statically typed languages are not formally safe. They have “loopholes” in the specification of the programming language allowing programmers to write code that bypasses the checks performed by the static type controller and therefore address a wider range of problems. For example, Java and most C-style languages are punning, and Haskell has features such as unsafePerformIO: such operations can be unsafe at runtime because they can cause unwanted behavior due to incorrect input of values when the program is running.
Dynamic typing
It is said that a programming language is dynamically typed or simply "dynamic", when most of its types are checked, it is executed at run time, as opposed to at compile time. With dynamic typing, types are associated with values, not variables. Dynamically typed languages include Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (relatively custom types, but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk, and Tcl. Compared to static typing, dynamic typing can be more flexible (for example, allowing programs to generate types and functionality from data at run time), although at the expense of fewer a priori guarantees. This is because a dynamically typed language accepts and tries to execute some programs, which may be an invalid static type of verification.
Dynamic typing can lead to runtime of a type, that is, at runtime, the value can have an unexpected type and an operation meaningless for this type is applied. This operation can occur long after the place where the programming error was made - that is, the place where the wrong data type went into the place where it should not have. This makes it difficult to find a mistake.
Dynamically typed language systems, compared to their statically typed cousins, make less "compilation time", checks the source code (but will check, for example, that the program is syntactically correct). At run time, checks can potentially be more complex because they can use dynamic information, as well as any information that was present during the compilation. On the other hand, run-time checks only claim to have conditions in a particular program execution, and these checks are repeated for each program run.
The development of dynamically typed languages is often supported by programming practices such as unit testing. Testing is a key practice in professional software development and is especially important in dynamically typed languages. In practice, the testing carried out to ensure the correct operation of the program can have a much wider range of errors than static type checking, but, on the contrary, cannot search comprehensively for errors that are both testing and static type checking. Testing can be included in the software assembly cycle, in which case it can be considered as "compilation time", check that the user of the program will not need to manually run such tests.
References
- Pierce, Benjamin (2002). Types and programming languages. MIT Press. ISBN 0-262-16209-1.