Live data from Hacker News

We’re approaching the limits of computer power – we need new programmers

theguardian.com

251–260 of 265 posts

Re: We’re approaching the limits of computer power – we need new programmers

#251

Right now, most organizations (and developers) are focused on developer speed/productivity. As compute resources plateau, some developers will be required to focus on compute efficiency and speed. There will always be a limit to how fast you want your CRUD web app to run vs how much you want to spend on developers, though.

You are correct on the outset. I am simply observing the pendulum being on the one extreme end for a long time now though -- businesses always optimise for minimum time to deliver a new product and then pay very hefty consulting fees to fix the mess that could have been easily avoided in the first place (by making the project's development time 20% longer) -- which I am willing to bet my balls would not have been fatal for the business, in like 90% of the cases.

For things to go well and optimally, the pendulum should never be on the extremes. Sure, you guys are in a hurry. OK. But I must protect my name and your interests and must do a good job as well. Don't make me emulate a bunch of clueless Indians, please. Just go hire them.

Businessmen aren't very good at compromises when it comes to techies. I am still coming to terms with that fact and to this day I cannot explain its origins and reasoning well.

Re: We’re approaching the limits of computer power – we need new programmers

#252
post #6

If you look at the volume of software that needs to be produced, and at the trend to include software in more products, and at the entrepreneurial imperative that risk capital is the most expensive resource, it looks very unlikely that handcrafted machine instructions will play a greater role in the future. Cloud computing and SaaS have extended the deadline for coming up with an answer to "What comes after Moore's L…

I don’t think that handcrafted machine instructions are what is necessary. Even switching from languages like Ruby or JS (Node) to languages like Go or Elixir yields tremendous efficiency improvements. Beyond that, developers being conscientious of what they send over the wire, and being just a bit critical of what the framework or ORM produces also can yield substantial gains. I say this as a “DevOps” guy who is res…

You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out.

Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the request and sending the response; Elixir almost doesn't take CPU resources.

I worked with a lot of languages, Go/JS/Ruby/PHP/Elixir included. Elixir so far has hit the best balance between programmer productivity and DevOps happiness. (Although I can't deny that the single binary outputs of Go and Rust are definitely the ideal pieces to maintain from a sysadmin's perspective.)

Re: We’re approaching the limits of computer power – we need new programmers

#253
post #6

If you look at the volume of software that needs to be produced, and at the trend to include software in more products, and at the entrepreneurial imperative that risk capital is the most expensive resource, it looks very unlikely that handcrafted machine instructions will play a greater role in the future. Cloud computing and SaaS have extended the deadline for coming up with an answer to "What comes after Moore's L…

Although I guess we could consider more performant, but still easy to use, languages to be a form of automation.

Rust, [partially] OCaml and [partially] Elixir come to mind. Elixir is much slower than those two but for the value it brings to the table, is quite fast.

Out of everything I worked with in the last 15 years I'd heartily recommend Rust for uber-performant-yet-mostly-easy-to-use language.

Re: We’re approaching the limits of computer power – we need new programmers

#254

It seems like there might be a pretty straight up tradeoff between difficulty of developing software and quantity of software produced. So the more we attempt to optimize at a lower level, the more time it takes to develop, and the less software someone can make and maintain. So, given that - would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now? The…

> would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now?

Dude, I agree to lose at least 80% of them, most are useless and with bad UX on top of that. Even worse: they are distracting.

At some point hiring the programmers to pour software by the kilogram becomes a visible problem -- when the businessmen wake up to the fact that the amortised cost of a job sloppily done (say, over the course of the next 2 years) is much higher than investing 20-30% more upfront. That's what the article is arguing for, IMO.

Re: We’re approaching the limits of computer power – we need new programmers

#255
post #45

The article read to me like one of those posted every 6-8 months with random thoughts someone had in one morning reminiscing old days with oranges compared to sports cars and complete disregard that, as time marches on, things change, people(customers/users) want more, convenience is prioritized. I'll also reminiscence a bit: back in 2000s, my 266MHz, 64MB, 4.1GB HDD PC would let me install a 2GB full feature third p…

I agree that we the people have the tendency to look with rose-tinted glasses at the past.

However, saying that things are just fine today is not strictly true. You are mostly correct but there's a lot of room for improvement and some ceilings are starting to get hit (people regularly complain that Docker pre-allocates 64GB on their 128GB SSD MacBooks, or that Slack just kills their MacBook Air they only use for messaging during travels). And still nobody seems to care and then people like you come along and say "don't complain, things were actually much worse before".

...Well, duh? Of course they were.

But things aren't that much roses and sunshine as you seem to make them look. Not everybody has ultrabooks or professional workstations. I know like 50 programmers that are quite happy to use MacBook Pros from 2013 to 2015. Those machines are still very adequate today yet it's no fun when Slack and Docker together can take away a very solid chunk of their resources -- for reasons not very well defined (Docker for example could have just preallocated 16GB or even 8GB; make the damn files grow with time, damn it!).

---

TL;DR -- Sure, things weren't that good in the past, yeah. But the situation today is quite far from perfect... and you seem to imply things are fine, which I disagree with.

(BTW: thanks for the nostalgia trip mentioning Legacy of Kain! They'll remain my most favourite games until my death.)

Re: We’re approaching the limits of computer power – we need new programmers

#256
post #180

You don't need "new" programmers. Just dust off some "old" programmers who are now merely 40-50 years old. There's plenty of life still in us, and we can tell a pointer from a hole in the ground.

We are too expensive for them, it seems.

Re: We’re approaching the limits of computer power – we need new programmers

#257

Earlier quoted context omitted.

I don’t think that handcrafted machine instructions are what is necessary. Even switching from languages like Ruby or JS (Node) to languages like Go or Elixir yields tremendous efficiency improvements. Beyond that, developers being conscientious of what they send over the wire, and being just a bit critical of what the framework or ORM produces also can yield substantial gains. I say this as a “DevOps” guy who is res…

You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out. Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the requ…

I was going to say that the more performant language thing was likely to disappoint. As you point out, database access is going to be roughly constant. But Rails -> Go would be an exception.

Re: We’re approaching the limits of computer power – we need new programmers

#258
post #257

Earlier quoted context omitted.

You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out. Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the requ…

I was going to say that the more performant language thing was likely to disappoint. As you point out, database access is going to be roughly constant. But Rails -> Go would be an exception.

Well, yeah. Still, Rails is much slower than Phoenix by the mere fact that its templating and ORM facilities are extremely inefficient.

It's not that Ruby is 100x slower than Elixir (of course it's not). It's just that Rails is so inefficient compared to Phoenix.

Sinatra, Phoenix, Rocket.RS, and a ton of others are specially crafted to stay out of your way and utilise the CPU as less as possible. And yep, as we both agree, in these cases the 3rd party I/O is the bottleneck.

Re: We’re approaching the limits of computer power – we need new programmers

#259

Earlier quoted context omitted.

Electron anecdote : I joked with a coworker that they had left their "out of office" status icon on slack in order to work in peace. Turns out that it was already removed but slack was still displaying it. ⌘ + R (refresh page shortcut) solved it.. Electron might help devs getting something out quickly but all these layers have a cost

Client and server side state sync is a hard problem regardless of whether your app is native. A native app wouldn't automatically handle this.

for some reason pretty much every time I have such an issue, command + r solves it, must be my luck

Re: We’re approaching the limits of computer power – we need new programmers

#260

Earlier quoted context omitted.

I'm doing VR on a 6 year old i7 and it runs perfectly fine. Improvements come almost entirely from updating the gpu

There won't be many GPU upgrades left if the manufacturing processes don't improve. GPUs are much closer to the theoretical performance you can squeeze out of a piece of silicon than CPUs.

I doubt it. My new gpu released in 2019 is 3x as powerful as my 2013 gpu but the new CPUs are mostly only improved in core counts.

Rendering is also an insanly parallelizable task. In the worst case we can always slap 2 of the same gpu on one card and get them to render half the screen or for vr, one gpu per eye.

Post reply on HN