Meh, OpenGL's inability to kill off The Old Way completely is one of it's biggest problems.

Sure, things are 'deprecated' but all that means is... well... nothing basically because they still work and will continue to work because no one is willing to say 'this shit is no longer sane!'.

In fact.. yeah... OpenGL... ugh... GPUs don't work that way.. such, the Approaching Zero Driver Overhead features (Persistently mapped buffers, multi-indirect draw/dispatch calls and the like) are great but are only half the story and even then good luck getting some working anywhere but Windows on NV or, at a push, AMD hardware... with lots of caveats to deal with on different hardware (<thing> must be tightly packed on this hardware, this is slower on some hardware etc).

And they show these graphs and things are faster and it is great and all that but it's still on one thread submitting work and it seems they live in this happy world where single core Mhz and IPC is continuing to increase at a great rate and they can ignore the idea of setting up command buffers on separate threads because, hey, you can saturate the command processor on a GPU from just a single thread...

... utterly missing the point that people WANT to be able to set things up on multi-threads because it means they can divide their work up logically (common console setup is to setup scenes from tasks which can run in parallel on the CPU) and take advantage of data/instruction cache locality (because they are shared on cores and threads!) and generally make their pipeline run faster in wall clock time.

But no... this idea that people might want to do this is apparently crazy or hard (you know, despite the fact that last gen was all about parallel command buffer building, certainly on the PS3 so this is pretty old ideas now...) and not going to happen... instead we are going to continue to pretend it is the 90s still and things will get faster!

Meanwhile D3D is completely retooling to go wide and exposed the same AZDO features, Mantle is already supporting it, Metal on iOS is allowing much the same (because OpenGL|ES is overhead city) and once again OpenGL and OpenGL|ES are refusing to move forward.

And I wouldn't mind so much but, on the deskop, OpenGL does expose some cool features which, even if you don't ship with them before they become standard, at least allow you to play with them... but instead... ugh...

Just...
Ugh.

That's seriously just the tip of the iceberg for what is wrong with openGL, so many questionable designs deceisions for a seriously outdated design philosophy.

Well, that's the "modern" issues; the thing is full of legacy mistakes and just treating GPUs like they are still 400 miles away over a network...

Maven attempts to helpfully download the updated package behind your back. Then it refuses to build because of the version conflict.

Actually it shouldn't, the version should be set to a specific one in the configuration file (though I guess if you neglect to define it that could cause the problem). The main issue I have with maven is some of the error messages can be really hopeless (doesn't seem to work well with the android sdk) and at work we have issues sometimes downloading dependencies on a fresh computer as one of the sites which hosts some dependencies doesn't always work and maven fails rather ungracefully rather than trying again.

Warning: If you're a Linux / Unix fan, skip this post !

Why the #### are Linux programmers "so out to lunch" ?!

Things that I run into all the ###ing time:

1: Creator abandons their program right after release, forcing their users to fix the bugs

2: No documentation

3: Documentation that is next to imposable to figure out

4: Incomplete / missing / inaccurate in program help menu

5: Misleading or missing comments in code

6: Programs and API that are not even close to the definition of intuitive

7: Changing entire file trees around during every minor version updates

8: Intentionally spaghetti codes everything ( ####ing hate this when debugging )
9: Has no clue what a program wizard is for

10: Has no clue what defaults are for

11: Program requires the support of several other third party API / libraries

12: Over use of Monty Python variables

That is more programmers in general when they aren't taught properly or are dead set in their ways and won't change no matter what.

Maven attempts to helpfully download the updated package behind your back. Then it refuses to build because of the version conflict.

Actually it shouldn't, the version should be set to a specific one in the configuration file (though I guess if you neglect to define it that could cause the problem). The main issue I have with maven is some of the error messages can be really hopeless (doesn't seem to work well with the android sdk) and at work we have issues sometimes downloading dependencies on a fresh computer as one of the sites which hosts some dependencies doesn't always work and maven fails rather ungracefully rather than trying again.

That is under the assumption that every other developer in the world --- or at least the public packages that you are referencing --- properly increments their version number any time a dependency updates their version number.

What often happens is that you are using packages A and B. A uses X and Y. B also uses X and Y. Then X updates their package with a new release number, and B updates their dependencies but fails to update their release number. Suddenly you have a dependency on X version 3 and X version 4, and mvn decides to barf all over the place about incompatible versions.

Depending on the popularity of the package the developers of hundreds of projects lose a full day (or more) of productivity.

One word: Gradle.

It happens all the stuff I'm currently toying with (artemis-odb, jitwatch, entity-system-benchmarks) all use maven. Which makes impossible to set up a nice working and simple Java project in Eclipse. Everything must have build steps, and sub modules, and custom compile chains, and bla bla bla. Which kinda fucks over the nice incremental compiling setup of Eclipse that I'm used to (save file, recompile that file, test the program, its fast and simple).

I'd use Gradle, I heard nice things of it, and "fucking maven" blog rands have started to appear around so I'm guessing it won't last much longer, it has passed the point of "omh this new thing is awesome!" and now people are throwing shit at it.

Using Linux-focused tools on Windows make you a second-class citizen of both the Linux world and the Windows world. It puts us in a grey immigration zone where nobody acknowledges our existence.

Hopefully Clang will change the 'intentional difficulty' issue, but so far Clang hasn't exactly been too interested in Windows all that much either.

Eclipse isn't a Linux-focused tool... it's a Java-focused tool :)

My rant topic: XCode. Maybe it's great, but coming from many years using Eclipse and Visual Studio, it's just one long pain in the arse.

Using Linux-focused tools on Windows make you a second-class citizen of both the Linux world and the Windows world. It puts us in a grey immigration zone where nobody acknowledges our existence.

Hopefully Clang will change the 'intentional difficulty' issue, but so far Clang hasn't exactly been too interested in Windows all that much either.

Eclipse isn't a Linux-focused tool... it's a Java-focused tool

I was referencing MinGW's buggy debugger and the lack of a free Windows-equivalent of Valgrind.

I tried Eclipse a few years ago, and yea, it's Java-focused (and laggily Java-built) nature made C++ work annoying. QtCreator is awesome on Windows though, as far as IDEs go.