I don’t understand how Matlab is your counterexample to this. You can make decent plots in Matlab, but it takes tons of work. By comparison the defaults in Plots.jl are amazing. And the control capabilities are even better.
3 Likes
I kind of understand @leon point.
I use GMT.jl and Plots.jl. But it is hard, from my point of view, to make fast figures with either. My current workflow is to get some simple figures in Julia and then use GMT or Matlab to make my plots for my publication.
2 Likes
What are the features those have that are better? Looking at some examples they do not seem any easier (discounting the fact that one may be fluent with one and not the other).
The idea of building composed plots with different backends is interesting, and a package could do that, maybe Plots itself, as mentioned.
I don’t need (and actually don’t prefer) 3D plots, so there is not much that I miss in Plots+GR. There are small things that I would like to see improved, which are, as far as I can remember now: a) better integration with latex syntax in general, to allow diverse fonts + latex; b) easier layout handling; c) easier fine tuning of positions of annotations, labels, etc.
(b) and (c) get really easy with a GUI, in which one could move the elements on the plot and get the final coordinates. (This is the Origin advantage over all of these)
4 Likes
I do exactly the same thing!
I would think it is a great thing to design a Julia plotting framework / standard, so that Julia can handle the plot layout, and other plotting packages can fit in with the needed compatibility.
Alternatively, a package called something like PlotLayout.jl should be created to handle that. The issues is that it will be easier to ask the package developers to conform to the standards of Julia, instead of asking them to conform to the standards of another package.
GMT (and GMT.jl) is a lot more than just plotting. What is it that you can do easier in Maltlab than in GMT.jl? Honestly, I’m not question your answer, just want to know how things can be improved.
And BTW, though there is not GMT back-end to Plots, many of the plotting options are the same or similar.
Edit: Not counting volume rendering. There Matlab is far superior.
Hi @joa-quim not at all a complaint on the GMT or GMT.jl. We all know GMT is the master for geo-plotting and other types of postscript generation. Maybe it is the old me, but I still rather make my final figures in the standard version of GMT and use GMT.jl for quick figures…
I think the general workflow in Matlab for quick-and-dirty figures, in my opinion, is still the best:
e.g.
figure
subplot(2,1,1)
plot(x1,y1,'ok')
hold on
plot(x2,y2,'*r')
subplot(2,1,2)
pcolor(x_matrix,y_matrix,z_matriz)
Yes it would be great if there was one plotting system that can do everything, put that into Julia Base, then everybody can build packages off of that like in Matlab.
The problems:
- build a plotting system first that can do everything (we’re trying in Makie but it’s hard, there’s soo much to do)
- convince everyone that this one approach is the best (basically impossible)
- finalize code so that it can be moved into Julia base, therefore no breaking changes are allowed anymore until julia 2.0 (also basically impossible because there’s such a huge surface of functionality, how do you know you’re done)
The path forward is that each plotting package does its best and we see how the user dynamics play out. Users will flock to the most useful, best maintained packages, and we can try to build bridges between the most used packages.
7 Likes
Maybe it is naive of me, but perhaps Julia needs something like BasicPlots.jl. Something that aids during the development of the code.
Not an advance package that can do everything as well and pretty as GMT.jl or Makie.jl. But instead (once again, taking the basic Matlab idea) a package that allow for quick-and-dirty plots. Something simple (with a fast learning curve) that does the very basic 1D and 2D plots (plots, heatmap/pcolor, contours), and maybe some basic 3D (plot3, surface) and some stats plots (histogram, boxplot). Perhaps with a simple layout command (subplot).
The rest can be achieved in the advance plotting package (@joa-quim knows that I will never stop using the GMT 
).
Just a thought.
The point, @marianoarnaiz, is that from my perspective your description is exactly what I want to achieve with GMT.jl. For example your subplot example is obtainable with something around (sorry, maybe later I can come with a clear working example)
subplot(grid="2x1")
plot(x1,y1, marker=:circ, linewidth=0.5)
plot!(x2,y2, marker=:star, mc=:red)
pcolor(..., panel=(2,2)) # EXCEPT THAT pcolor is not a GMT.jl module
subplot(:show)
But subplot is a harder target since there are so many things we may want to do/tune in a subplot figure and at same time make it simple to use. Matlab just choose awful bad defaults that everybody complains about (e.g. this ML package called “Plot it,…but plot it well! (MATLAB)”)
Anyway have a look at this subplot toy example.
1 Like
It seems that Makie is really the plotting package under the most active development currently. If there is a wish list, I would like to suggest a slightly better support for basic geo plots or if there already is such a support, some additional documentation on this topic.
What is the advantage of that relative to:
julia> using Plots
julia> plot(layout=(1,2))
julia> plot!(rand(10),subplot=1)
julia> heatmap!(rand(10,10),subplot=2)
? (serious question - meaning, what does that matlab workflow do that is so interesting? From the examples and code snippets I don’t get it)
2 Likes
The point is that Matlab handles layout from within, thus allowing subplots to be made from any external packages.
In your example, imagine you want to make subplot 1 using GMT.jl and subplot 2 using Makie.jl, and so on.
1 Like
Nice. That is something interesting, yes, and clearly could be an interesting development route for future Plots.jl.
2 Likes
Ok, you keep reasoning on the illusion that Matlab accepts more than one packages.
… but maybe you are thinking in GMTMEX, the GMT.jl ancestor but again, have no illusion, there is no other plotting package in Matlab than the one provided by TMW (which changed dramatically arround Matlab2015)
Thanks for the comments , Joa-quim!
No, I’m not thinking of GMTMEX.
One thing I want to make clear is that this discussion is about how we, as a group, could make Julia better. The use of Matlab as an example is just a coincidence. I have no interests of creating any illusion on a programming language that I’m trying to stay away from 
2 Likes
A single figure with subplots generated by different plotting backends sounds like it would be nothing but ugly and confusing. Why is that something you need?
3 Likes
This is not about layouts at all, you’re mixing frontend and backend. Matlab has one backend and lots of frontend packages, which are of course combinable because they all use the same backend. In your comparison to the Julia ecosystem, you list a bunch of backend packages, where it’s not easy at all to make the parts work together because they are entirely different things. The simplest thing about it would be layouting, all the other backend stuff is the problem, which matlab just doesn’t have because there’s only one backend. So it confuses me a little that this thread keeps going on about layouts when that’s not the point. What you want is one unified backend, and that’s not going to happen (soon).
5 Likes
@jules, how the lack of a unified backend prevents the use of the same plotting language and shortcuts (at least, as much as possible)?
For example, what obstacles do the different backends pose to allowing a common syntax such as: plot(sin, lc=:red, lw=2) (shortcuts for line_color and line_width) ?
The most annoying thing is to have to learn several “plotting languages” on the same julia platform, to achieve exactly the same thing.
Thanks for your expert advice.
Well you see exactly that playing out in Plots.jl, it tries to unify backends (matplotlib, GR, plotly.js, etc.) but that only goes so far. At some point, backends are just different and to be flexible one needs to descend down to the backend syntax, at which point the gains from Plots.jl are not so big anymore. So yeah I’m not a big believer in “unified syntax”, I’d rather learn one backend that is powerful really well than have one abstraction for five backends that is imperfect for each of them. Many people seem to prefer the second one though, which is fine, that’s why Plots.jl exists.
10 Likes
@jules, is it possible to allow both? That is, a shorter subset of the common syntax (with limited functionality) and the full-fledged “backend-specific” syntax?