If the Julia community ends up paying people for writing plotting code (in whatever form), I would prefer that to be invested in a mostly native implementation (eg like Makie.jl). We should plan for the long run.
29 Likes
I heartily agree with Tamas: the focus should be on pure-Julia solutions. Algebra of Graphics based on a Makie backend is fantastic. Gadfly was/is great.
Makie seems to be like nuclear fusion: great promise, always several years off from being usable to all and sundry. I think if all the experts in plotting and graphics who are currently wrestling half-a-dozen backends focused their attention on Makie, there could be real progress.
16 Likes
Agree. In my first reply I mentioned that focusing on either GR.jl or Makie.jl would be much more productive than trying to maintain multiple backends. I am hopeful for that.
2 Likes
Why is the GR.jl package not in the Julia Plots organization?
This would give the package more visibility. Am I right?
Not really? Iâm guessing you donât visit the JuliaPlots github org page to select plot backends, and that is the only place it would gain visibility. It is already front and center in the docs and much of the discussions surrounding Plots.jl.
3 Likes
I browsed some Plots.jl issues and i see problems in: doesnât work as expected (unclear in documentation that it doesnât), never tested, is not reproducable, is actually as problem of âyourâ julia environment, is actually a problem of a dependency.
So for anyone trying to help: Go into dialogue in the issues to clarify what work in which place is needed.
For the âexperts should gather to help a central plottingâ - well ⌠this didnât work now a few times. Even Plots.jl was Tomâs move to start something on his own before the âgroupâ concluded how the plan should be.
And looking at FTTP (slow compilation of complex code) iâd be not so positive on native julia only. Even i donât understand how ânativeâ do you want it to be: Do you stop at graphics library like Cairo/Skia or go down to OpenGL/Vulkan or down to GPU programming. Some infrastruture in graphics that can be integrated with Package Compile might be needed first.
3 Likes
I assume you meant time to first plot (TTFP) instead of FTTP. Isnât quite solid progress made by Tim Holy and many others on reducing method invalidations and improving what percentage of code is precompiled?
I think the point raised above is that, while the problem is mostly fixed for Plots, where much of the heavy lifting happens in external C libraries, doing the same for Makie is trickier, because there a lot of the heavy lifting happens in julia, until you pass on to a low-level Cairo or OpenGL backend.
That being said, there is already work to improve that, see eg dont use kw for lift by SimonDanisch ¡ Pull Request #749 ¡ JuliaPlots/AbstractPlotting.jl (github.com).
3 Likes
To be sincere, that was absolutely not clear to me, and I think already as it is it provides much more than that (all agree here clearly).
I have been using Plots with the default backend (GR) for everything I need to. I do not expect to make all sorts of imaginable graphics with it. I think it is natural to expect that something very specific (like 3D-earth plots) require specific libraries, but Plots (with the default backend, whatever it is) should be enough to produce high-quality and relatively complex plots.
Given its importance and its central role in the user experience, and the name it has locked, it deserves to be treated not only as a prototyping layer.
With some polish in what concerns the support for different fonts, easier layout handling (particularly for overlapping plots), and some more fine control on figure size and resolution, it is a very satisfactory solution to almost all most common plots people need to do.
Most people will do 2D plots of data, combining various plots in the same figures with different layouts, and draw lines, scatters, histograms, perhaps contours. A simple and robust interface for that is what I think Plots should focus into being. It is almost there already.
14 Likes
I agree with your view. For many things Makie is now a fantastic option and features are added every day and bugs are fixed on a daily basis but I also find rough edges many times. At the end I usually find that the safest option is to use Matplotlib, because it is very mature, but I really would like to have my Julia option.
The issue I found with all the Plotting systems is that they are incredibly complex so contributing by fixing bugs and the like is sometimes not very easy unless you have made it through the very steep learning curve of the internal workings. This feature makes it sound like it is not entirely suitable for a freelance, ocasional work but more suited for a full-time job if we wanted someone to be able to contribute to all the complexity of a package like Plots or Makie.
5 Likes
Maybe a good training video or two on how to maintain and make changes to the Plots package. I think the complexity of it all stops people from taking the first step to becoming a contributor.
7 Likes
I believe a fair way would be to use https://www.bountysource.com/ and mark issues youâd really want to get resolved
2 Likes
This is rather late, but is now possible to sponsor JuliaPlots via opencollective hosted by Open Source Collective. This is also linked to the sponsor button on github.
Collected funds will likely be spend for bounties first and depending on the amount raised we could think about paying a maintainer.
9 Likes