Rationale for the removal of workspace()?

Just curious, I’ve looked on github but haven’t found much information.

See the issues linked in #25046, and also #25207. TL;DR: it had a few problems, and Revise.jl has proven to be a better solution.

I saw these but having a few issues didn’t seem like a sufficient reason for removing a feature (otherwise not much would be left). And Revise doesn’t really implement the same feature (giving you a clean space to work with).

Personally I don’t mind the change too much because I don’t use workspace that often, but I’m a bit surprised there’s no stronger reasons to remove it.

My perception is that it was too much of a hassle to do right and at the same time (or because of this?) not used widely, and in the meantime Revise.jl fixed the same problem (with a different solution).

workspace() was a bit cheaper than simply restarting the image, but had all kinds of quirks. I am hoping Julia is moving in the direction that I rarely ever need anything like this, eg #22721.

That’s why I used workspace(), and I think its unfortunate that its going away.

6 Likes

Coming from R, I’m used to rm(localobject) and a fast ls() (vs slow whos()) in the REPL. I know you can set localobject=0 to save the memory, but in an exploratory REPL session this gets cluttered. From what I can see, the issues around rm() have a complex history that makes it infeasible or somehow unthinkable for Julia. I tend to think of workspace() is kind of a nuclear option. Revise.jl is lovely and a huge boost beyond R’s REPL.

In short, I wouldn’t miss the loss of workspace() if there were a rm() or if restarting Julia were faster. But neither of those seems likely, right?

1 Like