DenkzeitWiki

Static Vs Dynamic Typing Arguments

Different kinds of typing

• static
  • variables have types
• optional static
  • static typing added to usually dynamically typed systems
  • going static after the dynamic phase of the project settled.
• dynamic
  • not variables but values have types
• TypeInference
  • the type is infered by the methods that are invoked on a object

Type inference may quack like dynamic typing, it may walk like dynamic typing, and it may fly like dynamic typing, but it doesn’t swim like dynamic typing. [1]

Pro static

• find bugs at compile time
• better support by IDE (refactoring)
• faster executed
• the bondage and constraint inflicted by static typing controls the programmer\developer. Useful in larger companies where the individual programmer is not trusted and to enforce group-practices.
• types promote DesignByContract quite low-level
• good for doing Big Design Up Front
• refactoring (starting with renaming) is secure. Renaming is provably secure (i.e. no errors will be introduced by renaming).
• one does not have to remember where that object is coming from (type) - you'll have to remember with dynamically typed languages.
• The case for static types
  • Improve robustness via early detection
  • Increase performance by reducing needed checks
  • Exceeding the limits of unit tests
• http://www.serpentine.com/blog/2007/07/29/on-the-value-of-strong-static-typing/

Imagine, for example, that, in OCaml, you can't pass a file handle that was not opened for reading into a function that will read from it. That is an error that is stopped statically.

• Strong Typing, interesting examples in ML

This means that the type checker has found an infinite loop bug in our program. Ponder that for a minute.

Con static

• UnitTests have to be written anyhow. The bugs that can be found with tests are much more sophisticated than the bugs found by static typing.
  • I.e. the ErrorsFoundByCompilers will be found by UnitTests, too. Those test will have to be written in statically and dynamically typed languages.

A type system is a set of tests. It's just the set of tests a language designer could invent without seeing your program. The tests are hard-coded in the compiler and it would be nice to have more control over them. [2]

• static typing is PrematureOptimization

I've been struggling with this general problem for a long time. That is, the "logical" arguments that are very hard to refute, like "software is created by typing." True on the surface, but not really the essence of the issue. But if you keep the argument on those terms, you can't really get anywhere, because the logic is irrefutable. Even if that logic completely misses the real issue.
This is probably why I keep fighting with the static-dynamic language debate, because it has the same feel to me. You can come up with all kinds of reasons that static checking is a good thing, until you have an experience programming in a dynamic language where you are vastly more productive than with a static language. But that experience defies the logic used to back up the reasoning behind static languages.Programming as Typing

• Static Typing is Communist Bureaucracy

Pro dynamic

• don't worry about types - just call a method (DuckTyping) - maximal flexibility
• the programm can be refactored, grown, evolved much more readily
  • Refactor more often to understand the benefits of that [3]
  • suitable for ExplorativeProgramming
    • will it be a list, set or hashtable that should be passed into that function? in statically typed language you'll have to decide (and have big changes if you gain deeper insights that inflict changes). In dynamically typed languages nothing has to be changed (at least to get the tests running again). [4]
• all those type-annotations get in the way of readable code.
  • but heck, what's the type of the parameter just passed in the method? ;-)
    • never mind!
• succinct, concise code
  • But: TypeInference can be that, too!
• weaving UnitTests into the code is much easier in DL
• A good test suite is way better than a compiler.
  • Of course it is but you have to invest time and money for a good test suite. The compiler is already there and does some very good "sanity checking" on your code before it's ever executed. [5]
• WardCunningham via JonUdell:
  • http://www.infoworld.com/article/03/02/13/07stratdev_1.html

And here we run into a major disconnect. To the enterprise, scripted solutions look like one-offs, not strategic systems designed to high standards of quality and able to evolve along with the business. What the enterprise folks don't get is that scripted systems can be engineered to meet these requirements. So they lean toward C++ and Java, and then rely on powerful integrated development environments, like Eclipse and IntelliJ IDEA, to make fluid refactoring possible. These tools can work very well. "They're complicated," observes Ward, "and you have to learn how to work them -- but boy, when you do, they make those languages start to feel like scripting languages."[6]

• Python in London Banking
  • Rapid development
  • Experienced programmers can learn Python very quickly
  • Simple cross-platform deployment
  • Debugging interpreted languages tends to be easier (and require simpler tools)
  • Hot fixes can be applies in place, just by modifying a source file if necessary
  • A mature language, with good performance, that interfaces to C libraries and other languages
  • A wide variety of quality libraries available

Con dynamic

• Refactoring is not well supported by IDEs (RefactoringInDynamicLanguages)
  
• Refactoring without breaking code is hard ('where is that type used?') -> RefactoringInDynamicLanguages
  
• http://www.artima.com/scalazine/articles/twitter_on_scala.html

As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place.

• static type is safe, dynamic types makes more fun
• static type helps the unexperienced programmer

The debate

• Programming with "Duh" Typing

Ultimately, I have found that big programs written in dynamic languages don't age as well as those written in a statically typed language because developers are more afraid to refactor them.