(I am working on an advanced FE course that would be based on Julia.) […] I still believe it is very important to have something really simple for the newbies that just works. No frills, maybe, but it does the job with minimum intrusions. If it is to be PyPlot, so be it.
It’s your course, so you get to say. If it helps: you can also make a simple no-frills plotting package that helps with the plots they’ll need to do in the course. But I don’t see how those considerations are a ecosystem/language level problem.
here is something rather silly I’ll admit of being guilty of. When you click on “Edit on Github” on a documentation page, it takes you to the commit that produced the docs (so not a branch). This means you can’t actual edit the page. To be able to edit all that is needed is to switch to master. so its just a click away. Yet I remember a couple of times when I just thought “ugh, some other time” and closed the tab.
Clippy is The Answer. We just have to change the phrasing a little bit: “Hi, I’m Clippy! You can make me go away by submitting one PR that improves this documentation!” Bingo, hundreds of PRs within the week.
Maybe adding some text in the README? For example (tagging @tbreloff here), there is no CONTRIBUTING file for plots (which is where I’d look to see what sort of contributions are expected). There is one on the website, but then clicking on the editing button redirects to a non-existing page on github. Long story short, you’d need to be very motivated to find the correct place to make the change.
Well, because it is not just my students who are either going to take to Julia or not. I think of the other potential users, which are not necessarily going to be using whatever I slapped together for the course. A newbie needs something that works out of the box: install the download package and you’re guaranteed to get what you need as a new user.
One thing to be aware of is that if you go directly to the edit dialog it will automatically fork the repository unless you have push access. Also if someone is not logged in you will just see a github login screen
The contributing bit is in the docs: https://juliaplots.github.io/contributing/ I wonder if it would make a difference to have a file in the repo as well.
ExamplePlots.jl could be a good repo, but perhaps it’d be even better to have a “graph gallery” folder under PlotDocs - if you have some plots to contribute, could you add this in a PR? Would be great.
This depends on what you mean by “guaranteed”, but if you are looking for reliability/maturity like R or Matlab, you may have to wait a while. Notice that the latest released version is 0.6, which means that
Anything may change at any time. The public API should not be considered stable.
This is about the core language, the library ecosystem may of course take additional time to catch up once the language stabilizes.
Julia, especially the released branches, are perfect for productive daily work, but users occasionally need to get their hands dirty. It is very important to keep this in mind when teaching a course, and adjust expectations accordingly. Choose Julia when the benefits (speed, future value of investment, convenience) outweigh the costs (occasional bugs, library ecosystem moving forward rapidly, WIP or nonexistent libraries for certain tasks).
thanks for the lively discussion and to everyone who contributed. Initially i tried to get an overview of things/technology/SW that’s in flow (and might be interesting to contribute to) without visibility but i learned also a lot about community building and expectations on the plotting topic. I wasn’t aware e.g. about Simon’s https://github.com/SimonDanisch/MakiE.jl .
I’ll pick up some topics in dedicated other questions.
@tobias.knopp: I think one of the most promising efforts was/is Winston.jl. It is pure Julia and thus is fully hackable. Integration with Gtk.jl works nicely.
Unfortunately the development behind this stalled a little bit.
I am not certain if this satisfies your needs, but the InspectDR plotting backend is also “pure Julia”: The rendering is done through Cairo.jl, and the interactive GUI makes use of Gtk.jl.
@stephancb: To me it seems that plotting can easily become highly complex. It would perhaps be worth (and a big work) to design a hierarchically structured plot container that can be filled/modified via the usual plot(…) functions calls or from persistent storage and that can be displayed with the different backends […]
I might not have understood your concerns correctly, but: If you choose the HDF5 backend, you can:
Build your plot in a backend-agnostic way using the usual plot(...) functions.
Save said plot to an .hdf5 file.
a) Stop working/close session/or whatever…
b) Come back at a later time (or possibly never stop working).
Choose whichever backend you wish to use when “replaying” said .hdf5 file.
Replay .hdf5 file to currently selected Plots.jl backend.
Add more detail to the plot using the usual plot(...) functions (if desired).
Possibly do the same to a second/thrid/… backend.
The only real problem at this point (That I am aware of) is that the HDF5 backend is not of archival quality: Given that the HDF5 backend uses an object dump of the internal Plots.jl structures, it is very succeptible to backward compatibility issues whenever the internal Plots.jl structures change.
To make an archival-quality version of the HDF5 backend, we would probably need to develop a more rigid specification for the file structure… and probably have some form of versionning to lower the pain threshold wrt to adding features in the future.
