3 ms·

Static typing à la C,C++,Java,js,etc... is from my experience inferior to dynamic typing. On the other hand, the Haskell typing is superior in many ways to dyn

Static typing à la C,C++,Java,js,etc... is from my experience inferior to dynamic typing. On the other hand, the Haskell typing is superior in many ways to dynamic typing. Because you lose very few power of expression but you gain a lot of time in your workflow (and also security). Concrete example (I'll use js): function showField(data) { console.log(data.field1.filed2); } you relaunch your application, you click on three to four elements, then you enter your name and a password. You click on the button, and "BAM, filed2 doesn't exists". Correct the typo or add a test and replay the game of executing your new code. Static typing: showField : ConcreteData -> IO () showField data = putStrLn $ filed2 (field1 data) Try to compile, get the error: showField : filed2 doesn't exists, may be you mean "field2". correct your code. Now you're done. Here is another example: Dynamic typing: function showField(data) { if (data.field) { console.log("OK"); } else { console.log("Not OK")} } ... showField(myData); Try it using all manipulations to reach the test case, then: ERROR, couldn't find field for null. :-| replace by if (data && data.field). In static typing: showField data = if (field data) then putStrLn "OK" else putStrLn "Not OK" compile: could not match String with (Maybe String) at ... now: showField data | field data == Nothing = putStrLn "Not OK" | otherwise = putStrLn "OK" You fixed it, but you didn't had to lose your time searching the error. The BIG bonus is that you detect the error before you discover it at runtime. Imagine you didn't detected the error during your test (even with unit tests). This is why it is so easy to push this kind of error in production in a dynamic typed language. And I only scratched the surface. I program mostly in JS now, and I love even more when I am doing Haskell.

yiransheng 12y ago
Very well put, I am learning haskell at the moment, and beginning to appreciate the power of its type system in a way never which I never felt in Java, C etc. When you chain a series of functions/actions together, only to supply data for computation last, type signatures almost always ensures the correctness of the entire computation. This is true even the computation occurs at a high abstraction level. It's almost like magic, when dealing with the more difficult concepts (well for beginners) like monads. There has been a number of times when I wrote something but cannot make sure it does what I want, yet it compiles and a few tests reveals it indeed works like a charm. Whereas in dynamic languages, it'd be a nightmare to dig into the dirty details at runtime. I always have this problem in R, a series of supposedly elegantly linked operations fail for mistakes like forgetting to convert character values into factor type. To debug such errors, I always have to explicitly carry out middle steps and store intermediary results, until finally locating the problem. Another note, even in javaScript, sometimes there at patterns encourage the use of implicit types or interfaces(typeclass in haskell). The canonical example is jQuery, most of the times you can safely do: $(something).method1().method2(param).method3()... This is because any jQuery object inherits methods from $.fn, and most of these methods returns either the same jQuery object, or another jQuery object. In a sense, jQuery itself is a typeclass, anything looks like $(something) is a instance type.
lispm 12y ago
To find undefined slots or undefined functions, you don't need a type system. A competent compiler is sufficient.
- yogsototh 12y ago
  The type system enforce some kind of usage. myObject[ someFunction() ] = 1; No compiler in the world would be able to detect if myObject.field should exists or not. In a (good) type system oriented language, you have to declare that myObject is a Map, and therefore when you want to access "field" you know this access could be "Nothing". The type system alert you if you don't handle the "Nothing" value.

yiransheng 12y ago

Very well put, I am learning haskell at the moment, and beginning to appreciate the power of its type system in a way never which I never felt in Java, C etc. When you chain a series of functions/actions together, only to supply data for computation last, type signatures almost always ensures the correctness of the entire computation. This is true even the computation occurs at a high abstraction level. It's almost like magic, when dealing with the more difficult concepts (well for beginners) like monads. There has been a number of times when I wrote something but cannot make sure it does what I want, yet it compiles and a few tests reveals it indeed works like a charm. Whereas in dynamic languages, it'd be a nightmare to dig into the dirty details at runtime. I always have this problem in R, a series of supposedly elegantly linked operations fail for mistakes like forgetting to convert character values into factor type. To debug such errors, I always have to explicitly carry out middle steps and store intermediary results, until finally locating the problem. Another note, even in javaScript, sometimes there at patterns encourage the use of implicit types or interfaces(typeclass in haskell). The canonical example is jQuery, most of the times you can safely do: $(something).method1().method2(param).method3()... This is because any jQuery object inherits methods from $.fn, and most of these methods returns either the same jQuery object, or another jQuery object. In a sense, jQuery itself is a typeclass, anything looks like $(something) is a instance type.

lispm 12y ago

To find undefined slots or undefined functions, you don't need a type system. A competent compiler is sufficient.

yogsototh 12y ago
The type system enforce some kind of usage. myObject[ someFunction() ] = 1; No compiler in the world would be able to detect if myObject.field should exists or not. In a (good) type system oriented language, you have to declare that myObject is a Map, and therefore when you want to access "field" you know this access could be "Nothing". The type system alert you if you don't handle the "Nothing" value.