My Kind of REPL | Hacker News Reader

My Kind of REPL

ianthehenry.com

87 pointsianthehenry12 comments

Hey: MANY, MANY, MANY THANKS!!!

I use REPLs in ways that are similar to yours, but 1) you have several tricks that are new to me, and 2) you've been able to put into words many ideas that I haven't!

My way is here,

http://anggtwu.net/eepitch.html

and I'm certainly going to cite you in my presentation in the next EmacsConf! =)

While we're at this: https://github.com/darius/halp -- I came up with it 16 years ago and still use it.

Example of use: the ## comments and #. outputs in https://github.com/darius/sturm/blob/master/tictactoe.py#L20...

(It'll need a Python 3 update if you're more up with the times than me.)

I mean that you can write programs that edit their own source code.

Like smalltalk.

or a computer virus :)

This is cool, I'm going to start trying it. I noticed elixir's doctests a few weeks ago and it seems like a partially related idea. It's not quite the same thing but I could see a formalization like them being the "other half" of the blog post's approach for a team.

This is great, especially the more graphic tests, and timely as I'm enjoying learning Janet.

This works for regression tests, and documentation, but not so much for something like TDD, where the test is more like (or should be) a specification for the program you are about to write.

Dude you are living in the matrix - in the best way possible. I love your post!

Is this not a form of mutation testing? With the added idea of treating anything you write to sanity-check the output as a test?

Mutation testing is where you make changes to your code's logic as a way to ensure that you have good test coverage for that bit of logic. Mutation testing is helpful with any kind of tests -- assertions, snapshots, whatever -- as a way to check that your tests are actually able to catch interesting bugs, but the idea is orthogonal to this workflow.

Have you found any added benefit in your approach using mutation testing?

Really interesting stuff I'm going to play with personally and in school I think. Thank you.

Hmm, I like mutation testing, and have found it very useful, but I don't know if it feels any different with this technique as it does with traditional assertion tests. Perhaps one difference is that, when you find a hole in your test coverage, it's easier to fill it in when tests are easier to write.

One thing that is a little different is that this type of testing makes it easier to write "counterfactual" tests, which are sort of similar: you observe the behavior of a function with input A, and then you make an interesting tweak to the input to get input B, and you can see how the output changes (you can even print the diff between the two outputs in your test). This is useful for ensuring that a test is actually testing exactly the thing that you want it to test -- if you have a test that "X fails validation when Y is Z," you can ensure that the only difference between a failing and a passing X is the value of Y, whereas if you only test that "X with Y=Z fails," you won't be totally confident that the failure is due to Y or due to some other newly introduced E. I think that the ability to print diffs between inputs and outputs makes this kind of REPL test a lot easier to read and write in this case.

Has anyone ported this workflow to Common Lisp yet?

Reply on news.ycombinator.com