G'day all. Quoting Graham Klyne :

(2) I find that I spend a far greater portion of my time *thinking* about what I'm trying to do than actually coding it. There used to be an adage in the software industry that programmer productivity in lines-of-code per day was independent of programming language: with Haskell, I suspect that old rule breaks down, because it seems that actually coding has become a relatively small part of the overall exercise.

In theory, that's true of other languages too. Programmers are *supposed* to spend more time doing non-coding than coding (where I don't, for example, count writing unit tests as "coding"). I suspect that this is actually an artifact of your level of experience with Haskell. I know that I used to spend more time thinking than coding. When you get familiar enough, you get to the stage where you can think on your feet.

(4) I have noticed that it's often very easy to write some inefficient code (sometimes *very* inefficient) to do some task in Haskell, and then to optimize it.

This, I believe, is one of the most unappreciated (by non-declarative programmers, anyway) aspects of declarative programming. It's easy to write could-be-slow code that works first time, once you've fixed all the bugs caught by the compiler. Then, it's straightforward to swap out implementations and replace them with more efficient ones as the need arises. This is possible to do in non-declarative languages. It's even encouraged in "agile" OO methodologies, like XP. However, it's so much less painful in a declarative language, because you're far less tempted to introduce hidden dependencies to begin with. In fact, I find that my "working but slow" code has almost no weird dependencies. I find myself having to _introduce_ them during the "get it faster" phrase. From an engineering point of view, this is almost exactly the right thing, because that way you (in theory) end up with as few dependencies as possible.

(6) I have found that Haskell seems to a particularly effective platform for pursuing some ideas of extreme programming,

There you go. :-) There is only one problem I've found with test-driven development in Haskell. In C++, it's possible to break the "module" abstraction (yes, I know, C++ doesn't have modules; it has classes, which are really instantiable modules) by using "friend". In Haskell, I find myself occasionally having to expose parts of a module which I would prefer not to, in order for the unit tests suite to do their job effectively. I wonder if there might be a way to fix this, say, by allowing modules to selectively expose parts of their interface depending on who wants to use it. Cheers, Andrew Bromage

G'day all. Quoting Derek Elkins :

The "nicer" way*, though it could use less typing and "extraneous" files, is simply use multiple modules.

Yes, this was my solution, too. Nested modules might make this even nicer. Of course, Haskell's module system could do with a redesign, but that's another topic. :-) Cheers, Andrew Bromage

On 2004-01-01 at 21:07EST ajb@spamcop.net wrote:

There is only one problem I've found with test-driven development in Haskell. In C++, it's possible to break the "module" abstraction (yes, I know, C++ doesn't have modules; it has classes, which are really instantiable modules) by using "friend". In Haskell, I find myself occasionally having to expose parts of a module which I would prefer not to, in order for the unit tests suite to do their job effectively.

I wonder if there might be a way to fix this, say, by allowing modules to selectively expose parts of their interface depending on who wants to use it.

One of my unexplored ideas is to make tests part of the code of a module (probably best done with some sort of typed include mechanism for test data), linked in some way with the type of an entity. So one might write something like f :: Integer -> Integer |? f 0 == 1 && f 3 == 6 The compiler would then (optionally?) run the tests as part of the compilation. This would bind the tests more tightly to the programme than is now possible. As I say, I haven't explored this, so perhaps some of those agile minds out there could run with it? -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

At 21:07 01/01/04 -0500, ajb@spamcop.net wrote:

In Haskell, I find myself occasionally having to expose parts of a module which I would prefer not to, in order for the unit tests suite to do their job effectively.

Yes, I've found that too. But I also wonder if this is a sign that the XP approach to test-led development isn't being followed faithfully. Theoretically (as I understand XP), the tests *are* the specification. And things that aren't exposed can't be part of the specification, can they? In practice, I think that there's a slight tension here: tests may embody the specification, but they also embody some knowledge of the way the code works, and (I occasionally find) some may be created to provide a finer granularity of information about how the code is *mis*functioning. I'm finding my development strategy is evolving to make more use of separate "spike" modules to test code fragments, so there's less need for this kind of white box influence in the test code. Which leads to a question: I've been thinking that the "white box" tests may be better served by test expressions coded *within* the module concerned. In many cases, I create these, then en-comment them when the code is working. I would expect that when using GHC to compile a stand-alone Haskell program, any expressions that are not referenced are not included in the final object program, so leaving these test cases uncommented would be harmless: is this so? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

G'day all. Quoting Duncan Coutts :

On a side note, I've found QuickCheck to be great for these kinds of unit tests. As an example, I was able to turn someone else's code for a trie data structure into a multi-trie (like a bag is to a set) without fully understanding the code and still be fairly confident that the code was correct!

I agree that QuickCheck is great for this kind of task, but I still find myself exporting unnecessary functions. For example, suppose you are writing a balanced binary search tree-based FiniteMap data structure, and want to test it with QuickCheck. As well as testing the interface, you need to test at least three internal invariants after each operation: - that the tree is balanced with respect to the balance condition, - that the meta-data used to maintain the balance condition is correct, and - that the tree is a binary search tree (i.e. that the keys are in sorted order if you do an inorder traversal). For this simple example, one extra exported function should do the trick: structuralInvariantFM :: (Ord k) => FiniteMap k v -> Bool However, a more complex data structure with multiple invariants would require even more exported functions, because it would become more important to know which invariant was broken. Cheers, Andrew Bromage

G'day all. Quoting Graham Klyne :

But I also wonder if this is a sign that the XP approach to test-led development isn't being followed faithfully. Theoretically (as I understand XP), the tests *are* the specification. And things that aren't exposed can't be part of the specification, can they?

I don't understand XP this way. The tests are, at best, part of the specification of a module or component. However, the specification of the system as a whole is partially embodied in use cases and, ultimately, the on-site customer.

In practice, I think that there's a slight tension here: tests may embody the specification, but they also embody some knowledge of the way the code works, and (I occasionally find) some may be created to provide a finer granularity of information about how the code is *mis*functioning.

Don't you sometimes wish you had a Haskell coverage analysis tool? :-)

Which leads to a question: I've been thinking that the "white box" tests may be better served by test expressions coded *within* the module concerned.

That's not a bad idea, but there is a problem with this, IMO. When programs get big, the cost of compiling becomes very significant. Assume for a moment that the size of a program grows linearly over its lifetime, that the cost of compiling a program is at least linear in the size of the source code, that recompilations happen regularly and that hardware is not upgraded. (The last assumption is true in many real-world cases; often, build machines are kept "frozen" to minimise the risk of OS/compiler/etc changes introducing changes in the produced software.) A little thought shows that the cost of compiling this program over its lifetime is quadratic in its final size. It's a subtle cost because it's amortised over the lifetime of the software, but reducing the cost of a single compilation pass really does pay off. It follows that introducing code which is immediately thrown away in most cases is probably the wrong thing for many software development tasks. Cheers, Andrew Bromage