4 ms·

Yes it is fascinating - the static versus dynamic rears its head in all sorts of places - sometimes not even programming related. Smarter people then me can pr

Yes it is fascinating - the static versus dynamic rears its head in all sorts of places - sometimes not even programming related. Smarter people then me can probably identify some underlying mathematical reason... I know the "typed lambda calculus" is the super set of the lambda calculus, but that's about it for me (or rather the "commonly known" lambda calc. is really a special case of the more general typed lambda calculus) - now if that translates into static typing being more mathematically pure/complete, I don't know (and even if it did - what does that mean in practice??). I think nice languages with decent type systems kind of make static typed languages look nice - so the aesthetic argument (which is what most people refer to when they bring up the debate) mostly goes away (eg haskell, scala to some extent - although it can get gnarly). I like using both - however from what little experience I have had I haven't enjoyed dynamic languages with optional type annotations (but it is limited experience). I am interested in Brendan Eich's suggestion for ECMA script 4 (!) to have typed interfaces for the edges of a system....

time_management 18y ago
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.

time_management 18y ago

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.