Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Level Is the Goal

bvisness.me

Post reply on HN
Print view View original

91–100 of 158 posts

Re: High-Level Is the Goal

#91

Post by chuckadams »

IceDane wrote: post #42
highd wrote: post #22

Earlier quoted context omitted.

I'm fairly confident that the new reddit React implementation can be improved in performance by a factor of 3x to 10x. I would be interested to hear others who have good reason to explain why not. I can certainly imagine React-like systems that are capable of statically determining DOM influence sufficient to make comment-collapsing negligible.

It is blatantly obvious to anyone with just a little bit of experience that the reddit devs barely know what they are doing. This applies to their frontend as well as backend. For some reason, reddit is also the only major social network where downtime is expected. Reddit throwing 500 errors under load happens literally every week.

Reddit also puts the "eventually" in "eventually consistent". Not in the sense of consistency being driven by events, but in the colloquial sense of "someday". The new message indicator will go away ... eventually. Your comment will show up ... eventually.

Re: High-Level Is the Goal

#92

Post by dijit »

torginus wrote: post #89

I feel like the term 'engineering' implies bending the rules of reality to your goal in a way that is both economical and is very good at reaching the stated goal. Like for example if you're an automotive engineer, you can't go ahead and put in the thickest beams made out of the strongest steel on hand, because the resulting car would weigh 20 tons and cost $300k. To add to that, it would probably drive like crap, an…

> I feel like the term 'engineering' implies bending the rules of reality

I'd phrase it differently: Civil engineering is fundamentally about understanding trade-offs within hard constraints. You have materials of known strength, known wear, and known properties (compression vs shear). It's boring by default because the physics don't budge.

A lot of software engineering, web and SaaS development in particular, hasn't had to confront comparable resource limitations. For decades we've had (for practical purposes) an infinitely fast calculator, practically infinite supply of active working data and and infinite amount of them to chain together. So, without constraints people have just run wild.

But here's where it gets interesting from my perspective: when you point out the resulting bloat (200ms to open a Reddit comment), many developers will defend it not as a technical failure but as correct business prioritisation. "User hardware is cheap, developer time is expensive" or "users will upgrade their devices anyway"—essentially externalising the performance cost onto users rather than absorbing it as an engineering constraint.

That's the fundamental difference. An automotive engineer can't build a 20-tonne car and tell customers to buy stronger roads. But we absolutely can ship bloated software and tell users to buy faster computers, more bandwidth, better phones. And for a long time, we've got away with it.

The question is whether that's still sustainable, or whether we're approaching the limits of what users will tolerate.

Re: High-Level Is the Goal

#93

Post by torginus »

dijit wrote: post #92
torginus wrote: post #89

I feel like the term 'engineering' implies bending the rules of reality to your goal in a way that is both economical and is very good at reaching the stated goal. Like for example if you're an automotive engineer, you can't go ahead and put in the thickest beams made out of the strongest steel on hand, because the resulting car would weigh 20 tons and cost $300k. To add to that, it would probably drive like crap, an…

> I feel like the term 'engineering' implies bending the rules of reality I'd phrase it differently: Civil engineering is fundamentally about understanding trade-offs within hard constraints. You have materials of known strength, known wear, and known properties (compression vs shear). It's boring by default because the physics don't budge. A lot of software engineering, web and SaaS development in particular, hasn't…

I think the main issue is lack of competition. If company A makes a 10% worse car that costs 10% more than company B, they very quickly go out of business.

There is no 'Reddit 2' substitute product (or indeed for lots of software), and network effects tend to dominate, so your benchmark is 'is it bad enough so people would rather use nothing than your product', which is a very low bar to clear.

Re: High-Level Is the Goal

#94

Post by skybrian »

torginus wrote: post #89

I feel like the term 'engineering' implies bending the rules of reality to your goal in a way that is both economical and is very good at reaching the stated goal. Like for example if you're an automotive engineer, you can't go ahead and put in the thickest beams made out of the strongest steel on hand, because the resulting car would weigh 20 tons and cost $300k. To add to that, it would probably drive like crap, an…

At the big tech firms, there are engineers looking for software fixes that make tiny efficiency improvements that can save lots of money at scale.

Meanwhile, Google and Apple look for whatever ways they can to improve battery life on their phones.

But for many other developers, this isn’t going to save money or increase sales, so the incentives are more indirect.

Re: High-Level Is the Goal

#95

Post by dijit »

torginus wrote: post #93
dijit wrote: post #92

Earlier quoted context omitted.

> I feel like the term 'engineering' implies bending the rules of reality I'd phrase it differently: Civil engineering is fundamentally about understanding trade-offs within hard constraints. You have materials of known strength, known wear, and known properties (compression vs shear). It's boring by default because the physics don't budge. A lot of software engineering, web and SaaS development in particular, hasn't…

I think the main issue is lack of competition. If company A makes a 10% worse car that costs 10% more than company B, they very quickly go out of business. There is no 'Reddit 2' substitute product (or indeed for lots of software), and network effects tend to dominate, so your benchmark is 'is it bad enough so people would rather use nothing than your product', which is a very low bar to clear.

Spot on. And it's worse than that: you're not choosing between a 10% slower product and a faster alternative, you're choosing between a slow product and losing access to everyone still using it. That's not a market choice, it's a hostage situation.

We can see this works in reverse: developer tools, CLIs, and local apps where network effects don't apply (ripgrep over grep, esbuild over webpack) performance actually matters and gets rewarded. Developers switch because they can switch without losing anything. But Instagram users can't switch to a lighter alternative without abandoning their social graph.

This is why the "developer time is expensive, user hardware is cheap" argument only works in the absence of competition. In genuinely competitive markets, efficient code becomes a competitive advantage worth investing in. The fact that it's "not worth optimising" is itself evidence of market power, not sound economics.

Your automotive analogy actually understates it: imagine if switching to a better car meant your old car's passengers couldn't ride with you anymore, and that's closer to what we're dealing with.

Re: High-Level Is the Goal

#96

Post by torginus »

I think people overestimate the necessity of 'high level' conveniences or the difficulty of writing C/C++ to the metal.

For example, take Dear.IMGUI which is a c++ UI framework with a kind of data binding, which generates vertex buffers which can be directly uploaded to the GPU and rendered.

It supports most of the fancy layout stuff of CSS afaik (flexbox etc), yet its almost as low level as it gets.

The code is also not that much harder to write than React.

Re: High-Level Is the Goal

#97

Post by wat10000 »

dijit wrote: post #92
torginus wrote: post #89

I feel like the term 'engineering' implies bending the rules of reality to your goal in a way that is both economical and is very good at reaching the stated goal. Like for example if you're an automotive engineer, you can't go ahead and put in the thickest beams made out of the strongest steel on hand, because the resulting car would weigh 20 tons and cost $300k. To add to that, it would probably drive like crap, an…

> I feel like the term 'engineering' implies bending the rules of reality I'd phrase it differently: Civil engineering is fundamentally about understanding trade-offs within hard constraints. You have materials of known strength, known wear, and known properties (compression vs shear). It's boring by default because the physics don't budge. A lot of software engineering, web and SaaS development in particular, hasn't…

A major difference is what costs money.

A civil engineer might work on a major bridge that costs a billion dollars to build. An automotive engineer might work on a car that has a cumulative billions of dollars in production costs. An aeronautical engineer might work on a plane with a $100 million price tag.

The engineer’s job there is to save money. Spend a week slimming down part of that bridge and you’ve substantially reduced costs, great! Figure out how to combine three different car parts into one and you’ve saved a couple of dollars on every car you make, well worth it.

Software doesn’t have construction costs. The “engineer” (I have the word in my job title but I hesitate to call us that) builds the whole thing. The operating costs are often cheap. Costs like slow rendering are paid by the customer, not the builder.

In that environment, it’s often not a positive ROI to spend a week making your product more efficient. If the major cost is the “engineers” then your focus is on saving them time. If you can save a week of their time at the cost of making your customers wait 50ms longer for every action, that is where you see your positive ROI.

When software contributes to the cost of a product, you tend to see better software work. Your headphones aren’t running bloated React frameworks because adding more memory and CPU is expensive. But with user-facing software, the people who pay the programmers are usually not the people who pay for the hardware or are impacted by performance.

Re: High-Level Is the Goal

#98

Post by jadenPete »

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript.

You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, as a result, they're becoming very popular. I can pull down some code, run `cargo build`, and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community.

If you want your language/library/framework/layer in the stack to become popular, make the tooling good and make it easy for folks to get their questions answered. Everything else will follow.

Re: High-Level Is the Goal

#99

Post by ahartmetz »

flumpcakes wrote: post #76
teiferer wrote: post #67

> a gigantic manual that lists every property of the system in excruciating detail, which is totally worthless for learning and barely usable as reference. It's the only usable form of reference! I want all the details to be presented in a reference. Where else? > low-level tools are terrible too It seems to me the author is confusing lack of familiarity with lack of existence. There are lots of fantastic tools out t…

> It's the only usable form of reference! I want all the details to be presented in a reference. Where else? I guess it's like a dictionary: it's only useful if you know the word you want to look up, rather than reading through every definition until you find the function/library/ability that you want. I do agree though, when I need to look something up, I do want it in great detail - it just isn't a very good learni…

Language servers with LSP for Rust and C++ are available and, I believe, widely used. At least I use them.

Re: High-Level Is the Goal

#100

Post by Twey »

When you can build down as well as up (https://ngnghm.github.io/blog/2015/08/24/chapter-4-turtling-...) — or, equivalently, do away with the up/down orientation entirely, you can have your cake and eat it too.

And as a bonus if you control both slices of bread it's much easier to change the sandwich filling as well! (Though if the original sandwich-builder wasn't careful you might find some sticky residue left over on your bread… maybe someone should take this metaphor away before I do more damage.)

Post reply on HN