Based on discussion here, that’s what I put in my .juliarc.jl file. The cost of the first plot is taken at launch.
using Plots
default(show = true, size=(1100,800)) # personal preference, not necessary for this trick
p = plot(1:10);Plots.close();
Of course, this means that firing up Julia now takes about 15sec to launch. But I much prefer to spend the 15s at launch as opposed to anxiously waiting to see my “new freshly-baked results that might shatter the scientific world… if only I could see the results NOW”
There’s still #16467 (which prevents you to use workspace when using some packages) that is quite annoying, hopefully it gets fixed at some point. Thinking about it I should maybe evaluate all my code in a dummy package and then just use another one when I want a clean workspace.
Actually, after #265 was fixed, I found the opposite to be true. The reason is that my modules usually contain type definitions, and when reloading/replacing a module in the REPL, any data which was defined using the types of the original module will go into an “orphaned type” state so that all the module functions can no longer be applied to those types. This is true even if the type definition was not changed in the updated module.
To clarify what I mean, consider the following module in “Foos.jl”:
module Foos
type Foo; x::Int; end
f(foo::Foo) = foo.x + 1
end
And this REPL session (on 0.6.0-rc1):
julia> include("Foos.jl");
julia> foo = Foos.Foo(10)
Foos.Foo(10)
julia> Foos.f(foo)
11
julia> include("Foos.jl");
WARNING: replacing module Foos
# now foo has a type which is out of scope
julia> Foos.f(foo)
ERROR: MethodError: no method matching f(::Foos.Foo)
Closest candidates are:
f(::Foos.Foo) at <redacted>/Foos.jl:3
(Also, the error message is maximally unhelpful.)
For this reason, I only put stable code (e.g. type definitions) into the module, but the functions which are under development, I put them into a seperate file outside of the module scope. Reloading this file will just update the function definitions, and avoids replacing the module. Once the function has stabilized, I put it in the module.
RStudio has a number of really great features that I can only assume will also come to juno in time. Working with RMarkdown files is really seamless in RStudio; unless I’m mistaken, there’s no “knit” button in juno. I do think that Hadley Wickham is a shining star in the R world who really understands that programming is done by humans. For example, devtools is a really great package which I think has really accelerated development in the R ecosystem. I’ve been working on PackageGenerator.jl to make “batteries included” Julia packages, so we’re getting there (and there are a lot of really great packages working on literate programming, include documenter, weave, macrotools, etc). But I do think that everyone could learn some lessons from the Hadleyverse, including:
Functions with full words separated by underscores (and in general, programming that follows natural language as closely as possible)
Gearing everything towards absolute beginners (and being more friendly to people who ask stupid questions, as I often do)
The suggested workflow atom-julia-client/workflow.md at master · JunoLab/atom-julia-client · GitHub actually suggests using an empty buffer rather than the console to develop code within the scope of a module. I always do that (with a ‘scratch.jl’ file), then just rerun the code up the point where I’m at to regenerate the state.
You find the R community more friendly towards beginners? I in contrast find the julia-community much more friendly and welcoming (to people who appear to be making an effort), though with a tendency to urge people to contribute rather than to request.
Fair enough. Oh, by the way, there is markdown preview in Atom markdown-preview-plus. There is no such thing as JuliaMarkdown, though, of course - the rMarkdown feature of RStudio seems more intent on competing with something like Jupyter?
ClobberingReload.creload("modulename") doesn’t have that issue, because it reevaluates the code inside the module (as does Autoreload.jl and Atom) instead of creating a new module with new types .
The fact that you need external tooling is also a sign that something’s not ideal with the base language. Maybe it’s just a necessary evil and there’s not much do do about it, but it doesn’t feel so great currently.
I’ve been writing my code in a package, and putting my exploratory code in runtests.jl, then just running Pkg.test("mypkg") over and over. It runs fresh every time, so I can change anything, it goes pretty fast for small package (it gets cumbersome eventually). I also end up with way better test coverage this way. It still not ideal, but its easy and I understand it. Once the debugger is easier to use, I’m guessing that will solve most of my remaining complaints.
For what it’s worth, “Julia has” and “there’s a package for” is pretty much the same in Julia, and that it a major strength. Practically nothing has to be in Base, other than what is there because it is handy.
