Re:Should programming languages support unit testing natively?
by nostrademons on Saturday November 07, 2009 @10:35PM
(#928754)
"Fighting the compiler" doesn't necessarily mean type errors. It could mean that you have to warp your design to fit the constraints of a language, often making much more extensive changes to your program than you would otherwise would've had to.
Though a lot of my complaints about Haskell's type system could be alleviated with a good integrated refactoring tool. If I had one-command operations to:
a.) Convert a plain function to a monadic one
b.) Change the signature and stacking order of a large stack of monadic transformers
c.) Add a new alternative to an algebraic data type, and track down and fix all functions that use it.
d.) Add a new parameter, at an arbitrary position, to a function.
e.) Change a straight return value to a Maybe.
f.) Add a new field to a record or tuple type.
Then I'd find Haskell's type system much less oppressive. What's the status of Leksah these days?
In Haskell, you do not fight the compiler either. With practice, you will find that the few type errors the compiler returns to you are legitimate: Wrong calling conventions, typos, API misuse, returning nonsense in a specific case and so on. I have, perhaps, some 5 errors per 100 lines of Haskell code I write that the compiler quacks on. It is equally bad moving dynamically typed programming idioms to Haskell as it is moving statically typed programming idioms into, say, Python.