Russ Allbery writes:
> I also think this may well be a good place to apply one of the ideas of XP
> (Extreme Programming, a fairly flexible small-group software design
> methodology), namely to write test cases *first* in many cases before
> writing the code, and to seriously consider trying to write unit tests for
> pretty much every bit of code that you write.
Dan and I had been talking about this, and we're all of the same mind.
Part of the language design is to come up with language test cases,
and part of the module design is to come up with C-level module tests.
I've heard the act of coming up with test cases also helps one spot
corner cases and interface problems that would otherwise have only
come up once large amounts of code had been written to the old design.
Nothing can prevent us overlooking something, of course, but this work
would have to be done anyway (sorry, *should* be done anyway :-) and
has the potential to save us lots of trouble.
In short, I concur 110% with you.
Test cases before code is not just part of XP, though. Many people
are advocating it.
After brief thought, I conclude rest of XP doesn't apply to perl6.
Lazy design is only relevant when you've got evolving customer
demands. That model scares the crap out of me given the variety and,
uh, novelty of some of the perl6 RFCs. I'm all for settling customer
demands *before* beginning on this (something I think we can do,
because in a large sense we are the customers). The final part of XP
was programming in pairs, and I really don't think that's going to be
possible :-)
Nat
