[emehex]

May I interest you in Jevons paradox:

> In economics, the Jevons paradox occurs when technological progress increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the falling cost of use induces increases in demand enough that resource use is increased, rather than reduced.

Source: https://en.wikipedia.org/wiki/Jevons_paradox

[rachofsunshine]

As a concrete application: software development has gotten infinitely easier in recent decades. Better IDEs, fewer performance constraints, better virutalization, less worries about on-prem deployments, autocomplete, easy version control, you name it. Any given engineer should be orders of magnitude more productive - yet demand has (recent slump aside) only grown.

[visarga]

And computers have become 1 million times better in the last 2-3 decades. Higher frequency, more RAM, more bandwidth, more network peers. And yet we make even more of them.

> "I think there is a world market for maybe five computers." Thomas Watson, president of IBM, 1943

[dghlsakjg]

Which, mythological provenance aside, was a very accurate statement at the time.

In 1943 there were probably only a few governments capable of paying the extreme cost, and having a valid use case, for a "computer" in 1943.

If you asked him what he thought the market was for a device that cost a month's wages, and could connect to anywhere on earth, do infinite math, remember anything perfectly, and entertain the whole household was, he probably would have had a different answer.

[Cheer2171]

Same with the infamous Gates quote. In 1981, 640K really was enough for anyone in the market for a personal computer at the price point of the IBM 5150.

[tromp]

https://www.wired.com/1997/01/did-gates-really-say-640k-is-e...

[hyperman1]

The 8086 was based on a 64K design, with segment registers thrown in to expand it to 1M (and 640K of that 1M was reserved for RAM).

It was already clear then that 64K on its own was not enough, and the segment register twiddling to touch other 64K windows was seriously limiting.

The model was patchy from day 1, and would need serious effort to be future proof. Even if computers with 640K installed were rare, the design limitation of 640K possible RAM was clearly not enough.

[Zenzero]

It only sounds like a silly statement because we kept the name "computer". In terms of what a computer was in 1943? He was probably right.

[bluGill]

In 1943 computers were common companies hired rooms full of them. Visicalc on an apple ii can do in minutes what they did in a day.

yes companies used to hire people to just add columns of numbers.

[klyrs]

Some days, I wish my job was that straightforward...

[hrkucuk]

I think that quote is correct. We have billions of physically separated computers that are all connected. And for the most part, if they are not connected, they are rather useless. So we do indeed have just a few "computers" in the world, whose components are distributed across every individual who uses these few computers.

[kamaal]

> "I think there is a world market for maybe five computers." Thomas Watson, president of IBM, 1943

Given all computers in that era are literal super computers of their times, that quote seems to be mostly right even till date.

[ForHackernews]

https://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_attrib...

[seoulmetro]

That quote means nothing about the future.

[rightbyte]

> software development has gotten infinitely easier in recent decades.

I don't agree here. It was way simpler in the 90s. The programmer experience probably peaked around the transition from TUI:s to win32 where you could do either. Different screen resolutions is probably what made programming gui:s suck. And all the churn of Microsoft and Oracle frameworks didn't help.

Nowadays the overhead of making an app that passes procurement is insurmountable. And consumers seem to not buy apps at full price anymore.

[EasyMark]

Why can’t they just decide on a framework and stick with it, warts and all? My God Microsoft is the worse for this, how many .Net frameworks do they have out? I’m glad I’m “stuck” back the world of “simple” Qt GUI and lower level embedded stuff.

[rachofsunshine]

Design and framework churn is a sort of conspicuous consumption. It's not that, taken literally, your 1997 geocities site has gotten any worse - it's that making something better is so trivial that if you don't make something better you look like an idiot / someone without resources / totally un-self-aware.

[tester756]

Yea, because C++ world is known for having one, sane thing instead of 10 inconsistent.

[johnnyanmac]

I think that's why the Paradox works. Doom was a technological power house in the 90's. Created by 5 people in 15 months.

Techs advanced enough that you could make a facade of doom by yourself over the weekend (game design aside). Game devs can be so incredibly productive. But instead, demand sweeled to insatiable heights, as well as dev teams. Doom 2016 probably had hundreds of staff involved and 4-5 years of dev time.

That's basically what happens when tech aims to be bigger and better instead of how to optimize each dev themselves to be individually more productive and keep the project lean (company structures aren't helping either).

[adventured]

> That's basically what happens when tech aims to be bigger and better instead of how to optimize each dev themselves to be individually more productive and keep the project lean

Comparing Doom 1993 vs 2016 makes no sense in that context. There's no scenario where you make gigantic scale Doom-style game worlds circa 2016 with even 20-30 people, much less 5-10. Art asset creation alone for 2016 requires far more staff than the original Doom. Optimizing each dev wouldn't begin to scratch the surface in terms of what you need to get to Doom 2016 if we're talking a dozen people or less. You'd need extraordinarily advanced AI agents creating for you, and the year would need to be more like ~2040-2050. The tech underlying a game like Doom 2016 is a modest part of the labor scale problem.

[johnnyanmac]

> Optimizing each dev wouldn't begin to scratch the surface in terms of what you need to get to Doom 2016 if we're talking a dozen people or less.

What do you think comes to mind when you hear "optimizing each dev"? My suggestion was for each dev to work wider, not deeper. There'd inevitably be a hit in raw fidelity, but that's part of the point I wanted to make.

Of course, no amount of automation even with AI will make up for millions of hand crafted man hours. But my big discrepancy with modern game dev is: for how much business want so care about costs and skimping on labor, we go far, far past middling returns in order to deliver these AAA games. I'd definitely wager that you could preserve 80% the quality of Doom 2016 with 20% of the staff (and pay that staff better, not just pocket the 3x cost reduction) and it would still look top of the line. Even then I question the middling returns.

There are good and insidious reasons why it's so rare, but I was really hoping these better tooling over time would produce more indie studios able to work at around a AA level of production. 5-10 people making games that really aren't that vast a gap from AAA presentation to the common consumer. Instead that sector is seemingly shrinking. It's a problem I at least want to try and chip away at in my career.

[rachofsunshine]

That's not that development has gotten easier, it's that the bar has gotten far higher. The fact that e.g. responsive UIs and multiple input methods and the like are possible is a consequence of the fact that development is so much easier you can afford to spend resources on such things.

What you're citing is an example of the Jevons paradox, not a counterexample. Development got easier, so demand for (more depth and variety of) development rose.

[entangledqubit]

While I agree that development has gotten more complex (often unnecessarily), compared to the 90s, the sheer number of potential consumers now available seems hard to justify complaining about.

[jaggirs]

Nothing is stopping you from using 30 year old tooling if you think it is better than today's

[acuozzo]

The tools (and environments!) 30 years ago were better suited to solving the problems of 29 years ago than the tools are today in solving the problems of the upcoming year.

Specifically, our target environments distance us too greatly from the problem(s) being solved on the main/"happy" path.

Is there a WYSIWYG GUI builder for WWW/Android/iOS as good as Delphi was for win32 or Interface Builder for NeXTSTEP?

If not, then I have to waste a ton of time working on UI boilerplate code instead of the important & fun stuff.

[jaggirs]

> The tools (and environments!) 30 years ago were better suited to solving the problems of 29 years ago than the tools are today in solving the problems of the upcoming year.

A.k.a. The problems have become harder (stricter requirements, more ambitious objectives), which is entirely different than the tooling having become worse.

[acuozzo]

I didn't state that the tools are worse. It's just that they're not as well-suited to the problems we're solving now than the tools 30 years ago were to the problems we were solving then.

The tools themselves are better in so many ways. They just haven't caught up to what we're trying to do with them. Myself, and others, remember fondly when they had.

[dmitrygr]

> software development has gotten infinitely easier

Writing good software is as hard as it has ever been. IDEs don’t help you with anything that makes proper software difficult. The only thing that has changed is that users have been conditioned to accept shit.

[staunton]

Never let "good" be the enemy of "cheaper and roughly on par with the competition".

[s1mplicissimus]

That's the mantra of this current LLM era

[entropicdrifter]

If you think this is a new perspective on software development, I've got some dotcom bubble stocks to sell you

[DowagerDave]

>> software development has gotten infinitely easier

Software development hasn't even gotten a magnitude easier, let alone infinitely. Every improvement has addressed accidental aspects not the essence.

[fragmede]

by sheer accessibility of computers, programming has gotten easier. Computers used to be these behemoths, now, the usb-c to hdmi adapter I have lying around can do more FLOPS than the computer that took us to the Moon. Maybe not infinitely, but it's sure gotten easier and more accessible.

[codr7]

The barrier to entry has been lowered, and I'm not sure that's such a good thing short term. Software developer used to be a thing, these days it means absolutely nothing.

People have no respect for experience and skills anymore, it's all about the profit and any bootcamp monkey can make money.

[rbanffy]

> Writing good software

Unfortunately, market pays mostly for CRUDs with various styles of APIs on top.

[incrudible]

> Better IDEs

We are now getting to a point where IDEs are as good as the ones we had in the 90s.

> performance constraints

Evened out by higher fidelity and less efficient programming languages and paradigms.

> deployment

More robust, perhaps, but also much more complex.

> version control

An improvement in some respects, a regression in others.

> more productive

Hard constraints make people productive. Being productive is about what not to do, impossibilities make for easy decisions.

[exe34]

in what ways is version control a regression?

[rvense]

Typing on a typewriter is five-six times faster than handwriting. Imagine if we still spent all our time writing! How silly that would be.

[fragmede]

that voice dictation is so commonplace still blows my mind (usually when I get an essay of a text message)

[amy-petrik-214]

As another concrete application, roads:

https://bangaloremirror.indiatimes.com/opinion/others/easyno...

The idea is more lanes on the highway means more traffic means slower (even though you added a lane!). What goes off of this is what's called "Palin's Corrolary", which is to make traffic faster it's best to have fewer lanes. Politicians apply various techniques for this such as perpetual construction or allocating vast swaths of asphalt for bicycles, to make the traffic flow faster.

So it does make sense that in fact slower chips will make AI faster, and punch cards will make software development faster, as the inverse of these proposed trends.

[meiraleal]

Productivity which is cancelled by the procrastination and mental issues social media brought to us all.

[codesnik]

well, it's time for another abstraction layer.

[stackghost]

And another js framework.

[recursive]

At this point, I'd take anything that would displace the react hegemony.

[exe34]

http://vanilla-js.com/

only include what you need, and it minifies to zero byes!!

[binalpatel]

My personal (overly biased view after reading Chip War recently) take is pretty much there, seems like a lot of the same early dynamics of semiconductors are playing out here.

Very large R&D expenditures for the next iterations of the models at the leading edge (the "fabs" of the world), everything downstream getting much cheaper and better with demand increasing as a result.

Like a world where Claude Opus 3.5 is incredibly expensive to train and run, but also results in a Claude Haiku that's on net better than the Opus of the prior generation, occurring every cycle.

[skzv]

One of my favourite economic paradoxes. It changes the way you think about efficiency and consumption.

My colleague introduced me to this idea. He had been studying ways to increase computing efficiency out of concern for the environment. Making programs more efficient would reduce energy consumption, right?

His advisor introduced him to Jevons paradox and he realized such efforts could have the exact opposite effect. So he dropped that research entirely. If you're worried about energy consumption, you need to make energy production more green, not machines more efficient.

Making data centers more efficient will probably cause us to build more data centers and use more power overall, not less.

[01HNNWZ0MV43FF]

Unless it's something with a relatively fixed demand

[SoftTalker]

Sounds like a variant on the "induced demand" theory that people who are opposed to road building always trot out.

[J_Shelby_J]

Well, we’re not going to roll it out.

But it’s not really a theory so much as an established fact that the only way to reduce traffic is to have viable alternatives to driving.

[bluGill]

Only because noboby is willing to pay for all the roads a city needs. Freeways in very rural places are never congested because we outbuilt demand.

Des Moines needs Huston levels of freeway to meet current demand. Which is why nobody is willing to pay for it.

[marcosdumay]

No city has enough space for all the roads everybody need to get everywhere by car. You'd pave the entire city and it would still not be enough.

But, of course, the people saying "better streets would only make people drive more" are stupid. It's just that the people insisting one can do everything by car are also stupid.

[exe34]

> But, of course, the people saying "better streets would only make people drive more" are stupid.

that's right, better streets and more parking area will deter car use.

[bluGill]

The only people saying that are sarcastic. cut it out, it isn't halping anything.

what people want is to do things. They want better streets and more parking because they think it will help them - induced demand proves they are right. If you don't like it then work on a real answer, great transit for example (not the transit for people with 5 DWIs that we are trying to punish - which is what all most people see, no wonder they don't want it.)

[bluGill]

You can go up and down and find plenty of space.

of course that is even more expensive.

[marcosdumay]

Or you invest on something that uses less space for the more fixed routes people do. And let them use cars on the more diverse routes...

[obelos]

If you have ever not gone somewhere because “there's too much traffic” or chosen to go to a store because it has easier parking than an equivalent alternative store, you've experienced the rudiments of induced demand.

[bluGill]

Generally it isn't traffic but it takes too long so you don't even consider it. if we had telleportation I'd have lunch in a Paris café but that would mean 8 hours to get there so I don't consider it.

[entropicdrifter]

We'd still have induced demand even if we had teleportation, the bottleneck would just be the capacity of venues, restaurants, and retail businesses.

You wouldn't consider casually popping into a Paris cafe if the wait was always 4 hours or you had to have a reservation months in advance, which would be the case if travel time was a non-factor for everyone

[threatofrain]

We might end up with less because we realize we already overbuilt and restaurants were depending on local captivity.

[jessriedel]

It is, but in both cases it's not a good reason by itself to reduce investment in supply (roads or GPUs).

[rcxdude]

One is indeed an example of the other

[hangsi]

Interesting to consider GPUs as the coal of the AI revolution.

This is worth it for the mental image of heaping them into a boiler fire by the shovel load alone.

[fragmede]

Mental image? This is the AI revolution.

https://imgur.com/a/ePGD89d

[EasyMark]

This definitely made me laugh after reading endless complaint (well scrolling) threads on the price and unavailability of cheap graphics cards thanks to $coin mining and AI usage. I would love to shovel a few in the fire to produce energy for the next generation of overpowered cards while I play old schools games on my $250 laptop

[EasyMark]

I bring this up all the time with coworkers. When a new generation of processors come out with amazing speed/#of core/power improvements, developers get lazier. I’m all for meaningful improvements, and grudgingly on the side of stuff like electron that allow easy cross platform dev, but please, for the love of God, please quit stacking on garbage features and useless GUI mods, pointless graphics, endless pulling in of huge libraries to do one little thing, etc. I try my best to keep my C++ and Rust dev as small as possible with as few dependencies as possible. If something might take me more than a week to write myself, I’ll give it strong consideration, otherwise I write it myself.