Hacker News Reader

Comment by sillysaurusx | Hacker News Reader

Even today it amazes me that python devs don’t live in the repl the same way that lispers do. The interactive approach is underrated. Especially in the era of test-first development, which I think is a fad long term. (That’s not to say no tests, just not tests first.)

View on HN

I'm trying to convince myself Jupyter isn't a form of living in the REPL expressed through tabbed state in a linear order, of python execution. I think it is, but I suspect it fails some boundary condition of significance. That said, when I did it, I didn't find it too hard to introspect on my code, in what it told me.

I do think there is a meta going on around LISP repl and it's internal introspection which other REPL don't quite provide. You can come to almost the same place in output, but not at interaction with the run state of the 'machine' itself. (somebody else in the thread made the point its mostly there except handling exceptions in the stack)

Jupyter Notebooks are absolutely a form of REPL, the type pioneered by MACSYMA, cloned by Mathematica, and significantly enhanced by Symbolics Dynamic Windows and Common Lisp Interface Manager (which is basically just DW but for any Common Lisp with CLOS).

Try redefining something from a library that is used from a lot of different places. It's easy to change one copy of a definition in Python, but the only way to get all of them is to write your new definition to disk and restart Jupyter.

You simply can't in Python, not only due to unwind-first exception handling, but also because one module is represented by multiple objects in memory: one object for each other module that imports it. That makes it impossible to redefine anything (you'll always miss some of the copies of whatever you tried to redefine). Importing things from modules piecemeal makes it even harder to find them.

The importlib.reload function only applies to one copy of a module. A comprehensive solution would be incredibly complicated and would still have limitations.

In contrast, a Lisp package exists in exactly one place. No matter where you get it from, two references to the same package are always eq (having "is" equality in Python terms). Therefore, if you redefine something in a package, you redefine it for everything that uses the package. It also helps that imports in Lisp apply to the symbols, not the things they refer to. So importing something doesn't hide a copy of it anywhere. The most naive redefinition technique will always work, with no edge cases.

The inability for class redefinition to affect already existing objects in Python is another severe limitation. Even if you could redefine anything reliably in Python, you'd still have this problem.

I think you can argue that the pervasive use of notebooks is close enough for learning at least, but it's not as good for real development. The edit-and-continue features in Visual Studio for C# (and similar feature in Java) is the closest non-lisp thing we have these days. The languages aren't made for it like lisp are though, you have to do full restarts all the time.

I still wish there was an environment more like Smalltalk for Python.

>The edit-and-continue features in Visual Studio for C# (and similar feature in Java) is the closest non-lisp thing we have these days.

Some years ago I was playing around with Franz Lisp, and noticed an interesting debugging feature in it. A few days later, I was using a then-new version of Visual Studio for writing either C (not C++) or VB, and noticed the same cool feature in it, which MS was calling Edit and Continue.

IIRC, it was introduced in that VS version, but not sure, since I was not a regular Visual Studio user.

On Microsoft ecosystem, it was initially introduced in VB.

Interesting.

Shameless plug: I have always been fascinated by edit-and-continue and I build a JavaScript IDE centered around it.

https://leporello.tech/

Python doesn't work well for repl development. You cannot set the current module in Python as you can do in Lisp. So you're restricted to make changes to the current module. Also, debugging in the repl is not as powerful in Python.

Sure it does. Just paste the defs into the repl.

You can also use `from importlib import reload` and then have an expression like reload(foo).bar() to constantly reload your foo library.

But this means you have to litter your application with support for it, doesn't it? In Common Lisp, I can stop at a breakpoint, paste in a new definition of any function in the application, and then resume and it will use the new definition everywhere rather than the one that existed when the breakpoint was triggered: https://two-wrongs.com/debugging-common-lisp-in-slime.html

*and not only paste, but write, in the source file, the new definition, re-compile it (C-c C-c), and resume execution from a stackframe before this call. (a clarification for folks who would think we must paste in the REPL)

That's useful not only for breakpoints but also for errors. We can fix an error without re-running everything from zero. https://www.youtube.com/watch?v=jBBS4FeY7XM

Reload only reloads one copy of the module. If there are other modules that imported the same module, your new definition will not be seen by them unless you find all the copies of foo in memory and reload them also. Since there's no reliable way to do that, you're more likely to just restart Python all the time.

Not accurate as worded. Python caches module imports in `sys.modules`, so all imports get the same one. A `reload()` will reuse the same dict object that was being used as the module's namespace, so everything with a reference to the module object will see the same namespace and get the updates.

Check out lpy-mode

What? Yes you can. I do it all the time.

    import code; code.interact(local=vars(foo))

where `foo` is the module object you want to set as current. This launches a subREPL in that module's namespace. (EOF kills the subREPL and returns to main.)

Python has a debugger in the standard library that can also do post-mortem inspections.

I do a lot of python halted in the debugger, which is a close enough approximation.

I do! I have been using Common Lisp since 1982, love it. But when I code in Python, Emacs with the old Python support gives you a really nice editing and REPL environment.

test driven development has been around since the late 90s and was popularised in eXtreme Programming circles, are you sure it's a fad? I find it the most efficient way to write code and keep it running in the long term personally.

Reply on news.ycombinator.com