Hacker News Reader

Comment by TheOtherHobbes | Hacker News Reader

LISP continues to be a very interesting language.

But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state.

LISP would be a more practical language if it included a trivial option to make that possible.

View on HN

> LISP would be a more practical language if it included a trivial option to make that possible.

If you're using SLIME: M-x restart-inferior-lisp

In that case, can't you just restart the REPL? Or give the program a main function that you run?

Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation?

E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc.

That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak from experience.

And with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation?

Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.

My point was, having an actual example of data in front of you, instead of only definition of the structure/schema/interface/type of the data could push people more towards relying on things specific to that example. Especially in dynamically typed languages, but also for things like trying to take the first element of a list that might be empty (in languages where that doesn't return an `Option`), etc.

And I wonder whether someone observed that in practice.

I see what you were getting at now

I've not personally observed that, fwiw.

My attitude with tests is not to write individual tests when I can write property-based tests. The payoff from the latter is considerable. Let the computer do the work of generating and running tests; its time is worth a whole lot less than mine.

For individual tests, say for coverage, these should also be generated automatically if possible, say by looking for inputs that kill mutants. I've backburned a Common Lisp system for doing this, generating mutants from Common Lisp source forms and automatically searching for and minimizing inputs that kill new mutants. Maybe one day I'll finish this and put it out there for general use.

Never programmed in common lisp but I imagine it is trivial to enumerate all refs and unbind them.

I just create new / changed functions next to the others and eval the selected region, then clean up. When I think i'm done, I'll restart the repl and try if it all is fine or if I depended on something in the state. That doesn't often happen anymore. I use the repl to try out things I just written in files. I can't say I remember a moment when state was a/the problem.

M-x slime-restart-inferior-lisp

works fine.

I wish there was some, even theoretical, effort to fix this. It's a crossdomain issue, even react in a way deals with that.

There's a practical way to do that right now in CL; in most implementations it's cl-user:quit, but UIOP defines a portable wrapper for it

I usually add one or more reset functions, and then I can customize whatever state I want to return to.

Reply on news.ycombinator.com