Hacker Newsnew | past | comments | ask | show | jobs | submit | glhaynes's favoriteslogin

> I think the question is: Why are we so inefficient today? It's not about looks either: We are building even uglier buildings. The building I'm living in right now is buzzing with air-conditioning units. It's wasteful and it's also an inferior solution (headaches, dry air, only inside is cool, etc...)

I'd guess because of misguided "separation of concerns" and the ability to externalize the inefficiencies: You can either carefully analyze the surrounding climate and the usage patterns of your building, then hire architects who are able to take those into account and are willing to work with the imposed constraints - or you can have your architects go wild and imagine whatever crazy shape you want and treat climate control as an afterthought: After all, you can just slap on some air-conditioning and be done.

Of course air-conditioning will cause numerous problems: Energy usage, air pollution, additional heating of the outside environment, etc - however as long as energy is cheap, those are not the problems of the owners of the building.


Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.

The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.

I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.


Your question seems rhetorical, but here are my thoughts anyway...

This is the new normal, coinciding with the death of expertise.

The WebKit developers clearly are not working in a vacuum, if one bothers to read the blog post:

> Our proposal has been received positively by our colleagues at other browser engines, GPU vendors, and framework developers.

Not to mention that the WebKit developers are pretty much the forefathers of all modern web tech. So the WebKit developers and their colleagues are the experts. And the expert consensus is the successor to WebGL will be something new, something that can be implemented in DirectX 12+, Metal, and Vulkan.

But all the non-experts have heard of Vulkan, and are armed with the simplistic notion that Vulkan is the "next generation of OpenGL". They erroneously conclude that WebGL's successor must also be a Vulkan based solution.

The non-experts will justify this belief with all manner of ridiculous conspiracy-esque conclusions to reinforce their bias. Like "Apple is trying to force the standard", "Apple wasted their time developing Metal", "Apple is a closed-source walled garden", "Apple is expensive". All of which is is essentially the tech version of "libtard" based arguments.

RIP expertise.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: