Monday, March 17, 2008

Static vs Dynamic Typing

I thought I knew the differences between static and dynamic typing. I was wrong. I thought it was the way you declare the variables and functions in certain ways. Whether assigning types to values or expressions. Static typing refers to types declared in a program at compile-time. Dynamic typing refers to types declared in a program at run-time. There is more to it though. I'm still trying to understand what it all means. Some languages use static typing and others use dynamic typing. I think C uses static typing and Java uses dynamic typing. There are many differing views on the subject. Some think static typing is better for testing then unit testing. Others disagree. I'm still researching to get a better understanding of the difference.

8 comments:

aaron said...

keola check out: http://en.wikipedia.org/wiki/Type_system

more specifically, check out the "Type checking" section. that explains a little bit about what the differences are.

dng said...

Static typing is type checking performed during compile-time. Static typing allows program errors to be caught earlier and program execution to be more efficient.

Dynamic typing is type checking performed during run-time. Dynamic typing is more flexible although slower running and more prone to program errors.

Is this a better explanation of the difference? Why is it important to know the difference? Does it help when writing code?

synthesis said...

Java is statically typed and Ruby is dynamically typed. Dynamically typed code can write code that writes code. Everything can be changed at runtime. This usually gives you a lot of power resulting in fewer lines of code.

aaron said...

well thats not entirely true. java has casting which is a sort of dynamically typed mechanism.

austen.ito said...

While it is true that Java lets you use casting, which resembles dynamic typing, that casting is still done at compile time. The compiler enforces restrictions on what you can cast things to. For example, if you create a String, try to cast it to another object like a BufferedImage. The compiler will give you an error.

The same is true for polymorphism. In Java you can have objects be of different types in the same class hierarchy, but that typing is done at compile time. At runtime it goes and figures out what the type of the object is.

With pure dynamic typed languages like Ruby, you don't have that compile time check. (Assuming you are using the compiler for Ruby. If not its interpreted at runtime) Types don't even matter until runtime when you need to operate on objects. What that buys you is the ability to write less code because all of the code dealing with the types of objects and casting will be removed. It also makes your code easier to extend because changing class interfaces won't cause the compiler to complain. You can continue to work as normal and hopefully your unit tests will catch the problems.

Hopefully that makes sense. I just started working with Ruby, so I'll let James the Ruby master correct me.

austen.ito said...

hrm. forgot to check the notify me button

aaron said...

What that buys you is the ability to write less code because all of the code dealing with the types of objects and casting will be removed. It also makes your code easier to extend because changing class interfaces won't cause the compiler to complain.

there is gotta be more benefit than that...

austen.ito said...

Those are the two main benefits that I recieve. I'm sure there are more.