The crux of my whine is something like this...
OpenGL and "Modern" OpenGL (3.0+) are industry standards that are very well documented.
On top of that, they aren't that damn hard to learn. They're also very well considered, because hey, they have to be. OpenGL is the backbone of so many things.
Every so often, I'm poking around, or hey - even USING some kind of specialized graphics system that has decided that using something like pushing and popping a matrix requires a special call... that then is really, in turn, calling the OpenGL function.
So, in my mind, I cannot help but think that this is some endeavor in stupidity, a splaying of efforts, and bad for performance. If one was to try to say, render a rectangle and make it rotate using OpenGL and the slimmest amount of frameworks needed in say, an Xcode project, if you look at the compiled code (eg., the executable), you're going to see that it is much more straightforward and streamlined than what's created by these kind of abstracted "easy" libraries/frameworks/systems.
How much more useful would OpenCV be if all of the aspects of it that could have been written in OpenGL, were? How much more useful and straightforward would OpenNI have been if they had given the segmentation algorithm in OpenGL instead of all of those wrappers?
Then there are things like ofx and Processing. I want to tread lightly here. ofx and Processing are both great because there have been a ton of contributions by many people, and there's a "scene". That's great. I use both, and they do what they do.
Yet... I don't buy the bit about making a the language "lightweight" and then, boom, it's easier. Slowly but surely, many of these languages reinvent all of the functionality, using a bunch of system specific calls that do the exact same stuff, but are often in way more flux.
So, in reality, there are still a bunch of different methods to learn. They rarely cut down on the amount of code that needs to be written save for a word or two here or there, and often require integration of more, sometimes not too well written frameworks. Before I get my head ripped off about the "sometimes not too well written" comment, it's a fact that with so many of the libraries, that they're in more transition, methods are changing constantly, and for what? To settle down on what the appropriate syntax is to do stuff that could be done in something already proven, and existent, OpenGL, that already has established syntax.
What happens when you need to tap into more function that what's provided by the abstraction? A big pain! Oh yeah, and you wind up using OpenGL.
Now, you might say, "George, you use QC, that's an abstraction!". Well, yes and no. Hey, like I said, I also use Processing and ofx.
Yet, QC is a graph evaluation system. It does have it's own frameworks it uses, and system for writing additional modules, sure. Yet, the crux of it, is that it is NOT a code language on it's own. It's a mechanism for determining flow and evaluation of sub-modules, that I can write using Obj-C, OpenGL, OpenCL and other good stuff. Heck, I can EVEN use ofx and other stuff, or roll my own patches to use whatever the heck scripting language I want. There are convenience methods, sure, but it's not "all about" the convenience methods. There are massive benefits to a modular system, in my estimation.
People have their socks rolling up and down about WebGL, and I do too. Yet, for YEARS I have been able to embed the same shaders in websites using QC, AND quickly make GUI to control it, AND switch shaders willy nilly using all kinds of control methods, from artnet to iPad. I can have a shader updating and compiling live with every single change I make to the code... or not.
That execution graph can be used on it's own, used as resource in an app, embedded in the web, or whatever.
When I read about people that have minimally worked with QC, and they write some plugin that's slow as shit and write it off... it's their loss. It's not because QC can't render a ton of points, or do any of that other stuff, it's because the user isn't taking the time to read docs, go through available sample projects, etc. It is easier to fail than succeed sometimes.
You can have an app running as a single module in QC, it doesn't have to be a simple function. Any of the Processing, ofx, etc., stuff, can be done in QC the same or similarly, and then you have the advantage of modularity. You have a patch that you can use over and over again, and use other patches to trigger it, dictate flow of data to it, bind parameters to GUI when making an app, etc. Hell, you can mock up your own GUI *using QC*. The fact that a bunch of QC users don't do this stuff doesn't mean it can't be done, and done well.
Getting aside from the QC thing, I just ask people - if you're rendering an object and loading a shader... does it really make sense to use Processing? Does it really make sense to use ofx? Does it make more sense to just do the thing using well established OpenGL, and wind up learning something that isn't some kind of hopped up college student cesspool of disorganization, where the innovation is driven by poor communication between tons of coders of intermediate skill?
Please excuse any typos.