Earlier quoted context omitted.
> almost 30k$/mo That's like, a couple full-time developers, AIUI? Maybe even less than that. Perhaps the people who say "people are more expensive than hardware" have a point - at least in the Bay Area. Or you can move to the Rust Belt if you'd like a change.
Sure, but my point was that they cut that bill with 20k PER month by giving me 5k one off... They gave me 10k runway to poke around but 5k was enough to fix it; it was simply that bad to start with. The low hanging fruit in most systems I see is really trivial to fix; they just have no one to do it... I bet other people here have seen that before when thrown into an existing project (and I read Spolsky at an impressi…
We’re approaching the limits of computer power – we need new programmers
91–100 of 265 posts
Re: We’re approaching the limits of computer power – we need new programmers
#92Every few years something like this gets written. I remember similar things being written in 2004-2005 before the Core 2 line of processors came out. There is still improvements being made to the current tech or new takes on the current tech that aren't incorporated yet in the current bunch of consumer processors. Also I happen to think that what makes a computer fast is the removal of bottlenecks in the hardware. Yo…
except now it has actually been true for years. clock rates aren't increasing. advances in performance have been only from things that are tricky for developers to efficiently leverage (cache, simd, more cores). We need developers who understand these new low level details as much now as we needed that kind of developer in the past.
Sure it is true. It isn't a tech journo writing a quick piece to get some clicks. I am quite cynical these days.
There hasn't been any competition in the Desktop CPU space for years until 2019.
Also clock rates haven't increased since the mid-2000s (there were 5ghz P4 chips). Clock rates being an indication of speed stopped being a thing back then when I could buy a "slower" clocked Athlon XP chip that was comparable to a P4 with a faster clock.
Also more stuff is getting offloaded from the CPU to custom chips (usually the GPU).
> We need developers who understand these new low level details as much now as we needed that kind of developer in the past.
I suspect that there will get better compiler and languages. I work with .NET stuff and the performance increase from a rewrite to .NET core is ridiculous.
Re: We’re approaching the limits of computer power – we need new programmers
#93Earlier quoted context omitted.
I just realized that this situation hasn't improved much in twenty years. But the problems are really commercial (or maybe "political") not technical. Then there's the ongoing War On Native Apps. I'm no prophet, but I did predict then that the browser would have eaten all the business applications space by now. It was just obvious. Colleagues objected that the web could not match rich native programs.
Well it can't, but it doesn't matter in the way your colleagues thought it would. Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.
Re: We’re approaching the limits of computer power – we need new programmers
#94Earlier quoted context omitted.
Even if the software only needs to respond at a certain speed, scale will quickly make you either pay through the nose for better hardware or optimize the software so that it can respond in a small fraction of the original speed. The trick, as always, is finding balance between paying for hardware and paying developers.
But that is the case now too and in my experience it swung to paying through the nose for hardware in general; as more or less a sidetrack I take on projects where I optimise (mostly online) systems. Example; a few weeks ago a startup asked me to check out their setup as they were spending almost 30k$/mo on AWS. I spent a few days optimising and now they are down to less than 10k$. With some more work it will be a fe…
Re: We’re approaching the limits of computer power – we need new programmers
#95The major problem areas are those where it's economically "best" to do the computationally inefficient thing. The obvious example is the quick-to-build MVP, but many of the bigger problems come from platform conflicts. Because we have at least five different actively uncooperating operating system platforms, it's hard to build portable native apps - so people build electron apps instead. We also use the web browser a…
Don't forget the benefits of portability and the need to hire people as factors contributing to the use of higher level, generally less efficient languages: a few days back I read a description of C as a "hard to find skill these days".
Re: We’re approaching the limits of computer power – we need new programmers
#96Stock photo shows voltage regulator circuitry beneath cpu, most likely SMD capacitors. I wonder if the author thinks these are the parts he is writing about?
Re: We’re approaching the limits of computer power – we need new programmers
#97I remember how well and how fast software worked 20 years ago. Today I have to reboot my telephone to make a call.
Re: We’re approaching the limits of computer power – we need new programmers
#98Re: We’re approaching the limits of computer power – we need new programmers
#99Earlier quoted context omitted.
Well it can't, but it doesn't matter in the way your colleagues thought it would. Excel is a much better product than Google Sheets, but having the better product doesn't mean having the winning product.
I do believe a browser app can do pretty much the same as a native one, but I agree that the important bit is they didn't see the big picture: mostly free tech, no installation, safer, low mantainance, out-of-the-box truly client server, etc. Actually the web now is 100X more beautiful and responsive than at that time. I mean what you can do with an intranet server, not the radioactive media monstrosities. Not really…
Re: We’re approaching the limits of computer power – we need new programmers
#100This is a topic that really interests me, but I couldn't read the article -- either a paywall, ad-wall, or some other reader-hostile blocker incongruent with the foundation of the Internet prevents usability. Ah well. I'll join the conversation regardless. For all the programmers out there -- _how do we do this?_. I came into programming through Matlab and Python in Economics and Data Science. I don't have formal tra…
Honestly? I used to jabber on about this with regards to the still distant future of actual nanotechnology ... we need to find the guys who wrote videogames for arcades in the 1980s and press them for their secrets before so many brilliant tricks will be lost to time. They did so much with so little! My guess is that we will slowly approach this wall and spend a lot of time trying for incremental gains, trying to avo…
1) hardware that doesn't change. One C64 is just like every other C64 out there. You knew what the hardware was and since it doesn't change, you can start exploiting undefined behavior because it will just work [1].
2) The problem domain doesn't change---once a program is done, it's done and any bugs left in are usually not fixed [2]. The problem domain was fixed becuase:
3) The software was limited in scope. When you only have 64K RAM (at best---a lot of machines had less, 48K, 32K, 16K were common sizes) you couldn't have complex software and a lot of what we take for granted these days wasn't possible. A program like Rouge, which originally ran on minicomputers (with way more resources than the 8-bit computers of the 1980s) was still simple compared to what is possible today (it eventually became Net Hack, which wouldn't even run on the minicomputers of the 1980s, and it's still a text based game).
4) The entire program is nothing but optimizations, which make the resulting source code both hard to follow and reuse. There are techniques that no longer make sense (embedding instructions inside instructions to save a byte) or can make the code slower (self-modifying code causing the instruction cache to be flushed) and make it hard to debug.
5) Almost forgot---you're writing everything in assembly. It's not hard, just tedious. That's because at the time, compilers weren't good enough on 8-bit computers, and depending upon the CPU, a high level language might not even be a good match (thinking of C on the 6502---horrible idea).
[1] Of course, except when it doesn't. A game that hits the C64 hard on a PAL based machine may not work properly on a NTSC based machine because the timing is different.
[2] Bug fixes for video games starting happening in the 1990s with the rise of PC gaming. Of course, PCs didn't have fixed hardware.
EDIT: Add point #5.