5 ms·

This is a really nice example: toy enough that it's easy to understand and you don't get bogged down explaining the problem, but meaty enough that it shows some

This is a really nice example: toy enough that it's easy to understand and you don't get bogged down explaining the problem, but meaty enough that it shows some of the things you have to think about in real-world projects. I hope lots of people see this. I have a mental hangup about literate programming that is like how I feel about practicing hard musical passages with a metronome: it works so well at getting me over the hump into competence that I fear overusing it and wearing out the mental effect. Do magic spells get used up over time?

Jtsummers 4y ago
There's a difference between LP (or TDD or ...) working to help you improve your programming and get over hurdles versus a metronome. A metronome is a practice aid, when you perform you will generally not use it (though in an ensemble, someone or some group is often playing the part of the metronome in establishing the beat). With LP and other techniques they are not practice aids (or not just practice aids) but performance approaches. Now, you may not use them all the time, you may not find them generally applicable, but that doesn't mean that you should skip it if it gets the job done. In this case, the more you use it the more natural it will become for you. That means you'll be able to use it with greater fluidity and move in and out of the mode of literate programming (versus more traditional programming styles). Maybe you think, "I know what to write in code, let me just blurt it out." You do, you get it done. Then you reorganize and put it into a literate style because you like that presentation better, or you've reached a point where you need to clarify your thoughts before moving on ("I'm not sure what to do next, or is this really what I wanted? Let's examine it.").
- FrenchyJiby 4y ago
  Hey, OP here. I'm a heavy proponent of "we play (at work/in prod) like we practice (in personal projects)", so that idea of TDD/LP as "peformance approach" is interesting. Thanks for that. And on the tension between initially "after the fact" rationalization vs as-you-go LP, I tried to keep myself honest: The git repo has tags for each feature's initial completion[1]. One can indeed compare how the features were initially written vs how they ended up after the (heavy) editing passes. As you'll see, it's more than just more explicit text, there's a few bugs/warts that I cleaned up. Definitely felt this tension of "I can make it better" vs "I should keep the narrative intact". [1]: https://github.com/OverkillGuy/literate-wordle/tags https://github.com/OverkillGuy/literate-wordle/tags

Jtsummers 4y ago

There's a difference between LP (or TDD or ...) working to help you improve your programming and get over hurdles versus a metronome. A metronome is a practice aid, when you perform you will generally not use it (though in an ensemble, someone or some group is often playing the part of the metronome in establishing the beat). With LP and other techniques they are not practice aids (or not just practice aids) but performance approaches. Now, you may not use them all the time, you may not find them generally applicable, but that doesn't mean that you should skip it if it gets the job done. In this case, the more you use it the more natural it will become for you. That means you'll be able to use it with greater fluidity and move in and out of the mode of literate programming (versus more traditional programming styles). Maybe you think, "I know what to write in code, let me just blurt it out." You do, you get it done. Then you reorganize and put it into a literate style because you like that presentation better, or you've reached a point where you need to clarify your thoughts before moving on ("I'm not sure what to do next, or is this really what I wanted? Let's examine it.").

FrenchyJiby 4y ago
Hey, OP here. I'm a heavy proponent of "we play (at work/in prod) like we practice (in personal projects)", so that idea of TDD/LP as "peformance approach" is interesting. Thanks for that. And on the tension between initially "after the fact" rationalization vs as-you-go LP, I tried to keep myself honest: The git repo has tags for each feature's initial completion[1]. One can indeed compare how the features were initially written vs how they ended up after the (heavy) editing passes. As you'll see, it's more than just more explicit text, there's a few bugs/warts that I cleaned up. Definitely felt this tension of "I can make it better" vs "I should keep the narrative intact". [1]: https://github.com/OverkillGuy/literate-wordle/tags https://github.com/OverkillGuy/literate-wordle/tags