"Alberto G. Corona "
However, reusability of source code and maintainability has never been taken seriously by haskell programmers, simply because there are no industrial projects in Haskell with dozens of people with different skills that come and go.
Now that's a claim. In the sense that I don't do commercial haskell coding, but know what maintainability is, anyway: I've maintained everything from utterly atrocious to mindboggingly elegant java code for a living. I can tell you with 110% confidence that maintainability is about composibility, _on_every_level_: Not just on statement-level. Otherwise, I wouldn't have cussed that much. Curiously enough, as soon as the code didn't make you whince, it was easily maintainable. This is closely related to Linus' observation that good [imperative] code is data-structure centred, and Greenspun's Tenth Rule. With Haskell, there's finally a language that makes large-scale changes as easy as small-scale changes without having to resort to implement an interpreter for a functional language. As the position of changes tends to travel upwards in a bottom-up approach and small-scale changes are easy to pull off (you already understand what you need to do since otherwise you wouldn't have identified the need for a small-scale change and continued to add onion layers), caring about editability on function level just doesn't pay off. That's why I don't care whether or not I have to re-write a whole function to change it: If it's going to change, which isn't all that likely, I can cope with renaming it and write another say 160 characters directly below it. Adding a proper quickcheck property (if it didn't exist, yet, or the semantics changed) is usually more work: You don't only need to get the preposition right, but also the test case generator. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.