Why is 1.0 is the package target? Most of the Plots.jl issues come from having to continually work to keep up with Julia’s development. 1.0 is the timepoint where Julia stops changing and we can actually stop having to fix things that break. The target is to have something decent for 1.0, but by definition a lot of things will break with the 1.0 release. Hopefully shortly after (a few months) we can fix a lot in each of the backends.
4 Likes
Again, my point is that 1.0 is where (potential) new users of Julia will start taking it seriously. But, only if the standard library is up to snuff, and I include in the standard library some way of plotting. (I know it is not perceived this way at the moment, but for better or worse Julia is compared with Matlab, and users used to Matlab are never going to put up with something which does not have equivalent plotting capabilities built-in.)
Why is it important for Julia to have new users: obviously without users a language is not going to have and keep momentum. Without momentum it will be marginalized until everybody loses interest.
1 Like
If most people are smart they wait months before grabbing the new 1.0. You don’t get Windows 10 the first day it comes out, that’s just asking for bugs. If you buy a game on the first day, you’re essentially a tester. Same here: 1.0 is the day where the “here’s a bunch of breaking changes. We won’t break things in the near future” is released, why would anyone assume that everything isn’t broken for a bit?
1 Like
I thought the reason we had 0.7 was to allow package developers enough time to make sure their package works with 1.0?
No, it’s to have deprecation warnings to help package authors transition to 1.0. I believe they will be released pretty much one after the other. @StefanKarpinski can clear this up if I’m wrong. There was an idea of having a period in between but I don’t think it got traction?
1.0 is moving packages out of the “standard library” (Base); there’s no way it’s going to add a plot function. In free/open-source software like Python or R, and especially in a language like Julia, being “built in” is much less of an advantage than in Matlab.
Distributions like JuliaPro already do include plotting packages, however, and Pkg3 will make it even easier to set up a “standard” list of packages to install. Whether you have to type (e.g.) using Plots before running plot is orthogonal to the question of whether/how plotting in Julia can/should be improved.
Everyone agrees that plotting is important, and we all want Julia plotting packages to be as good as possible. We all want improvements, despite the fact that there are multiple production-quality plotting options already. Additional “plotting is so important” kvetching isn’t especially helpful — spend your time writing code, writing documentation, and filing issues for specific bugs and features instead.
2 Likes
You don’t think the community has anything to say about the direction that plotting support in Julia should take?
No. You can say whatever you want, but if you don’t donate code you’re not actually helping. You haven’t mentioned something that’s not already an open issue in Plots.jl. Everybody who uses the package knows what the problems are, and people developing the package know them even deeper. Why haven’t you discussed ConvertToAnyVector and its implications at all? That’s a real discussion to have that would be helpful, but it’s too deep for normal users to even know about. And that’s the issue: high level discussions are obvious, and lower level discussions that actually need to be had don’t tend to attract people to the conversations. If you want to have a real say in this stuff at all, go open up the Plots.jl issues (Issues · JuliaPlots/Plots.jl · GitHub) and give suggestions for code and designs that would fix issues, and make some PRs.
Nobody has any say in the activities of volunteers. You might say “Chris, you work a lot on packages like DiffEq, but should you instead fix ______ and ____ in Plots.jl and make more people happy?”. My response is, “sure I could, but I really don’t care about that right now. I’ll donate code when I feel like it, and I feel like it a lot more in DiffEq”. The problem with plotting especially is that it’s nobody’s paid work. @mkborregaard “runs” Plots.jl, but the success of Plots is tangential to his career which is in biology. Everybody else who is contributing to Plots/Gadfly/etc. is similar: they are scientists by day, and by night help every once in awhile because they would like the plotting situation to be better. Nobody’s career is tied to Plots, and nobody is paid to work on Plots.
Trying to tell these people what to do when they already know what you’re saying, and not offering any support (no code, no money, etc.), is crazy. Open source entitlement is a major issue that developers have to deal with every day. I would say that it’s a major source of frustration, and I have seen open source entitlement make more people stop contributing than anything else. There are even many cases in the Julia ecosystem where people have just stopped responding to any discussions because of discussions turning into demands (like this). Please understand this problem, and do not become part of the problem.
9 Likes
Let me give an example of how helping in a real discussion just amounts to “giving a shit”. Here’s an issue from yesterday.
https://github.com/JuliaPlots/Plots.jl/issues/1138
Plots.jl developers (i.e. people who volunteer time, but have volunteered enough time to be bestowed a title that I arbitrarily dole out) spent their time opening up that plot in different browsers to narrow down this issue. If you wanted to help the developers have more time to work on what you think are the pressing high level issues which require deep knowledge of Plots, why didn’t you do this? Literally the code was right there, but most of the developer time is busy working on things which pretty much anyone can do (narrowing down what’s actually causing an issue and fixing docs).
Another case is documentation. There are problems in the docs, lots of spelling and grammar problems all the time (especially from contributions I make…). Why not just PR to fix spelling and grammar? Why not add some examples? That opens up other people’s time as well. What about things you don’t know? Join the chatroom, ask, find something out, and fix the docs when you found out how to do it. That’s how all of the good docs get written anyways, since a developer with all of the details can’t write good docs (they know too much!). See this for a discussion from matplotlib.
Another case where it is easy to contribute is to just document some issues really well. Even if you don’t know how to fix it, writing down “here’s exactly what’s going on, here’s code that breaks, but this small change fixes it”. Even adding that to someone else’s issue. That makes it soooooo much easier to find out how to fix something.
Sure some issues take a lot of knowledge of the internals, but you’d be surprised how much you could contribute.
I am not doing this to be mean to you, I am writing this all down so that way it’s very clear to you that this kind of discussion doesn’t help and can actually be harmful. But not only that, I want to make it clear how easy it is to help.
5 Likes
@PetrKryslUCSD Barking less and riding lower on your horse is a better course of action!
IIRC what happened is rather that Gadfly (another native package) came around and replaced Winston. Gadfly isn’t very active anymore but it’s basically because it’s done. There’s a few issues with it (plotting images mainly) but as I understand it’s some fundamental limitation of the design/backend instead of something that can be fixed with some patching. And with Immerse you had interactivity and figures management 2 years ago.
I’m not sure what’s the windowing issues with GR but if it can draw on a GtkCanvas it should be easy to get windows and interactivity with Immerse.jl (instead of redoing everything).
Personally, for the long term for native solutions (as opposed to web ones), I think the problem should be broken into several sub-pieces and tackled one at a time:
- Windowing and input (Gtk, SDL, …)
- Drawing (Cairo, OpenGl, …)
- Higher level interfaces (Plots, Gadfly, …)
I think that for drawing and windowing there’s not that many options, you have a few good C libraries that need to be wrapped and make sure that they work together and on every system. One issue is that you need to know a bit of C and those libraries, so not that many people can contribute. Gtk.jl for example is great but has a few deep issues that almost nobody even understand.
That said for short term (v1.0) I agree whatever works the best at the moment should be put forward as a default.
I don’t think you understood my point.
The way things work right now is
(a) someone decides they wish to program a new plotting library and they start programming,
(b) some find it useful and start contributing,
(c) others find it not useful and start their own thing.
It is perfectly fine, and I am happy to contribute and to take advantage of what resulted. It works great for things that are not crucial.
But, some things are better done with consideration and planning. A lot of this deliberate thinking obviously is taking part in the design of the language itself.
My point is: plotting should also be addressed in this planned way. The community in my opinion should be involved in the decision how to provide plotting support to the users of the language: I don’t think it could hurt to find out whether we could all come up with a better path. (Which obviously doesn’t not preclude anyone from writing their own high-falutin’ graphics library.)
I don’t mean to prescribe to individual developers what to work on and such. But I don’t think the solution here is to tell people “just buckle down and contribute to what someone else thinks is the way to go”.
Why not have a rational discussion. Are our only choices Plots.jl and Gadfly? Is the right decision for everyone to use what is already there or roll their own? We won’t know until we try to find out.
Perhaps then a consensus can emerge, a group of developers interested in making it happen may then materialize, and as a result the Julia community could be in a better place a year from now.
The Halliday article is nice and to-the-point. I’ll say one thing on a more optimistic note though 
: I just went through the last 100 PRs opened on Plots (that’s for the last 100 days, roughly); and 25% of them were from people who are not associated with the JuliaPlots organisation in any way. The Julia community is really strikingly collaborative, and this shows it empirically, IMHO.
8 Likes
I think you’re right on the money here.
I do think we have, potentially, a possibility to create a more open and creative ecosystem for plotting in Julia. Over time. My one key lesson from taking part in the community around Plots.jl: plotting really is surprisingly complicated.
5 Likes
I understand your point perfectly. What you don’t understand is that you are talking in an open forum with the developers about building an open forum / committee to make suggestions. You’ve spent a lot of time arguing for an open dialogue with plotting library developers to tell them your ideas… ironically to the plotting library developers. If you actually have good ideas for what to do with plotting, just write them down and give some example code. We’ll be happy to discuss them, or most likely link to a Plots.jl/Gadfly issue where we already have been discussing it. The beauty of open source is that the community is already involved in the decisions and the dialogue is open for anyone to participate. We’ll mold it into Plots.jl if we see it as a good use of our time, build a new plotting library if we see it as a good use of our time, or ignore it. Nobody is purposely wasting time… that’s a silly idea. We just agree in some cases, and disagree in others, and nobody has the authority to make a final decision because everyone’s a volunteer.
Unless what you’re actually looking for is being a one man “community” that makes “the decision how to provide plotting support to the users of the language”, in which case you should probably provide money, expertise, or undergrads looking for class projects. Latter is preferred as we are quite busy and always are low on manpower. It sounds like what you really want a Julia Computing sponsored default plotting library with dedicated developers. That’s a great idea, but a fantasy until you cough up the funds.
Open source doesn’t need new ideas. The ideas are abundant and usually obvious, but even more important is that people don’t realize what a good idea is until they actually try to implement it. But for any idea… we just need people to actually code.
3 Likes
I am sorry Chris, I don’t think you’re on the same page. I think in fact that it is much more important to involve people who are consumers of graphics packages than those who produce them. Then we might learn what could actually make a difference for the Julia language. It could be Gadfly or package XYZ, I don’t know. But shouldn’t we try to find out?
You keep exhorting me to contribute to Plots.jl. But shouldn’t I (and everyone else) try to figure out whether that is the right cause to devote one’s time to? I suspect that most contributors to current packages write code for them simply because “they are there”, not because they are convinced they are the right solution to the problem.
No, I am not trying to get you to contribute to Plots.jl. Please read anything I posted.
Let me just be clear. You are a consumer of the graphics package and you are involved with a discussion with people who develop them. What are your ideas, and where can we see the code that shows how to implement those ideas?
3 Likes
I am sorry, we seem not able to connect. I will stop now.
Speaking of collaboration, how much work would it be to re-establish Gadfly as a backend to Plots? This goes hand-in-hand with asking about documenting the backend development API and finding out how big it actually is.
The Gadfly API has been relatively stable, is my impression, so it shouldn’t be too much work. It would require building those enhancements the other backends have gotten in the last year or so too for feature parity, though.
The key is for the group behind Gadfly to want to have the backend and to lend a (fairly big) hand with building/maintaining it. That’s really the central element for a good backend.