Well this has gone bizarre . Maybe the preconceived notion that Revise is difficult blocks the idea that it actually only requires a single character change, i.e. change include to includet, and now it all works? It’s even documented:
Look, I think that there is definitively a discussion to be had about including Revise by default. I believe using Revise should be unnecessary, and the base include should do what includet does. I have mentioned to @tim.holy that I think we need to start with the signaling, moving Revise.jl to the JuliaLang org, and having a real discussion on including it in the standard Julia. The Julia user’s survey says that the vast majority of users use Revise (>80% IIRC?), and it’s basically just a standard part of the installation process now. Streamlining that would be good.
Hyperbole is just unnecessary. I’m going to assume the best intentions and that this is just a discoverability issue. Sometimes people don’t learn how easy Revise is because it’s not a part of the “standard Julia installation”. Yes it’s only a single character difference and these issues are solved, but removing that single character difference and making its docs part of the standard Julia documentation would make things a million times easier. Agreed. We’re at the very last step, and we should rectify this. This thread shows that it is possible for someone who thinks they are informed in the language to miss a pretty crucial step to the “shadow standard installation”: let’s get rid of the shadow part and just make it standard?
About moving Revise inside Julia as default. Would it include a way of disabling it (at least the includet mechanism)? I am not sure of implications of such a move, so just wondering is there would be a way to get back the old working (if there is a use or need for it).
On the other hand, such a move could probably be a good thing for newbie’s workflow …
I cannot see why changing include to includet would be breaking, maybe @tim.holy has an example. Under the assumption that it’s not breaking, I would propose the following steps:
Move Revise.jl to Base and enable it by default.
Move Revise.jl documentation to be a section in the Base documentation. Can better integrate it in the near future.
Change include’s behavior to be that of includet, and make a new includent that is the untracked version. Change the docstring and docs in Base for include to mention the difference between the two and improve the discoverability of includent, though heavily suppose that the tracking behavior is what the vast majority wants.
And I think we’re good? Again, these are rather “trivial” workflow changes to someone who’s already using Revise, it’s essentially no difference if it’s in Base or not to someone who already knows about it. But I think that this small difference would be a massive improvement to the discoverability of good workflows, and I don’t think we should underestimate the importance of making it the actual standard.
I like the idea of moving Revise to Base, but not before we lay some groundwork to make it a lot lighter. It’s a huge dependency chain right now.
Change include’s behavior to be that of includet
Oh god, that’s terrifying. I dislike includet because of all the subtle ways people can forget about data-dependencies when they try new methods with old inputs. I fear an awful lot of false bug reports.
The video goes into depth about how to avoid errors while redefining structs. Setting it up (the loading is usually automated through startup scripts), and using it to redefine methods, is almost trivial from a user’s perspective. Often one doesn’t need to redefine structs, and won’t have to go through the hoops listed in the video.
Perhaps better make include work as includet only when explicitly called in interactive mode (repl etc.), where it may be expected that contents of the included file may change.
These (steps) are good ideas, I would also add a way to go to old behavior as an environment variable (e.g. JULIA_INCLUDET=false) as a switch control, and maybe an API (e.g. Revise.defaultincludet(false)) to complement?
Yeah, and my context was, that I simply wanted a bearable performance on my REPL, so a much smaller usecase.
It later turned out, that the 6 seconds to compile a simple function, is much rather a bug, and not how slow Julia usually is.
I was under the assumption, I have to separate out my REPL code into small libraries, just so it doesnt take a couple of seconds for every function to run.
I like this idea (with optional argument true/false). In that case it might be unnecessary to make the default behavior different to the current, safer one (track=false). The option should be sufficiently visible even to newbies by its description in the docs of include.
My main issue with includet is that in workflows which use a module not in a package (e.g. includet("MyModule.jl"); import MyModule), as is common in scripting, the script code itself needs to depend on Revise. It is not enough for the user to have Revise loaded, since the script code itself needs to be modified to be compatible with Revise workflows. Even if includet were not the default for include, being able to put something like __revise__include__ = true inside of MyModule, which Revise would auto-detect to work with include, would be useful as then the script code does not need to depend on Revise. (This is inspired by __revise_mode__ = :eval, which I also end up putting into all my non-package modules so that revise behaves the same for the module as for a package.)
We could also revisit to ship Revise in the VS Code extension by default and make it available in the REPL there. I started that at some point and got stuck somewhere, but that would probably go a fair way to make it available to a lot of folks.
One thing to be aware of is there’s a selection bias with the user survey. I highly doubt the survey captures the “layman” user of Julia – even I’ve only taken the survey once and I’ve been using Julia since 2015-ish. The survey is so heavy, that even though I’ve opened it a few other times I’ve given up partway through. It seems to me that the survey is probably only getting the Julia “poweruser” or “acolyte” users to respond. If we’re talking the “next level of popularity” in that other thread, it seems obvious that we’re targeting people who aren’t even aware of the user survey. There really should be a “survey-lite” and a “survey-heavy” in my opinion.
Anyways, even though I’ve been aware of Revise.jl for probably as long as it has been around, I don’t use it. The general recommendation I’ve seen for using Julia is to not add any packages to your base Julia installation, instead use projects if you need additional packages. And I don’t want to go through the trouble of creating a project just to have Revise.jl. Maybe I’m just a “stubborn” user, but I’m not going to use a “default” workflow that isn’t supported in the standard library because I’ve been burnt enough times with Julia where I’ll get used to a package just for it to get mothballed/deprecated for another package. I’m willing to do that for packages that provide iterative solvers, eigen solvers, automatic differentiation, etc., but not for a package that defines my default workflow.
All this to say, I 100% support making Revise.jl the default / included in the standard library if the Julia power-users have determined that the functionality it provides for workflows is valuable.
Sounds like the next survey could be a bit smaller? Do you think its worth it, opening up a post about this as well? I also like contributing to surveys, and get tired of them, if they are lengthy
As an anecdote, I’ve been using Julia for 3-4 years. I had no idea includet existed until today. I just heard people tell me to use Revise, so I checked use Revise in the VSCode settings and assumed everything was working fine.
Plenty of things that are described in these threads as being needed for “new users” are actually just for users in the bottom 98% of the Julia user distribution
Same, the few times I have used Revise.jl I just did the exact same thing as you and found it to not be all that beneficial, probably because I’ve not been using includet
. Maybe the preconceived notion that Revise is difficult blocks the idea that it actually only requires a single character change, i.e. change 
