3 ms·

I do repl driven development just fine with ipython and autoreload setup. What features do you feel are lacking?

jonahbenton 6y ago
Yes, when I work in python, I do that too. It certainly works ok. The place I would start from a critique perspective is around lifecycle. Python has encouraged carelessness and overwork at module load and init time, and there aren't common protocols (that I have seen) that involve standing up a graph of objects across an application after a single module reload. So when you reload a single module and the names in the module now point to different data and code elements, all the downstream dependencies on those names have to change as well, and Python doesn't have patterns for organizing and managing at that level. This also impacts runtime introspection, which is a key benefit of a repl oriented language. One implication is that there is not at all a pattern of "repling into" a running python application to poke around and see what is going on. To most python programmers this is a foreign concept. Related others involve code style, and implicit vs explicit ways of referring to and moving data around, which also impacts runtime whole system introspection. Python has all the pieces to have a very nice repl-first programming model, but lacks patterns for key parts of that- explicitly standing up the graph of live objects, and using a repl to interact with a live system with live objects. Hope that makes sense.
vindarel 6y ago
Here's an overview: https://lisp-journey.gitlab.io/pythonvslisp/ https://lisp-journey.gitlab.io/pythonvslisp/ In short, the Python process has to restart to take changes in, and you loose your objects in the REPL. The Lisp process doesn't and is built to (lazily) update your objects to reflect structure changes (such as if you deleted a class slot). I particularly like the Lisp way for unit tests or the web.

Yes, when I work in python, I do that too. It certainly works ok. The place I would start from a critique perspective is around lifecycle. Python has encouraged carelessness and overwork at module load and init time, and there aren't common protocols (that I have seen) that involve standing up a graph of objects across an application after a single module reload. So when you reload a single module and the names in the module now point to different data and code elements, all the downstream dependencies on those names have to change as well, and Python doesn't have patterns for organizing and managing at that level. This also impacts runtime introspection, which is a key benefit of a repl oriented language. One implication is that there is not at all a pattern of "repling into" a running python application to poke around and see what is going on. To most python programmers this is a foreign concept. Related others involve code style, and implicit vs explicit ways of referring to and moving data around, which also impacts runtime whole system introspection. Python has all the pieces to have a very nice repl-first programming model, but lacks patterns for key parts of that- explicitly standing up the graph of live objects, and using a repl to interact with a live system with live objects. Hope that makes sense.

vindarel 6y ago

Here's an overview: https://lisp-journey.gitlab.io/pythonvslisp/ https://lisp-journey.gitlab.io/pythonvslisp/ In short, the Python process has to restart to take changes in, and you loose your objects in the REPL. The Lisp process doesn't and is built to (lazily) update your objects to reflect structure changes (such as if you deleted a class slot). I particularly like the Lisp way for unit tests or the web.