This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditional compilation approach.
Writing tests at more intermediary stages is not as much a matter of best practice, but I see know the appeal. At some point I started writing one-off functions to rerun the same code over and over in the REPL- that's when I realized it was time to start writing tests even if the API wasn't finalized. But full TDD is a matter of taste. There are people that like to have a really good idea of what they're getting into, and it seems like TDD works well for them. I myself have trouble. When I try to write tests first, I wind up paralyzed by making decisions without knowing the costs and benefits. That's where the REPL comes in handy for me- figuring out what shape I want my data to be, double checking edge cases faster than I could reference the documentation, and playing with new building blocks.
This is the biggest challenge for answering “why Lisp?” It’s different enough from the programming that most people are used to that it rises to the level of a radical novelty, with all the explanatory difficulties that entails.
In fact, it’s a defining characteristic of the radical novelty that it can only be understood experientially. And even then experience is merely necessary, but certainly not sufficient.
I mean, lots of languages have REPLs now- people get that they're really useful! This isn't secret knowledge, the pros and cons are on display. Macros are nice (though of course Ruby has them too), but I'm always surprised by how far people get with method call chaining (hell they have monads over in JS land now). The experience of writing lisp is very similar to that of writing Ruby, or even Javascript- really any dynamically typed language with good enough lambda support. It's by no means as strange as an array or concatenate language. It would surprise me very much if the reason you and I like lisp, or other people don't like lisp, was anything other than taste!
Interestingly enough the Lispiest non Lisp dev experience I've professionally had is writing java 8 using Eclipse on the JVM treating the unit test runner as a kind of C-x C-e. It's no wonder Clojure was such a good fit for the JVM.
I personally can't use anything without vim bindings. I have evil mode in Emacs, vimium while I'm in Firefox, vim bindings in Nyxt, and an aversion to using any program that isn't one of the above. This is not just hipsterism- on 10 occasions while writing this comment I've had to delete a kj or jk as I tried to exit edit mode. That doesn't really mean non-vim bindings are defective, if you catch my drift. No judgement here! But it's a possibility you might consider.
Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it.
You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the fly.
This kind of experience is pretty much limited to Smalltalk, Forth, and Common Lisp (with Erlang having a more limited ability to do live updates).
It's really nice to be able to redefine classes while you're playing around- but CL's handling of class redefinition just isn't up to snuff on a production server. It's just like doing live changes to your schema, only you see, rather more so. Compared to scp->shutdown->mv->start, if you can possibly tolerate <10s of downtime, or the many existing solutions for gradual rollout if you can't, it just doesn't make sense.
If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5.
I can't speak to Ruby or Erlang, but the Python REPL is much less than 0.999 because of the semantics of "import" making it very challenging to change code once it's been imported.
Lisp had interactive programming a decade before Smalltalk. The interactive PDP-1 Lisp is from 1963. BBN Lisp was based on it. Which then was taken over by Xerox PARC as Interlisp.
BBN Lisp / Interlisp already had a very sophisticated programming environment in 1970, including a built-in structure editor for Lisp.
For side-effect heavy code, a repl is not nearly as productive as good tests and a debugger.
(What is interesting is that people tend not to test or check manually their code's side effects, so a repl is the best option for almost all the debugging that people actually do.)
My dream is still to come up with some ergonomic way of blending the two. I want to have tests written, but swap out the thing they test live in the REPL. Or register new one-off tests from the REPL for things I don't think will be useful once things are set in stone. I've heard one of the several billion testing frameworks for common lisp does something like this, but I haven't checked it out yet.
You don't type directly in the REPL most of the time. Send lines and functions to it instead.
Though, I must ask, is it really that much better? I do keep functions around if I think I'll have a use for them again- the vast vast majority really are one-offs. Plus, most of my REPL usage is iterating on an expression. Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.
Yes, it is.
> Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.
You can do both.
I also work in a REPL. For me, design usually starts well before code. Then the REPL will take me towards defining behavior via understanding and exploring particulars around a solution or set of alternative solutions. Then as some final step, I will assert that it does what it should do, and guard against possible future changes violating some assumption.
Depends on the programming language, how much state they need to build up, and so on. And they're still slower than just running the actual live code anyway.
Tell the test runner to not catch errors and let them pass through up to the debugger. Have a test fail, get the debugger, go to the buggy line (without quitting the debugger), fix the bug, compile the function with a keystroke (yes, one function), come back to the debugger, restart not the full operation, but the function call, the debugger frame where the error happened, and see the test succeed.
You ran the test exactly once and fixed everything in the process, very quickly. This is exactly what we do everyday with the debugger, with trivial or complex code, with unit tests or regular code.
An example: https://www.youtube.com/watch?v=jBBS4FeY7XM not with unit tests, it's an example on how to restart a precise frame, how to avoid re-running everything.
1. write the basic test scaffolding
2. debug, stepping until I get to a point in the test that needs to change
3. modify the test code (and save, which hot-reloads)
4. move the execution point to before my change
5. GOTO 2.
There are some changes that can't be hot-reloaded, but I've been surprised and how flexible it is.