4 ms·
I just don't think you've tried or been exposed to responsible REPL prototyping and development. Like sure, you could have all sorts of issues if you use REPL i
by _coveredInBees 6y ago
I just don't think you've tried or been exposed to responsible REPL prototyping and development. Like sure, you could have all sorts of issues if you use REPL irresponsibly and pollute your state with undocumented code and side effects. But if you use it responsibly, it can be really fast and efficient when prototyping things... Even complex subsystems in a larger codebase. I've prototyped entire reimplementations of SOTA object-detection DNN algorithms in Pytorch with no issues and have been far more productive because I can develop functionality in small chunks while intimately understanding the problem at hand and associated data and then immediately graduate it to a working script/module/package as I go along.
For more complex things, I can even have a stub for a function I am developing and breakpoint into it and then I prototype the functionality in the REPL and that is wayyy faster and less bug prone than trying to go at it blindly in your IDE without being able to experiment and verify your code as you develop it.
- jampekka 6y agoI probably haven't. But I have seen quite a bit of irresponsible REPL development. What I don't see is the benefit of the REPL. I effectively use my editor and the shell as a "REPL", but instead prefer to have the code in a program structure all the time. This means I don't have to have extra discipline for not accidentally polluting the state. Plus I can use version control, which means I can quite easily try out quite deep changes and still revert back to any state I had before. This is difficult with REPL. And with this workflow I don't have to do any extra "graduating" step; the code usually cleans up during the process. A big additional benefit is that I can use the shell. I can e.g. pipe stuff from other programs, and I make a CLI for the program on the fly. The main problem perhaps is when there are some longer computations, as there often are in analyses. For these I prefer memoization to the disk. The usual way to do this across REPL-sessions is to write ad-hoc temporary result files. This gets hairy really fast when you have to update these when the codepath before the dumps change. I don't see much benefits of REPL over my workflow. Maybe some completions are nicer in REPL and you may get a bit nicer formatted output, but these are quite trivial. Perhaps people who are not accustomed to shell think that REPL is the only way to "rapidly iterate"?
- kruxigt 6y agoGood comment. I personally use the REPL exclusively but I can totally see how your workflow can be benefitial in some ways.