Wait, you're suggesting that if I want to submit a one line patch to your code, I should convert it wholesale to spaces, and then submit the patch? That doesn't sound like a great way to do source control to me ;)

Meanwhile, if we both just use spaces all along, neither of us sees any fucked up layout, and both of us can edit and work on the code without having to submit ridiculous patches that convert all the white space in the file to something else.

Because tabs are not enough to lay out code well (you always end up with a couple of spaces to align things correctly). Then once you introduce a mixture, you end up in a situation where a change in tab-width causes layout fuckup (i.e. you get fuck ups on a different user's system).

Meanwhile, if you use spaces for everything, code remains well laid out everywhere. If you have even a half-decent editor, it will allow you to edit spaces as if they were tabs, so using spaces has exactly 0 drawback.

You realise that the way you (intelligently) make buildings survive large earthquakes is not to build ridiculously strong foundations (those actually make your problems worse). Instead, it's to design the building to move and sway with the earthquake. Hence why any large office building built today in the bay area is likely to be sat on big rollers, and/or have a weight system on the roof to damp the building.

So what you're saying is basically "I want I high level API for drawing graphics reasonably fast". That's fine, you should go grab an engine. There are plenty of very high quality ones out there, many of which are free (at least until you start making money). There are also plenty of mid-level ones that will not cause you to have significant lock in.

However, the person writing said engine for a AAA game, or an app that involves 3D rendering and that has to conserve battery life as much as possible while still hitting 60fps doesn't have the same set of constraints as you. People in that situation need to get as much performance as they possibly can, and for them, having OpenGL using up 20% of the CPU (on a desktop), or 50% of the CPU (on a mobile device) is completely unacceptable. The guy writing the AAA game could be using that CPU power to make the AI smarter, or simply to push more render items. Similarly, the guy writing the mobile app could get double the battery life if they didn't have OpenGL sat in the way.

For reference, the numbers above are reasonably accurate. Go try to push 200-300 draw calls on a reasonably high end Android or iOS device - you'll discover that an entire CPU core is used up by the OpenGL driver. When you compare that to Metal, where you can get more like 3000-4000 draw calls. That really makes the difference between a game that looks like a mobile game and a game that looks like a PS3 game.

You may not think it's a good idea, but every single game engine developer on the planet thinks it's a great idea ;).

No, it absolutely does come from designing the API differently.

The key conceptual difference is that in OpenGL, you change state, change state, change state, change state, render, change state, change state, change state, change state, change state, change state, render. You do this every render loop.

In {Vulcan | Direct3D 12 | Metal | Mantle}, you define two states at program launch, then each render loop, you do: bind existing state, render, bind existing state, render.

There's two gains here
1) A small one - you're calling fewer driver functions per frame. Many of these cross the kernel barrier, and as such are actually fairly large performance drags. When you're talking about doing a few thousand renders per frame, cutting out 2 kernel calls per render is a significant win. Cutting out 6 library calls per render is a less-significant, but still reasonable win.
2) The calls to change state can do much less. Like, unbelievable less. In OpenGL, the driver does not know when a render call is going to come, so it has two choices, either 1) it can do all the work for a state update every time a state change call comes in 2) it can cache all the state changes until a render call comes in. In the case of 1, this means it does a lot of duplicated work, in the car of 2, this means render calls lag a really long time. In {Vulcan | Direct3D 12 | Metal | Mantle}, instead, the driver can do all of the state verification and preparation work only once at application launch.

Why is state verification and preparation work so expensive I hear you ask. Well, a state change can have surprisingly large knock on effects. For example, on many graphics cards, blending is implemented as a frame buffer fetch, plus a few instructions at the end of the shader. That means that if you change the blending state, the driver actually has to re-compile the shader. Similarly, if you change the vertex format (e.g. to normalised vertices), again, that's implemented as a few instructions on the front of the vertex shader, so... gotta recompile and relink again.

Basically, a surprising amount of stuff requires a complete recompilation of the shader, and that's really costly. OpenGL makes the driver do this lots of times per frame. {Vulcan | Direct3D 12 | Metal | Mantle} do not.

No, they're not at all obsolete in the 21st Century.

When it comes to graphics programming, at the very low level (i.e. people who are writing the engines, not people who are using the engines), everything is about performance. These people (myself included) absolutely will jump through the hoops of writing 600 lines of setup code if it means I don't end up with half a CPU used up just recompiling shaders and verifying state changes all the time.

Ultimately, this code is written once, by the rendering engine developer, and then used an awful lot, so it being complex code means it's a large up front cost, but a very very low amortised cost. Meanwhile, it's a very very large performance gain.

Uhhh, you realise that it was Valve who wrote the open source Vulcan driver, right?

They're making a shit ton of profit of code they wrote, and happened to be kind enough to open source for you to use.

That, and, if you open source something, you made a conscious decision to allow someone else to use that code, and to make a profit off it. At that point, they have no responsibility to you at all. It was your choice to take your code and open it. It was very nice of you to do that, but you are not buying some kind of "future favours" with it.

Hah, improved productivity from overhearing team conversations? Bullshit. That's the biggest loss of productivity in the world, right there. Everyone ends up spending all their time talking, and not actually doing work.

It's also not even more fun. It's in fact very frustrating to not be able to actually get things done.

How do you know what's typical until you start crashing things into them?

How would you simulate it on a computer when you don't know the internal make up of the asteroid?

I wonder if a cinema owner should be forced to sell tickets to black men.

Oh wait, I don't wonder that at all, because I'm not a bigoted idiot.

Which reactor melt down has killed millions?

I mean, the parent post fails to take into account that when it goes wrong it renders a large area of land uninhabitable, but that's easily dealt with in modern reactor designs.

Right, smart people realise that the real way to get power is to pull the strings on the dumb people

Actually no, several studies have shown that money isn't the primary driver. Instead, once the cash level hits a certain point (basically, comfortable living), how much people enjoy the job dominates salary increases.