Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons for software developers from 1970s mainframe programming

hpe.com

Post reply on HN
Print view View original

21–30 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#21

Post by dualogy »

TickleSteve wrote: post #6
yodon wrote: post #3

Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…

software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.

> Efficiency counts, just not in the web world.

Which regrettably by now even end-users are painfully aware of!

Re: Lessons for software developers from 1970s mainframe programming

#22

Post by [deleted] »

yodon wrote: post #18
mahkoh wrote: post #13

Earlier quoted context omitted.

This is actually a problem that will fix itself in time. Soon the customer won't be able to run your quickly shipped product because his computer is not powerful enough to run more than 5 electron apps. If we take a browser, a text editor, and chat software as a given, only two more electron apps will be able to compete for the customer's remaining resources.

At which point the customer blames Microsoft for making Windows too slow. The chain of events between your app and their computer’s speed is sufficiently nebulous in the mind of your customers that it’s impact on your success will objectively be zero. I get that you hate Electron apps, and I understand why, but the reality is Slack and VS Code and others have been wildly successful. You might not use them, but millio…

[deleted]

Re: Lessons for software developers from 1970s mainframe programming

#23

Post by AlanSE »

yodon wrote: post #20
TickleSteve wrote: post #6

Earlier quoted context omitted.

software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.

The parent comment (which I didn’t write) seems to be getting up voted and down voted repeatedly, bouncing in and out of gray. Could one of the downvoters explain your objection? (Genuinely curious, looking to learn)

I don't have the ability to downvote, but I can explain why I might have downvoted.

The comment is repeating a saying, it's not original. I have heard it a ton of times. It's really an entire category of arguments which can be called "premature optimization".

While some optimization is premature, the saying is repeated in a way that is crazy overly-broad. It's based on a false assumption that is only approximately true in some of the cases for web development. The assumption is that bad performance can be traded for more compute power without other negative side effects. This is very untrue for most practical systems in web development. Most compute-heavy decisions will do both things - increase the compute resources you need, and degrade user experience. If you're super tiny working on super simple systems, then there's a certain envelope of request response times where it won't matter if you are faster or slower. So there are some cases where it is a valid argument, but to me, these seem incredibly specific to a certain stage of a startup. Beyond that, what matters is prioritization, not complete disregard for performance concerns.

Re: Lessons for software developers from 1970s mainframe programming

#24

Post by walterbell »

jacquesm wrote: post #14
yodon wrote: post #9

Earlier quoted context omitted.

Well said, but embedded developers already know this and behave as if their compute resources are scarce. I read the author as speaking to developers generally, which I think was his intent.

If web developers would be so kind as to consider my compute resources as scarce that would tremendously please me. This sort of thinking is important, you just need to be selective about when and where you apply it.

Since browser vendors like telemetry, there could be an optional plugin to monitor website consumption of endpoint resources, similar to weather sensors that submit to a central public database. Measure and track the consumption of the top 100 JS scripts globally, to motivate improvement.

Re: Lessons for software developers from 1970s mainframe programming

#25

Post by bandrami »

549362-30499 wrote: post #15
bandrami wrote: post #10

Earlier quoted context omitted.

> The business cares that it can get to market quickly and profitably at minimal cost. And then the successful business, in contrast, actually looks at total cost of ownership.

The point is that cloud computing costs are small compared to labor costs, so it's a waste of time to make a 0.005% cost optimization that takes a week of work. I would also love to see some examples of a 2G (!) library that people are casually importing. Where have you had this problem?

Labor costs are capital expenses; computing cost is an ongoing operational expense.

Re: Lessons for software developers from 1970s mainframe programming

#26

Post by lykr0n »

dualogy wrote: post #21
TickleSteve wrote: post #6

Earlier quoted context omitted.

software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.

> Efficiency counts, just not in the web world. Which regrettably by now even end-users are painfully aware of!

cough javascript cough

Re: Lessons for software developers from 1970s mainframe programming

#27

Post by lykr0n »

549362-30499 wrote: post #4

I really like the point about considering cloud computation costs. It would be great if individual developers could get feedback like, "This patch caused X% CPU cost per request, resulting in Y% monthly cost increase to keep projected usage below alert trigger levels." I also like the note about the headless abstraction, although I think it could gain some strength by talking about AWS Lambda or the actor model. But,…

Java has this built in, sort of. Your application OOM'ed? Here is a heap dump, please tell us what happened and fix it.

Re: Lessons for software developers from 1970s mainframe programming

#28

Post by amorphid »

TickleSteve wrote: post #6
yodon wrote: post #3

Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…

software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.

> Efficiency counts, just not in the web world

Knowing how to code efficiently, even if you choose not to, never goes out of style. I don't think I've ever heard anyone say that out loud.

Re: Lessons for software developers from 1970s mainframe programming

#29

Post by kinkrtyavimoodh »

TickleSteve wrote: post #6
yodon wrote: post #3

Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…

software development != web software development. Processing efficiency is still extremely important in the embedded world. Don't think that the embedded market is small, practically every product you buy has s/w in it. When you make for example a million units of a product, every single byte and every cycle counts as there is a large multiplier to take account of. Efficiency counts, just not in the web world.

And software development != embedded software development either.

Re: Lessons for software developers from 1970s mainframe programming

#30

Post by wslh »

chiph wrote: post #17
yodon wrote: post #3

Interesting article but the author seems trapped in an antiquated “compute time is more expensive than developer time” mindset. For most startups today the EC2 budget is negligible compared to the dev team budget. If you’re successful enough that the compute cost matters that’s a good thing and you can deal with it then. Optimizing for problems you don’t yet have just keeps you from launching and getting successful e…

In a non-startup world (established business), imagine if you went to the boss and said "If you give me 3 or 4 weeks for optimization I believe I can cut our Azure bill by 15%, year over year". You'd get his attention pretty quickly.

Yes, nowadays it is very easy to end up with zillions of VMs (and services) running in the cloud without a little organized plan. In the recent past you should trigger purchase orders to buy hardware. Not saying that the past was better but flexibility has a high price without coordination. Imagine thousands of developers launching new VMs with a single click.
Post reply on HN