4 ms·

Static typing began as a performance optimization for Fortran, early on when the developers realized it was a good idea to split ints and floats. If it were a p

Static typing began as a performance optimization for Fortran, early on when the developers realized it was a good idea to split ints and floats. If it were a performance optimization only, it probably would've faded from most modern languages entirely, but it offers new ways to think about languages and programming, and also allows tools to exist that can't be built for dynamically-typed languages, such as Ocaml's and Haskell's compile-time type-checkers, which are surprisingly good at catching bugs-- even ones that seem to have nothing to do with the type system. There are, likewise, functions and tools that can't be built in statically-typed languages. For example, a general "compose" function (or macro, if you're so inclined)-- one that takes a list of functions and produces their composition-- can't be built in a language like Ocaml. (The best you can do is ('a -> 'a) list -> ('a -> 'a) ; e.g. it has the additional requirement that each function have the same return type as its input.)

michaelneale 18y ago
>and also allows tools to exist that can't be built for dynamically-typed languages As well as the ones you mention - would you include IDEs etc ? or is that more an issue of not doing the "smalltalk way" of editing running code?
- time_management 18y ago
  I'm talking about the compile-time type checker that ML and Haskell have. This is a very powerful tool that doesn't exist in dynamically-typed languages. It seems like a mere curiosity, because a lot of the super-cool things you can do with type-checking are impractical (e.g. the use of phantom type hackery to do bounds-checking on arrays). However, on large projects with multiple programmers, it also helps to keep interfaces stable and self-documenting. For example, let's say you change the output type of a function deep in the trunk-- instead of returning a 'a or throwing an exception, it returns a 'a option, e.g. a discriminated union between None or Some x, where x is a 'a, using the None value to represent failure, in lieu of the exception-- and want to find all the places where things break in the leaf code, so you can adapt them to the changes. What tool do you use: grep? Nope. You attempt to compile the tree, and all the code-breaks are caught and displayed by the compiler.

michaelneale 18y ago

>and also allows tools to exist that can't be built for dynamically-typed languages As well as the ones you mention - would you include IDEs etc ? or is that more an issue of not doing the "smalltalk way" of editing running code?

time_management 18y ago
I'm talking about the compile-time type checker that ML and Haskell have. This is a very powerful tool that doesn't exist in dynamically-typed languages. It seems like a mere curiosity, because a lot of the super-cool things you can do with type-checking are impractical (e.g. the use of phantom type hackery to do bounds-checking on arrays). However, on large projects with multiple programmers, it also helps to keep interfaces stable and self-documenting. For example, let's say you change the output type of a function deep in the trunk-- instead of returning a 'a or throwing an exception, it returns a 'a option, e.g. a discriminated union between None or Some x, where x is a 'a, using the None value to represent failure, in lieu of the exception-- and want to find all the places where things break in the leaf code, so you can adapt them to the changes. What tool do you use: grep? Nope. You attempt to compile the tree, and all the code-breaks are caught and displayed by the compiler.