Static versus Dynamic Languages

One of the great debates among programmers is about static versus dynamic languages. It’s a debate that will go on forever because both sides have good points. The basic difference has to do with when errors are detected. In a dynamic language, errors aren’t caught until the bad code is executed. For example, in a dynamic language like Python, if you write a method call like x.foo(), and x doesn’t have a “foo” method, you won’t get an error message until that statement actually executes. In a static language, you need to declare types for things. Then, using the information provided by those declarations, errors like the undefined method in the example above can be caught at compile time.

It’s a trade-off: in dynamic languages, you don’t need to write type declarations to prove to the compiler that your program is correct. That’s very convenient, and it can lead to a style of programming in which your code is much simpler—and simpler code is less likely to have hard-to-find errors.

On the other hand, static languages catch a lot of mistakes for you. They force you to be more rigorous about how you write your code in order to make sure that it passes the compiler, and that process causes you to produce better-designed code.

Personally, I fall on the static language side of things. I find that the extra work of dealing with the type system saves me a huge amount of effort in the long run. Most of the silly mistakes that I make get caught by the compiler and never cause problems at runtime. In fact, my own preference is for very strongly typed languages, like the functional language ML. ML’s type system is incredibly expressive and incredibly strict, much more so than more familiar static languages like Java and C++. But in return, my ML programs almost never have runtime errors. Nearly all of the mistakes that I make end up getting reflected as inconsistencies in types. I’ve written thousand-line programs in ML and had them work without a single error on the first run after spending days working with the compiler to get rid of the statically detected type errors.

Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011