Lets first look at what are Static typed languages.
Static typing is when the the type of variable is known before running a program. In other words, in static typed languages, you have to declare the type of variable before it is used. In such languages, variable is bind to a specific type.
Most of the 'industry standard' languages like Java, C, C++, Pascal are statically typed languages.
There are some obvious advantage of using the static typing.
- Statically typed languages are potentially more secure as they can catch the typing errors during compile type only, before actually running the program.
- The performance of statically typed languages can be better. The compiler has the type information of a variable and it can potentially use it for improving performance. There are more opportunities for compiler optimization which can make it run effectively.
- Code written in static typed languages is easier to understand. The type specification acts as a implicit code documentation in the program. And unlike code comments, this documentation don't have danger of getting outdated. So, in turn, this leads to self documented code.
- Better IDE support is available. As the type of the variable is already determined, a intelligent IDE like Eclipse or IntelliJ can provide features such as auto completion.
In Dynamic typing, the type of the variable is determined at run time. In such languages, you don't need to declare a variable before it is used. Languages like Smalltalk, Lisp, Perl, Python, PHP, Javascript, Ruby are dynamic languages.
The advantages offered by dynamic typed languages are much attractive.
- First and foremost (according to me), Programming is more fun in dynamically typed language. You don't need to keep on declaring although you know that there is no value in it and its only required by your programming language, just for the understanding of compiler.
- A program can be written much concisely in dynamic programming languages. The decrease in the amount of code is not achieved only by omitting the variable declaration but the reusability and flexibility of the code increases greatly because of dynamic typing.
Lets look at the implementation of method that checks if the object is null or empty in Java
boolean isNullOrEmpty(String string) {
return ( string==null ) || (string.length() == 0 );
}
The problem with this method is that only objects of type String can access it. If you want to implement same method for any different object, you need to duplicate the method with different parameter.
And the same method in Ruby..
def isNullOrEmpty? object
object == nil or object.length == 0
end
As the type of the parameter is not specified, you can use this same method for any object that has length method, including any custom objects.
This feature is also called as Duck Typing in the ruby lingo. Duck typing suggests that Object type is determined by the behavior. That means, rather than checking for the type
of object, we just check if the object supports required operation.
However, advocates of static typing criticize of dynamic typing for some reason. Lets look the issues and see if we can resolve them.
- Dynamic typing can make code difficult to understand. The type of variable or the return type of method is not declared in code. So, it can be difficult to imagine what will be in a variable during runtime.
This problem is mostly faced by newcomers or people who are coming from the static typed programming background. However, some real application code can be enough
complex to confuse most experienced programmers also. The problem can be partially solved by proper naming conventions and also by witting unit tests. Properly designed Units tests helps to revel the purpose of code.Informative coding convention (like suffixing the method names with ? when the return type is boolean) and unit tests can help in understanding the code without the using verbose nature of static typed languages.
- Dynamic typed languages are more error prone as they dont perform the type checking before running the program. The program gives run time exception in case of typing errors which could be caught at compile time by static typed language compilers.
The frequency of run time errors due to typing issues is itself questionable. Although there is a possibility of such errors, the occourance of such events is rare even in complex system. And again, the practice of TDD or writting unit tests helps to capture the type errors.
In fact, statically typed languages are also not totally type safe. The type casts can fail at run time. Thats the reason we have ClassCastException in Java. The down casting - casting a object downwords in class hierarchy can be error prone.
- Dynamic typed languages are not suited for enterprise products and applications. Because of the lack of type checking and (so called)slower performance as compared to static typed languages, dynamic typed languages are good for fun programming but not for developing serious applications.
The company where I work, ThoughtWorks, is one of the industry leader in developing Ruby apps. If anyone has doubt if Ruby, one of the newest dynamic typing language is
enterprise-ready, I will suggest them to check out Mingle (http://studios.thoughtworks.com/mingle-project-intelligence), a project management tool developed in Ruby using rails and Oracle mix (https://mix.oracle.com/) which is a first public JRuby on Rails site. The performance and stability of these products is really good.
My personal choice is dynamic typing cause the programming with them is more fun for me. The ability of these languages to produce concise, reusable code has really amazed me. Although the features of static typed languages like ability to run code faster and checking for type errors before run time are nice to have, but these features comes with cost. So for me, languages with dynamic typing rocks ! :-)
