News for hackers. Stuff that matters.
Re:REPL Driven Design by danenania on Thursday May 28, 2020 @01:38PM (#23340101)
The trouble is that for the repl “test” to be reproducible, you don’t just need to store the relevant commands and result, but the full state/history of the repl. Since the point of a repl is to explore and experiment, it seems like your tests would end up with a lot of noise in them... but perhaps there are ways to get around this? I agree the concept of quickly converting repl sessions to tests is very compelling.
Re:REPL Driven Design by gmfawcett on Thursday May 28, 2020 @05:18PM (#23342782)
A common approach would be that the code you're testing / playing with is defined in a file somewhere, and reloading that file resets the REPL state sufficiently to iterate on your tests. e.g. if it does rely on external state, the reload will re-initialize that state. Morally similar to the setup instructions in a unit test.
Re:REPL Driven Design by samatman on Thursday May 28, 2020 @02:42PM (#23340815)
yes, there's a lot to it!

I store the complete repl history, complete with results and session metadata, in a database.

Pruning a session's history down to only what's needed is a manual process, true, and laying the groundwork to provide that feature has been the main yak shave.

Re:REPL Driven Design by bch on Thursday May 28, 2020 @04:38PM (#23342242)
> ...manual process, true

Before I get to my real comment, I guess a fair criticism of it would be “Well, where in the [development process] hierarchy do you actually want to live?”, which I guess is a longer discussion, but as a developer, you can’t become battle-hardened without going to battle. So we can nod to Carl Sagan[0] and say “I made this from scratch”, and know there’s value in that. At least occasionally running your REPLs by hand and taking the actual trip, instead of just wanting the destination. It may not be tenable as a full-time production development strategy, but that doesn’t mean it’s worthless.

[0] https://youtu.be/7s664NsLeFM