Live data from Hacker News

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

theguardian.com

151–160 of 265 posts

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

#151

I just don't buy this. I cut my teeth as a HPC programmer working with C and writing no-lock algorithms. There will always be a need for that, but realistically the vast majority of software being developed is simply not performance-critical. It's designed to work at human speed. Advances in language, compiler, and runtime implementations will continue to keep up with any growth in the need for performant application…

>but realistically the vast majority of software being developed is simply not performance-critical. It's designed to work at human speed.

I learned this by greatly improving a scheduling system algorithm that could schedule 10-12 related (to each other) medical procedures while accounting for 47 dynamic rules (existing appointments, outage blocks, usage blocks, zero patient waiting, procedure split times, etc) to sub second, improving the current algorithm's 13 seconds. You know what? It didn't matter. That was our speed test scenario (most realistically complex one a customer had).

The customer was fine with 13 seconds because it was so much faster than doing it by hand and these customers were paying hundreds of thousands of dollars for the licenses. Because of this, the improved algorithm was never implemented. It was a neat algorithm though.

Absolute maximum performance has its place, it's just not every place.

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

#152
Usually poorly performant code needs optimisation through a change of approach or mindset. It is the way we are thinking about the problem that is lowering performance. Not necessarily the hardware itself.

I've seen locking brought forward as a critical limit. Long discussions about new hardware and adding nodes and all sorts of expenditure required. We need a larger kubernetes. More GPUs!

I've also been in the situation where we switched to a plain redis queue (LPOP, RPUSH) scheme and gotten 10x the improvement just by lowering message overhead. A lot of the very complex solutions require so much processing power overhead simply because they involve wading through gigabytes. Better alternative solutions involve less gigabytes. Same hardware, different mindset. Not even talking about assembly language or other forms of optimisation being required. Just different philosophy and different methodology.

Perhaps we need programmers with the mental flexibility to run experiments and be open to alternatives. (Spoiler: we've already got plenty of these people.)

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

#154
post #121

Earlier quoted context omitted.

What about battery life? If you prefer, call it carbon footprint. Python has a huge carbon footprint. We should get rid of slow languages for environmental reasons.

But then we'd have to pour in more manpower, which involves more commute, more upkeeping (AC, lunch), etc.

Only if you are convinced there is a fundamental need for more manpower for code written in faster languages. For me personally, Crystal was the language that convinced me that great dev UX and productivity is possible in compiled languages. As far as I'm concerned, it even beats Ruby in both. YMMV.

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

#155
post #93

Earlier quoted context omitted.

Some times, there's one feature that's so useful it justifies the lack of many others. Google Docs is a terrible word processor compared to Word or even Pages, but being able to edit a document at the same time as someone else (with full features and little friction—IIRC Pages doesn't support Track Changes while collaborating) is so useful that I end up using Google Docs anyway.

Your comment also showcases how IMO a lot of software companies don't compete on tech. They compete on UX [1]. When I first came on HN and learned about YC's motto (build something users love) this idea was reaffirmed. [1] Google optimizes for a collaborative quick spreadsheet program (handy for consumers), and as other comments say, Microsoft focuses on pro spreadsheet use (e.g. finance).

I won't say that they compete on UX, more that they address different needs from different users groups. Some users need collaboration, others need niche math functions.

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

#156
post #23

The 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…

Thankfully not everyone is getting into Electron bandwagon.

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

#157
post #127

Earlier quoted context omitted.

Plenty of people make Electron apps only aiming to target a single platform it just happens to be so easy to add the others that most do it. The real problem is native platforms suck to code for or have too high a barrier of entry.

It often seems the main target is the web, then Electron steps in to provide an “app”. Slack really comes to mind here.

For that I already have a browser installed.

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

#158
post #93

Earlier 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.

Some times, there's one feature that's so useful it justifies the lack of many others. Google Docs is a terrible word processor compared to Word or even Pages, but being able to edit a document at the same time as someone else (with full features and little friction—IIRC Pages doesn't support Track Changes while collaborating) is so useful that I end up using Google Docs anyway.

We switched from google docs to Dropbox paper. It has one very useful feature which would prevent me from moving back: tracking todos with name and date. Every day I get an email which lists all upcoming todo deadlines across all paper documents. Super convenient way to track your todos.

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

#159
post #121

Earlier quoted context omitted.

What about battery life? If you prefer, call it carbon footprint. Python has a huge carbon footprint. We should get rid of slow languages for environmental reasons.

But then we'd have to pour in more manpower, which involves more commute, more upkeeping (AC, lunch), etc.

Or just stop using python going forward

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

#160

I just don't buy this. I cut my teeth as a HPC programmer working with C and writing no-lock algorithms. There will always be a need for that, but realistically the vast majority of software being developed is simply not performance-critical. It's designed to work at human speed. Advances in language, compiler, and runtime implementations will continue to keep up with any growth in the need for performant application…

I have a few PCs running Windows 10 that are older than 5 years. As long as they have SSDs and you're not gaming, they're still plenty fast, even for modern websites.

I have a macbook that's 8 years old with an ssd and 16gb of RAM. Only struggles with gaming on the integrated graphics, and the battery life has always been abysmal with the thirsty 35w i5 cpu.
Post reply on HN