Here’s an example. Assume that you have to write a simple text calculator that allows definitions of functions, storing variables, has reasonable number of builtins and provides meaningful error messages. Furthermore you have to implement it in c.

So you are probably thinking flex & bison (or lex & yacc if you prefer). Of course this is the best option given current tools. The only excuse to do it by hand is to learn how algorithms in those tools actually work.

But the flex and bison sources are meta-data for the resulting c program and this meta-data is very useful as it allows to get the work done. So it is not the point of meta-data itself. It is the question ‘will providing meta-data give me any benefit?’ that should be answered. If the answer is ‘yes’ then provide meta-data. If the answers is ‘no’ then why bother with doing something that won’t give any benefit?

That’s an interesting point about tests forcing you into structural rigidity. It would be hard to know, since it’s a behavioral issue. In theory, you should continually refactor your tests as you refactor your code. But I imagine you’re right: the more tests you have, the less willing you’re going to be to make a change that makes you revise your tests.

The strongest criticism I’ve seen of unit tests is that they they cannot catch three out of four bugs. They’re valuable for the one in four bugs they can catch, but QA has got to be a lot more than unit testing.

In the past I’ve used Ruby, TCL, PHP and Javascript and found repeatedly that the lack of type safety let otherwise obvious bugs go undiscovered. Some of these statically typed FP languages are somewhere in the middle I think. The type inference lets the code feel more dynamic.

Perhaps the issue was I had never even heard of TDD at that point. However, don’t tests cause the same kinds of structural rigidity that you are trying to avoid by using a dynamic language?