mt <mtvo@info.fundp.ac.be> writes:
Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written.
Type inferencing gives you 'compile time dynamic typing', so you don't have to think too much in advance. Representing a problem domain with types is roughly equivalent to using objects for the same purpose.
The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.
Haskell has lists of mixed type, see http://homepages.cwi.nl/~ralf/HList/ I think it's more convenient to represent everything as algrebraic datatypes. ADTs are sort of 'semantic lego' in that they represent the shape of the data. For example, the Tree datatype in http://www.haskell.org/hawiki/HaskellDemo : data Tree a = Nil | Node (Tree a) a (Tree a) says that a tree value can be either Nil or a Node that holds two tree values and something else, like Int, String, Double, or whatever you choose. How do lists of mixed types affect macros? Static typing in Haskell doesn't have that many downsides. A type system and checker is a simplified proof assistant implementation. You state certain properties about your program and the system checks for you. You can use the type system heavily, or skip most of the type checking. When I'm writing new code, my approach depends on my knowledge of the problem. Sometimes I ignore the types and just get the code working, and sometimes I write down the type signatures first and figure out the code from there.
From my viewpoint, type systems are one tool in the toolbox, no silver bullet, but at least a multitool :-) -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same.