I think about 5% of the people are like that. One of my coworkers at the time had monocular vision, and he could never see the 3D images either.
At first, I had to concentrate on the images a few seconds before my brain could get in the right mode. But after a few days of working with the images, it became almost instantaneous. Now after 30 years, I’m back to staring at them for a few seconds first.
I don’t think object orientation is necessary for a good plotting package. For over a decade I used the Interactive Data Language (IDL). From the start this had very good imperative plotting procedures that I loved. Then in the late 1990s it adopted object orientation. The adoption of object orientation for a new plotting library was a disaster. The syntax was not particularly intuitive. However, a bigger problem, which admittedly had nothing to do with object orientation, was that the implementation did not match the documentation. It was obvious that at some point they had a “we have got to ship this sometime” moment and it was shipped in an incomplete state. However they never fully corrected this. and as a result people were happily using procedural graphics over object oriented graphics for more than a decade later.
FWIW a problem with incorporating graphics into a standard language is that it tends to be very documentation heavy. Another problem is, that if you want to have real time graphics, it is useful to have environment dependent options. File output options can also depend on the file type.
There are surely subjective aspects, but let’s not try to dismiss the (few?) objective ones. I should have provided paper reference straight away I guess:
http://dx.doi.org/10.5670/oceanog.2016.66
https://www.nature.com/articles/s41467-020-19160-7
By community attention I just meant that people doing research in color theory most likely develop their new findings in popular modern packages, which is not surprising at all. Old packages, that surely had good reasons for their defaults, i. e.
I totally get this and agree it was the right choice at the time.
But now, despite obviously giving the possibility to customize everything (I mean, you can always pass a list of rgba values or hex codes…), they are slow to catch on sensible defaults, which is really the only point I was making about colors. Default line palette and default colormaps.
You can do whatever you wish, of course, but please be aware that even at an early stage of inspection looking at your preliminary data with a deeply skewed colormap would introduce a significant risk of getting equally skewed preliminary impressions, and in the extreme case jeopardize the research process itself. It can be late to realize a feature in the data was just a colormap artifact when you are preparing the definitive figure for the paper! Even more important if you ore one of your collaborators has color deficiency or you want to print with low quality hardware or even in black white: rainbow colormaps would become basically unreadable, newer perceptually uniform colormaps would generate a smooth, monotonic, constant derivative grey scale map i. e. exactly what you want.
If you don’t buy these points please just read the paper above, especially the lates nature communication or the one about matplotlib’s new defaults.
You need good defaults because you cannot expect any scientist to be a color theory expert and we all want the scientific community to avoid color-related pitfalls, right?
Finally, I’d give you a personal viewpoint (because yes, there are many subjective aspects). I personally don’t like the Gnuplot syntax, but I use Gnuplot a lot for portability reasons on HPC servers (yes the marvelous “dumb” terminal). I almost equally dislike Python (even if I find it a little easier to navigate) and I’m actually personally frustrated a bit by matplotlib’s popularity.
What I like for plotting is matlab, which unfortunately has not-so-good colormaps so, since I didn’t want to surrender to Python, I just collected myself a bunch of open source implementations in a unified user API, which for my projects substitutes always the default one. So yes, what I most agree with is:
where “they” includes matlab too.
(You cannot expect every user to roll his own colormap package for every plotting library right?)
Anyway aren’t plotting libraries all about visuals? Why is it so strange to evaluate them on a visual basis?
But yes, for intensive plotting, which is nothing but very intensive I/O I also agree that we should avoid interpreted approaches. A wrapper to matplotlib or similar is only really useful if all you want is to generate plots after all calculations are done and I agree that can well be done by just exiting the fortran program and starting a Gnuplot, Python or whatever session.
The only convenience about doing it from inside a fortran program is to avoid passing manually the data though dat files, which are terribly storage inefficient, or even more refined formats, like HDF5, which instead introduce the problem of successfully interface to the storage standard from both sides.
So I agree the choice for intensive plotting is not trivial at all…
Color vision deficiency (CVD) affects more than 4% of the population and leads to a different visual perception of colors.
I think this includes the various kinds of color-blindness, such as the common genetic red-green condition. I was surprised to learn a while back that the opposite is also true, there is a genetic condition that allows some people (mostly, or maybe all, women) to see more colors.
Ok, there is much much more than I thought around… and some of these appear really nice to experiment with!
Thanks a lot for your work on searching, parsing and cataloging the ecosystem. It’s really useful!
I agree.
However Fortran at this stage can do well by focusing on the other saying, getting the basics right.
Incorporating any kind of direct support toward graphics in the language standard is likely a fool’s errand now.
However, the language standard can include a few basic goodies that will make it easier much to develop user libraries or to advance community stdlib efforts toward graphics that will also make it easier for the practitioners to consume them.
Consider something as simple and basic as ENUM: a good-featured ENUM facility can make it so easy and convenient to work with plotting and graphics libraries. Alas, Fortran 202X falls so short even with this.
And an intrinsic bit type in Fortran, one that would help out so much toward user library solutions toward graphics, appears entirely out of reach for the current practitioners in their programming lifetimes.
It is such a shame how the practitioners of Fortran keep getting shortchanged by the base language and its committee by continuing to overlook certain basic facilities, all in the name of disdain or wanting to do that which is less work for vendors at the cost of practitioner needs. It should not be like this.
I’m mostly interested on eps images (plots) for publications. None of those has color, at least in my domain of interest. On the fly plots are useful sometimes, but I don’t think you need a PhD in color theory to pick the right palette for such plots, given they just serve a quick inspection during runtime.
Because you should give them a serious try before concluding anything concrete about PLplot or DISLIN. The colormaps they have in their website are not very representative, I guess they made them that way to get more “eye-candy” images for obvious reasons - which apparently had the opposite effect to you than what they would expect.
Since you seem very interested on colormaps, and know more about color theory, I would be interested to hear your opinion about PLplot’s and DISLIN’s default color schemes - but again, don’t judge by demo images in websites, this requires a serious try first, which in turn requires time, and we are not in lockdown anymore to have plenty of it. 
Weird, you gave me the impression you are yet another “Python zealot” - you know, the ones ready to attack if someone says anything even slightly negative about Python. Every community has such zealots, but for some reason Python seems to have even more of them, or at least that’s what I have seen. Just to clarify, it’s still a small minority of the Python community, it just seems to be bigger in numbers, simply because the Python community is larger than others. And again, that’s what I have seen, it’s not concrete Statistics.
I apologize if I misunderstood.
Now, about matplotlib… I never tried it. I avoided saying anything about it for that reason, I only said that I wouldn’t consider a foreign package since I don’t have to, plus it’s interpreted. I must also admit that I am a bit… allergic to anything starting with “mat”, if you get what I mean - which I’m sure you do.
I just got an automated message saying my last post was flagged as “inappropriate” without any explanation why, and what exactly was the offending part. I honestly don’t see anything inappropriate in this post, in fact I think it was a friendly one, mainly addressed to @rgba.
I am also not sure I am willing to tolerate censorship. If this one is flagged as well, there won’t be a third. Ever.
Edit: The post was restored, it turns out it was not intended for deletion (just flagged), and it was deleted by mistake.
Oh. Well I agree that this was all together a completely friendly discussion about different opinions, what you would want an ideal disagreement to be. If that helps…
Yeah a PhD maybe is too much, but I’d rather avoid picking a choice all together and just trust the defaults. Of course there is always a range of expectations about sensible default vs easy and powerful customizations. Normally “power users of that particular aspect” prefer the latter and they know what they do, so that’s perfectly fine. “Normal” users wrt to that feature would instead prefer a nice default to put their trust on. It’s really the same as with linters/formatters, linear algebra packages (full blown low level calls to lapack/arpack/etc vs “poor man” easy wrappers like Armadillo, Matlab, Numpy etc), and finally with others aspect of plotting, like having crazy full control the tikz style vs wrapping Gnuplot in a very limited but friendly script like Eplot. If you “know nothing” about the low level details the “poor man” things can drive you a looong way, and faster then trying and drowning in the big power houses (thinking especially about Arpack here 
). If you instead are an expert you would find yourself very limited by the “easy and opinionated approach” and flee away fast.
Yes, that’s exactly the point. If you look at Beliavsky’s list there is so much to try out, hence you really need to make them “fail fast” before spending too much time on it. These big-number early selections are always inherently flawed but… I think that’s it in this world full of stuff to do and scarce in time.
Ok, specifically on this I totally got my eye off the ball apparently. From my reasoning I would expect the homepage of a plotting library to give the feel of what the daily experience plotting with it is, namely the defaults and some “ordinary” setups. Maybe have a “fancy stuff” page put somewhere else, for the curious/interested. But of course any entity would have its own idea of “marketing” and representation.
Oh no, no, really not 
.
Maybe just that the community is insanely big? Like collecting all kind of people, including these…?
Hehe! Matlab has its own huge pitfalls, especially regarding structured/modular programming and I love to spend my time bashing those aspects (like really, just lookup how their namespaces work, with popcorn!). It’s really a toxic 
love/hate relationship after all… With Fortran is more about a mature warm friendship maybe haha.
I understand completely, in fact I must admit I did something similar several times. There are only 24 hours in a day, so to speak. However, “summary trials” like those unavoidably lead to some “false negatives”.
Yes, apparently the good guys behind PLplot are not exactly skilled CEOs - and I am not sure this is a compliment or not.
This is in fact a very logical explanation.
The thing that bothers me about Matlab is it tends to replace programming in a high-level language, while it’s typically orders of magnitude slower. It also encourages people (usually novices in research) to use it as a collection of “black boxes”. There is nothing wrong with using a ready-made numerical method hidden behind a single Matlab command, because not everybody wants to be a numerical analyst. But they should know what exactly that black box does, and what are its limits. In many cases, they don’t. I mean, when you have a big fat red button in front of you that will solve your problem at hand, you are eager to push it, right? The solution is one click away, who cares about the details. People doing such things don’t go far away, of course.
And to be honest that’s not a Matlab problem, specifically. Similar platforms, like Scilab and Octave can be used that way. Even Computer Algebra Systems, originally created for symbolic computations, are used that way well.
Decades ago when the main language wars seemed to be Fortran vs Algol vs Pascal I heard someone ask a head of a mathematical department what programming language he used. The answer: “Graduate student.”