> "I think there is a world market for maybe five computers." Thomas Watson, president of IBM, 1943
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.
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.
yes companies used to hire people to just add columns of numbers.
Given all computers in that era are literal super computers of their times, that quote seems to be mostly right even till date.
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.
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).
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.
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.
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.
A.k.a. The problems have become harder (stricter requirements, more ambitious objectives), which is entirely different than the tooling having become worse.
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.
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.
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.
Software development hasn't even gotten a magnitude easier, let alone infinitely. Every improvement has addressed accidental aspects not the essence.
Unfortunately, market pays mostly for CRUDs with various styles of APIs on top.
People have no respect for experience and skills anymore, it's all about the profit and any bootcamp monkey can make money.
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.
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.
only include what you need, and it minifies to zero byes!!