Where is actual development in Plotting?

[danielc]

@Tamas_Papp

There is no single centralized decision.

I didn’t say that there was. That’s why I used the word “community”. You can mentally replace the word “community” with “plurality” if that helps clarify my meaning.

@Tamas_Papp

If you want PyPlot to be one of them, you should not condition your contributions on some vague community decision; just start contributing now.

We are all volunteers. You cannot tell me what to do any more than I can tell you what to do. The message I get from what people post is that most people are not keen on PyPlot but are keen on Plots.jl and native back-ends. I don’t want to spend a lot of effort on work that will either be unused or lead to fragmentation. That’s my personal choice.

Ideally, I think that many in the Julia community would prefer a native plotting library.

That’s my reading as well.

All other solutions have issues, but they are different ones, and Plots.jl gives you a choice so you can work around them most of the time.

I respect your opinion. But you see why my reading of the community is that there is more interest in Plots.jl than PyPlot.

[Tamas_Papp]

@danielc

That said, the state of plotting in Julia is indeed dismal, and we should be honest about that.

“Constructive” in this context means that value is added. Issues are constructive. PRs are constructive. Testing is constructive. Helping other users on this forum or another is constructive.

Initiating discussion with the purpose of “being honest” about an issue that is common knowledge adds little value, and is of secondary importance compared to doing something.

[Tamas_Papp]

@danielc

You cannot tell me what to do

Obviously. I was just assuming that you want something (a good plotting library that satisfies your preferences), and are willing to put in the work, and suggested a way for that to happen.

[mkborregaard]

@danielc

What is really unconstructive is to criticize people who honestly say that the current state is pretty bad. I worry that that kind of attitude would actually impede progress.

Did I misunderstand this? I thought “that kind of attitude” referred to me. If I misunderstood I’m sorry. There should definitely be room for critique - what I meant by “not constructive” was “not actionable”.

[danielc]

@mkborregaard

Did I misunderstand this? I thought “that kind of attitude” referred to me. If I misunderstood I’m sorry.

It referred to one comment that you made. Not you in general; just one comment. I hope you understand the reasoning: If people who highlight broad problems are heavily criticized for doing so, that just creates an echo chamber were one only hears good news.

I do think that the current plotting situation in Julia is dismal. It’s the main caveat that I give to people when they ask me about Julia. I am sure that plotting will improve over time. It’s just that right now all the native plotting packages are very immature, and the non-native PyPlot can be opaque, and it has the kind of issues that you would expect for a package that has to call Python to do its job.

[mauro3]

Easy now!

I feel this thread has reached the end of useful discussion, maybe it should be closed?

[cortner]

FWIW I use Plots.jl as a positive example to advertise Julia

[lobingera]

I don’t see that actual development in Plotting has stopped, so why closing a discussion?

[yakir12]

Yea, I love Plots.jl! I love the recipe idea. I think that the recipe idea is in fact so good it should be used in other instances where people would rather not include a larger package, but just the recipe for how the larger package should deal with their own package, like Unitful.jl (though Unitful is small) and any GUI package (Gtk.jl).

I understand where some of the criticism is coming from but I think what’s going on here is the clash between newish Julia users that might be used to more mature and nurturing environments and the talented people that sweat and volunteer their time and effort to build this new and promising language. We’ll get where you want to go, let’s just be a bit nicer on the way there.

[ChrisRackauckas]

@danielc

If people who highlight broad problems are heavily criticized for doing so, that just creates an echo chamber were one only hears good news.

Uhh, have you seen this?

Issues · JuliaPlots/Plots.jl

This comment doesn’t even make sense given the fact that real people who work on plotting respond to detailed descriptions of both specific and broad problems daily, and the proof is just one click away!

[lobingera]

@Tamas_Papp

Ideally, I think that many in the Julia community would prefer a native plotting library. It’s just that they also realize that this is an enormous undertaking, so they are OK with other solutions in the meantime.

We arrived at that point already a few times. And just to remind a few people here: It’s an enormous undertaking, because some basic functionality on which plotting will be implemented is missing or in flow or both. Like full-precompilation - that a package starts without any need to revisit code generation? Like full-working Dataframes - having a good and consistent answer to: missing data? Like managing C-API libraries - system-independent (BinDeps, Homebrew and a few ‘other’). Like system-independent windowing? Like a good answer to C++ APIs? Like a good answer to optional modules/interfaces?

I see progress in all this, and actually development in plotting could be worse. I understand the needs of users that just ask: Why is Plotting so slow, but it’s not really fun to develop either.

[pkofod]

I just clicked on this topic after having ignored it for a long time, and since Discourse saves your drafts, I still had this written:

I think this thread has a risk of going sour,

and tbh, I think I was correct. This was way back in October, but I decided against contributing to the discussion.

We are talking about open source software here. Some people are contributing because it helps them get their job done, some people are avoiding homework, some people are simply having fun coding at night when they’re off work. This has been discussed thousands of times across hundreds of open source projects in hundreds of languages.

@danielc

I just can’t win, can I?

Yes you can. Listen to the people who are taking part in the discussion. You’re talking about echo chambers and resistance to take criticism, but you are ignoring the evidence laid in front of you yourself. If all you wish for is that things get better then you might want to consider your debate style. Notice, I am not telling you to do anything, this is just friendly advise.

[danielc]

@kristoffer.carlsson

That’s funny, because when I saw your post I was “Oh, here’s the rude guy again”. And now we have this discussion again. If this keeps happening when you interact with other people, maybe you are the problem…

I have tried to learn from past criticism, and this time I have tried to be polite and careful with my comments. Having said that, more than one person raised strong criticism of plotting in Julia long before I wrote anything.

[danielc]

@ChrisRackauckas

This comment doesn’t even make sense given the fact that real people who work on plotting respond to detailed descriptions of both specific and broad problems daily, and the proof is just one click away!

I did not intend to suggest that people were not permitted to file issues on GitHub, or that those issues were not welcome. I did not imagine that my comment would be interpreted that way.

[sdanisch]

Well, your statement was very broad, so it’s easy to find a broad range of counter examples

Anyways, I feel the back and forth about interpretations of comments of people is becoming a bit unnecessary.
Obviously communication is difficult and it can be important to discuss interpretations and defend the interpretation of your words - but it got to a point where it isn’t helping the topic anymore.

In contrast, there is a huge range of issues which we could productively discuss here!

People could open detailed issues at Plots.jl, Makie.jl or PyPlot - or summarize existing issues for a meta discussion.
I put up some things I find problematic right now in the Makie docs

We could write documents about what is wrong in the plotting ecosystem right now and what needs improvements.
There could be pull requests or discussions of certain design choices…

I’d also love to have more people test Makie and help me avoid problems from the beginning.

The community could help fleshing out modular, backend independent plotting utilities - e.g. layouting, recipes, finding optimal ticks etc.
This would be a great contribution, that is crucial for the future of Julia based plotting packages.

I’m not sure if we can get this level of involvement here, since speaking in broad terms fits most peoples time frame much better (I’m guilty of this a lot as well).

And to be honest, you need to be pretty involved to create a helpful meta discussion.

So, opening detailed issues about a concrete usage problem + neutral summaries of issues would be the most helpful thing for the developers of the Julia plotting libraries right now.

I’m sure as a developer of Makie & GLVisualize, I’m not even aware of some crucial issues that people hit in their every day plotting life - which could be avoided by good, concise summaries of current issues - maybe even in the form of documented tests submitted to Plots.jl

[BLI]

I don’t think the GR back-end supports TeX/LaTeX typesetting of labels, etc. – PyPlot supports this (based on Plots.jl documentation).

[dpsanders]

Have you tried it? Last time I tried it, they were supported (at least to some extent).

[jheinen]

LaTeX typesetting is still supported : GR.mathtex(x, y, string)

julia> using GR

help?> mathtex
search: mathtex

  mathtex(x::Real, y::Real, string)

  Generate a character string starting at the given location. Strings can be
  defined to create mathematical symbols and Greek letters using LaTeX syntax.

  Parameters:

  x, y : Position of the text string specified in world coordinates string :
  The text string to be drawn

julia>