I think it’s completely valid and relevant for users of libraries to feedback experiences and feature requests. And it’s great to come with new ideas. I still think statements like “plotting in julia is a dismal place indeed” are unhelpful.
But e.g. @gabrielgellner 's comprehensive description above is very useful, especially as that experience is quite surprising to me.
3 Likes
I really like the work on Plots.jl and the idea of PlotRecipes.jl. It’s true that choosing a backend and finding the best backend for a particular application could be not so easy for newcomers. When I taught to non Julia users, I always chose the backend that works for the desired graph. In general, it was PyPlot because it’s more feature complete. So, the plotting line started as:
using Plots
pyplot()
plot(...)
Maybe the best option to reduce that to only two simple lines:
using Plots
plot(...)
It’s making the default backed as feature complete as possible. It could be by adding more features to the actual default backed or by changing it (or a bit of both).
Maybe the most simple solution is replace the current default backend for the most complete one, and ensure it’s installed together with Plots (using REQUIRE). But it’s a problem, because PyPlot is the most complete backend at the moment, and depending on a Python package could lead to some problems. For example, to make PyPlot usable in Travis I needed to add the following line in the configuration file:
sudo python -m pip install --upgrade pip
sudo pip install --upgrade matplotlib
julia -e 'Pkg.add("PyPlot"); Pkg.build("PyPlot")'
1 Like
Why do you say that? It used to be like that but I don’t think that is true anymore (in the sense that other backends are equally complete, IMHO).
1 Like
Not equally complete. I pointed out one important area where that’s not true: trisurf plots (with the ability to designate what the triangles are). That’s very important for FEM PDE people and GR cannot handle that to the degree that’s necessary still (though Plotly can), and Plots cannot interface with that.
If you open up a paper in something like materials science I guarantee you will see these kinds of unstructured meshes showing the solution of some FEM discretized PDE that requires this. I know of this one example very well because it’s important to my field and I couldn’t find out how to implement it (maybe you can show me the ropes and we can get this closed for good :P), but I’d assume (maybe incorrectly) that anybody else could probably name one example which their field needs. That just goes to show how diverse a plotting library needs to be. So lets not get ahead of ourselves, there’s a reasonable degree of feature-completeness elsewhere and Plots does a great job at exposing tons of features, but PyPlot is still king and there’s still work to do in Plots & backends.
(another example I used to have was ribbon plots not in Plotly to show GR is missing something and so is Plotly, but now that’s fixed and if I want a good argument that PyPlot strictly has more I’ll need to think about it 
)
I was definitely not arguing that Plots - with any backend - has feature parity with matplotlib/PyPlot.
I don’t want to go into a “mine is bigger” discussion but I have serious doubts that matplotlib is more feature reach than GMT. When I look the matplotlib gallery I would say that with more or less work GMT is able to do it almost all. Add to it the ability to deal with satellite imagery, projections and productions of wall size (Gb sized) figures. Because of its extreme versatility its has a compact syntax that scares newcomers, but that’s where I hope the work in GMT.jl will help make things easier … for easy things.
@ChrisRackauckas you mean plots like this (low res version)?
1 Like
Is https://juliaplots.github.io/supported/ updated?
For PDE’s, I would say that anyone doing serious visualizations is likely to use something like Paraview or VisIt. And we already have an excellent package for exporting to VTK (VTKExport.jl).
Could you please provide a link, github doesn’t list a VTKExport.jl and so doesn’t pkg.julialang.org?
No 
Relevant: Searchable Supported Attributes · Issue #50 · JuliaPlots/PlotDocs.jl · GitHub . We should have whatever generates this make a Markdown table and update it.
3 Likes
Huh, GMT.jl looks cool.
Yes, but we shouldn’t have to farm out to a completely separate software for even simple verifications.
I think the newest one was GitHub - JuliaVTK/WriteVTK.jl: Julia package for writing VTK XML files ?
I’m sorry for adressing this, which is tangential to the discussion, and I bet nobody cares about this, but it doesn’t feel right not to comment on this. I don’t run Plots.jl 
Plots is run by the JuliaPlots organisation, which is a really nice and active group of people. The “owners” of the org, are @tbreloff (who wrote the package), me and @daschw (who is very likely the biggest contributor to the org in the last 6 months or more, though I haven’t counted).
So not only do I not run the org, I wouldn’t want to - the reason all of this is fun is all the interactions, ideas and bikesheds being exchanged between everyone. And that’s the core: it’s fun to build something of value together.
9 Likes
For my experience working a lot in both python and R previously, Julia is unique in how many plotting api’s people use regularly as opposed to just having one or two main libraries and then a lot of pet projects that never take off. […] As well as questioning if other spaces that I am familiar with have had the same history of plotting API proliferation.
Yes, there is a similar history in e.g. python: https://speakerdeck.com/wrobstory/up-and-down-the-python-data-and-web-visualization-stack
This is a great point – but I think it’s not (at all) a technical issue, as opposed to a documentation issue. I’m really guilty of (1) reading the documentation, (2) not getting something, (3) figuring it out and (4) not updating the documentation. And I’m guessing other folks do the same (I hope I’m not the only bad person here).
One thing that may also help is to build a gallery of plots? R had that for a while (I think it’s been retired now?), and it helped me a lot when I was a new R user. I’d be happy to see this become part of the Plots.jl documentation.
8 Likes
Sorry, It is WriteVTK, I misremembered.
That’s a great idea, we decided to do that a few years ago, in fact, but it hasn’t materialized yet
I think this is a super-important point. There are many pages of docs at JuliaImages, and by the principle that more “code” means more bugs, I’m sure it has many problems. To be honest, the number of corrections have been modest (though very welcome!), but somehow I doubt it just means that my docs are perfect as they are.
Making small fixes is not hard, either: documentation pages have links (pencil-icons or “Edit on GitHub”) that with just a couple of clicks let you submit corrections. I wonder what we can do to get people more willing help out? Animate the icon so it dances around the screen? Or write some user-pestering javascript: “I see you’ve loaded this page three times in the last day. Is there some problem with it?” Or maybe even a protection-money bot: (with husky voice) “Got some nice documentation here. It’d be a real shame if something happened to it because you didn’t contribute to it.”
More seriously, I suspect the fundamental problem is that the real issues require real effort to fix, just like with code. And as hard as it is to find people willing to donate time to writing open-source code, it seems to be even harder to find people willing to donate time to writing open-source documentation. Does anyone have experience with Google Code-in, which seems to make docs a priority? (I see there’s a call for participation right now, if someone here wants to step forward and manage an application for the Julia community.) Or any other programs?
3 Likes
This is why I like chats. When people realize it’s easy to just ask questions and get some answers back, you learn what questions new users are having. I only get one new super active questioner every once in awhile so it is a small sample, but I do re-work my docs to accommodate the issues each one has.
Clippy.jl
I’d be willing to help out here.
2 Likes
@mkborregaard: I do apologize if my comment caused you distress. It was not personal, and it was not meant as a reflection on the job you guys are doing at Plots.jl.
I was thinking what the experience of someone encountering Julia’s ecosystem for the first time might be. (I am working on an advanced FE course that would be based on Julia.) I had to admit that some bits were not very appealing, especially to users of Matlab (which includes all of my students): no debugger, and plotting.
Please realize that the view from the newbie’s perspective is very different from what the developer sees: the developer knows of the hundreds of functions that work just right, and sees the big picture too. A newbie sees that just to get the first plot out it may take a minute. (I actually managed to shave my face yesterday while I waited for the plot. Admittedly with recompilation of the dependencies…)
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. But I think it needs to be there not in two years, but now.
With 1.0 we could get the momentum going, but for that getting new people on board is critical.
3 Likes