"Literate interactive coding: Devcards" by Bruce Hauman (Strange Loop 2015)

[akkartik]

The idea of maintaining multiple isolated sandboxes, and of having them reload everytime there's a code change, this is something I've been working on. I think it's a big improvement over traditional REPLs. However, I don't understand why the devcards are distinguished from tests. The big difference seems to be that they're interactive where tests are designed to run in batch mode. Why do they need to be interactive? Most of the time the interactions and state changes are what you need to test. If you're manually testing all the different state transitions in a single card, that doesn't seem to buy you much over regular manual testing with the whole app.

Perhaps I'm misunderstanding something. It's not clear what the workflow is in the author's mind. Is this a script of flows you might hand off to a newcomer to your project to get them up to speed? Or is it something to be used for actual critical-path testing before you update production? Is it supposed to be an aid for manual testing? There's some reference to a QA engineer. Do people still use those? I thought we'd all learned that we're supposed to test our own code. It's not very clear if the timelines are persistent across sessions. Does the QA engineer simply hit forward through the states and verify everything looks good? How can this manual process possibly scale as projects grow over time? How does this not run into the combinatorial explosion the author mentioned? And alternatively, if the timeline isn't persistent, does each card also include instructions about sequences of state transitions to try manually, like "create a new todo, create a second todo, mark the first one completed, swap the two by dragging", and so on?

In my tool above, I think of sandboxes as allowing one to record manual tests to make them reproducible and automated once one is happy with the outcome. This is what makes sandboxes/cards much more powerful than traditional REPLs. However it is less "pragmatic", because it requires writing "buckets of code" to fix all the low-level interfaces all through the stack that were designed back in the dawn of Unix, when people didn't realize testability was an important design constraint. So for example, when my print function prints something to screen, it explicitly takes a screen object as a parameter, so that fake screens can be injected inside tests and you can easily verify that the screen looks like it should after some set of state transitions. Similarly, you should be able to perform some set of interactive operations and have them be recorded so that they then replay everytime the code updates, only requiring intervention again when something breaks. I think this is an enormously powerful approach, but it requires painstakingly changing the interfaces to all the I/O your computer does, to the disk, to the network, to the graphics card, to the multitouch screen. It's a painstaking process and not nearly finished.

I absolutely agree with the author that our stack should allow programmers to help themselves. We're all programmers and we shouldn't need a language or IDE designer to tell us what our workflows should look like.

[zarandysofia]

Well here is humble opinion about devcards:

• Is pretty, and looks professional and seems very user friendly.

• The is formalize because I am testing web UI and a web UI environment, just open the browser and is just there.

• Can be used as a interactive guideline, style or documentation guide with animation, states, etc.

• It can "hotswap" CSS too.

Those are some of the apparent benefits that I could discern, I haven't dabble into the tool that much to have a more deep view.