Toys are an idea I'm taking from lib2geom, where Nathan instituted them as the preferred development approach and they have contributed a lot to lib2geom's success: essentially, a toy is a very simple program which demonstrates a specific concept and allows interactive experimentation. They're also a good supplement for unit tests, when dealing with large-scale properties of code that are difficult to write unit tests for, or cases where the desired behavior isn't even clear yet.
One of the temptations with toys is to treat them as a first draft of the main code itself: since lib2geom is a library, it's been less of a temptation there, but I imagine it's going to require more effort to resist with Moing. So I'd like to lay out several ground rules for toys:
- Toys must be focused: they should cover a narrow vertical slice of functionality relative to the intended functionality of the main code
- Toys get their own section of the source tree
- No code from a toy can go into the main portion of the source tree without being rewritten
- However, toys are allowed to use code from the main program, and toys can be refactored within the toys section of the codebase to create a "toy framework"
2 comments:
Actually they have been first drafts for some 2geom code. Often times it's convenient to write a function right in the toy code, and once it's proper, move it out to the main. For example, I'll probably get my intersection toy working with arbitrary paths, then base the sanitation off that stuff.
Just because it's toy code doesn't mean it's not good code.
Particularly due to the compositionality of good haskell, I think it will be very difficult to not use code from toys.
As such, I disagree with #3. I think it's meant well though. Rough toys should be rewritten. However, the isolated development environments that toys offer is also good for perfecting the subject matter. <insert pearl/clam metaphor here>
#4 was totally me in 2geom :P Anyway, I hope the 'code use' from main will be module based - no code copying just for the purpose of principles, I say!
Indeed, if toys use code from main it ought to be module-based.
Regarding #3, I usually find that retyping code (rather than simply lifting and moving it across) often gives it that extra polish because I have to think about all the code all over again. At the very least I tend to get better identifier names out of it.
I'm not going to loose much sleep if we don't always live up to that ideal, but I do want that ideal to be there.
Post a Comment