Hacker News Reader

Comment by Zak | Hacker News Reader

> I can't really do it in Python and it makes me sad.

That really bugs me with a great many popular languages. There's a REPL, but the libraries and tooling don't really embrace it.

View on HN

The only tools I've found with decent support for Python and other languages are all emacs based. Same goes for the Clojure and CL ones, actually. It's no surprise, I suppose, because this style of programming is so natural to an emacs user.

But it's difficult with Python as soon as you try to do anything beyond a single module. CL and Clojure have proper packages and namespaces so it works fine. But in Python you're limited to working on the context of a single module. If you modify a module that was imported then you have to restart the REPL because you can't reload modules. It just doesn't work.

In CL I would just load the entire system then eval whatever part I want to. From that point I would never not have the current version of the system completely loaded into the running image. Much the same with emacs itself. It is a running image of your emacs lisp system and you can just modify it and eval as-you-go. Does any other language even come close to this?

>Does any other language even come close to this?

Smalltalk

Interesting. But one of the points of Clojure is to get away from the object-oriented way so I'm not sure that I'd like Smalltalk.

You have to try it to really understand what OO actually is. Its not the OO you might be familiar with..

Yeah that is why it supports a subset of CLOS.

Erlang and elixir.

If I understand it correctly, Smalltalk is really nothing like Java and the mainstream OOP that Clojure is a reaction to.

Smalltalk is dynamic and Java is static.

Smalltalk, it is an experience, given that language, IDE and runtime/OS are all blended together, while Java can only do so much, even with the more advanced IDEs.

Clojure might be a reaction to C++/Java/C# OOP style, but it surely adopts Common Lisp OOP style.

I think if things have private state that can't be seen externally and that's idiomatic then there's a conflict, if not then there isn't. Do you think it's worth learning Smalltalk? Is it still possible?

Have a look at http://pharo.org/documentation (a modern smalltalk implementation), they have some good materials, also a discord server.

I think it's worth learning, even if you never use it.

> But in Python you're limited to working on the context of a single module. If you modify a module that was imported then you have to restart the REPL because you can't reload modules. It just doesn't work.

This is so frustrating, the Python REPL does some kind of module caching, and I haven't found how to disable it. When I asked on IRC a few years ago, I was told that I was using the REPL for the wrong purpose.

Have you considered using ipython as your REPL? I use ipython and in my profile, I have the following setting. This enables auto-reload and it works almost all the time.

Here is the option I have in my profile file. You can run this command inside the ipython session as well:

%autoreload 2

The times I have seen auto-reload fail is when there is lot of class creation magic going on or while dealing with global connection objects which sql alchemy might be creating. But, other than that it works very nicely.

I stumbled upon importlib.reload(module_name) in the Spyder IPython console, which I use as a REPL alongside the code editor in Spyder. REPL based programming has spoiled me and I find myself drifting towards lispy things like Clojure for the REPL alone, nevermind all the other good things.

Haskell (in the form of intero+emacs at least) also has very nice REPL integration and will automatically reload any changed modules and any modules that depend on the changed modules. The debugging facilities are nowhere near what CL/SLIME offers, but I find I need a debugger much less often in Haskell anyway.

If you look at commercial tooling for Common Lisp, they can do a little more than plain old Emacs.

It doesn't help that most languages that advertise having a REPL really have more of an interactive shell than a true read-eval-print-loop. Lisps do a really good job of making a distinction between the reader, evaluator, and the printer. It makes it really easy to create tools that use just one or two of these or insert themselves between the different layers to expand the REPLs capabilities.

Yes indeed, and now that repl.it is popular with noob programmers I think that distinction has been lost. Who told them that what they are offering is a REPL? Sigh...

Yeah, PHP supports a REPL too! I sometimes found it useful when working on mediawiki to debug issues when a full blown debugger wasn't necessary. And if you were familiar with the various internal API's it was pretty easy to do simple maintenance tasks through the REPL without needing to write a script.

Which one do you use? I ended up rolling my own years ago and it's worked out fine (other than the fact I've never gotten readln support working), but I've noticed a proliferation of other solutions since about the release of PHP 7 and wonder if they're an improvement.

I used Boris, and the php debugger as a pretty effective shell sometimes. mediawiki had eval.php, which is apparently now shell.php

https://m.mediawiki.org/wiki/Special:MyLanguage/Manual:Shell...

Based on my experience with that I’d definitely add a shell utility to any large application I was working on.

Reply on news.ycombinator.com