In an earlier post I mentioned I'd come back to the advantages of dynamic typing. My primary reference for all the quotes and information is the dynamic type wikipedia page. But if you're not very familiar with programming it can read like a spooky animal. I'll try to translate by pointing out a couple of advantages of each that relate to my personal experience.
Definition of a Type System
A type system describes what each block of memory is and can be thought of as metadata or descriptive information. Type information aids the interpreter or compiler to translate your brilliant code* into assembly and binaries to run on a specified platform.
So the essence of typing is to prevent or catch errors where data or operations are misclassified and misused. Basically, don't put the square peg in the round hole. This can happen before run time with static typed languages which are compiled. Or it can happen at run time with dynamic typed languages. Maybe we'd be better off with type agnostic compilers and interpreters. More on this later.
Why do we need run time typing at all?
Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.
Static typing defined
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. In static typing, types are associated with variables not values. Statically typed languages include Ada, AS3, C, C++, C#, F#, JADE, Java, Fortran, Haskell, ML, Pascal, Perl (with respect to distinguishing scalars, arrays, hashes and subroutines) and Scala. Static typing is a limited form of program verification (see type safety): accordingly, it allows many type errors to be caught early in the development cycle.
The features of static typed languages are:
- compile time checking of correct types. But static type checks are more restrictive as they can dissallow completey acceptable code. Static type languages usually have methods around this by allowing type casting
- built in documentation, knowing data or function type aids others in understanding code flow
- no need to do extensive type checking in unity tests
- specific optimizations: This allows optimization by knowing how to align memory of a certain type
Dynamic typing in a nutshell
The type of nut or even that an object IS a nut isn't checked until run time.
In dynamic typing, types are associated with values not variables. Dynamically typed languages include Erlang, Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (with respect to user-defined types but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk and Tcl. Compared to static typing, dynamic typing can be more flexible (e.g. by allowing programs to generate types and functionality based on run-time data), though at the expense of fewer a priori guarantees
The features of dynamic typed languages are:
- dynamic typing gives a coder more flexibility by allowing type generation on the fly during code execution
- as long as an object has the methods used it can function within any other range of interfaces without a complex inheritance tree (thank David Pollack's Scala post below for this point)
- dynamic languages encourage unit testing, which can capture a wide range of errors beyond type safety (behaviorial feature?)
Conclusions
Static and dynamic typing can coexist in a programming language. Coding behavior or the human pattern may be more important than whether a language is static or dynamically typed. Although opinions can sway strongly to one side or the other, this post on the Scala blog covers the topic well.
Earlier I mentioned the possibility for type agnostic compilers or interpreters. A language with this feature would require a machine architecture that is capable of using handlers to process data without ever having to know what the data was or how the handlers work. Even the knowledge of whether a memory block was a handler or data would be unknown. There'd need to be a way to connect memory locations, to change other memory locations. Agnostic memory structures would create a completely dynamic language.
Notes:
* If you're reading this post I'm giving you the benefit of the doubt