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

41–50 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#41

Post by fsloth »

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…

I'm guessing the original meme (it's been around a long time) originated from hardware vendors. Of course you want to buy more machines!

I've never seen any detailed case studies to prove it in either way.

Re: Lessons for software developers from 1970s mainframe programming

#42

Post by js8 »

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…

This is an economically rational decision. But it is also a bad one.

It's a good way to build non-scalable applications. Because if you scale the application, then at some point, the computer's time will become more expensive than developer's time. Of course, that cost is economic externality for the development shop, so why should they care?

Edit: I am not sure word "scale" is obvious. There is Google-like scaling, which is we run the software on many machines in house. But there is also Microsoft-like scaling, which is many users run the software. Collectively, they have pay the cost and they have to waste the energy.

Re: Lessons for software developers from 1970s mainframe programming

#43

Post by kabouseng »

AlanSE wrote: post #23
yodon wrote: post #20

Earlier quoted context omitted.

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

"This is very untrue for most practical systems in web development."

And yet the very first sentence in gp's comment:

"software development != web software development"

So gp already qualified his statement is not applicable to web development, and then you criticise his comment with a web development example...

Re: Lessons for software developers from 1970s mainframe programming

#44

Post by joatmon-snoo »

js8 wrote: post #42
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…

This is an economically rational decision. But it is also a bad one. It's a good way to build non-scalable applications. Because if you scale the application, then at some point, the computer's time will become more expensive than developer's time. Of course, that cost is economic externality for the development shop, so why should they care? Edit: I am not sure word "scale" is obvious. There is Google-like scaling,…

You're arguing against a strawman here.

No one's saying "let's do stuff the stupid way!" - they're saying hey, let's focus on getting users before fleshing out the technical details of the what-if-we-actually-make-it scenario. Or, as the classic saying puts it, don't put the cart before the horse.

Re: Lessons for software developers from 1970s mainframe programming

#45

Post by vedloseper »

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.

There's also many multipliers that apply to the web. Every page can be loaded by millions or billions of people, more than once, and usually sharing resources with other tabs. It all adds up quite quickly. It's like saying gum wrappers don't matter, while there's a mountains of garbage growing in the background; maybe not enough people care, but it still matters even though they don't care.

Re: Lessons for software developers from 1970s mainframe programming

#46

Post by hunter23 »

joatmon-snoo wrote: post #44
js8 wrote: post #42

Earlier quoted context omitted.

This is an economically rational decision. But it is also a bad one. It's a good way to build non-scalable applications. Because if you scale the application, then at some point, the computer's time will become more expensive than developer's time. Of course, that cost is economic externality for the development shop, so why should they care? Edit: I am not sure word "scale" is obvious. There is Google-like scaling,…

You're arguing against a strawman here. No one's saying "let's do stuff the stupid way!" - they're saying hey, let's focus on getting users before fleshing out the technical details of the what-if-we-actually-make-it scenario. Or, as the classic saying puts it, don't put the cart before the horse.

Yes exactly! The point is you don't build a scalable app until you have a scalable business idea. The first iterations of a startup are about testing different ideas, not about building sustainable architecture.

Unless you are building a technical work of art, it's all about finding the right product.

Re: Lessons for software developers from 1970s mainframe programming

#47

Post by rbanffy »

joatmon-snoo wrote: post #44
js8 wrote: post #42

Earlier quoted context omitted.

This is an economically rational decision. But it is also a bad one. It's a good way to build non-scalable applications. Because if you scale the application, then at some point, the computer's time will become more expensive than developer's time. Of course, that cost is economic externality for the development shop, so why should they care? Edit: I am not sure word "scale" is obvious. There is Google-like scaling,…

You're arguing against a strawman here. No one's saying "let's do stuff the stupid way!" - they're saying hey, let's focus on getting users before fleshing out the technical details of the what-if-we-actually-make-it scenario. Or, as the classic saying puts it, don't put the cart before the horse.

This is a relatively narrow scenario. Some applications "already made it". I'm helping build an IIoT solution that can process a really ludicrous number of measurements per second. If the code is optimal, we have a pretty positive impact on the company's bottom line. If it's not, we'll become famous for being the first group to unwillingly enter Top500 territory.

Re: Lessons for software developers from 1970s mainframe programming

#48

Post by rbanffy »

hunter23 wrote: post #46
joatmon-snoo wrote: post #44

Earlier quoted context omitted.

You're arguing against a strawman here. No one's saying "let's do stuff the stupid way!" - they're saying hey, let's focus on getting users before fleshing out the technical details of the what-if-we-actually-make-it scenario. Or, as the classic saying puts it, don't put the cart before the horse.

Yes exactly! The point is you don't build a scalable app until you have a scalable business idea. The first iterations of a startup are about testing different ideas, not about building sustainable architecture. Unless you are building a technical work of art, it's all about finding the right product.

Some decisions need to be made early on. You may be fine with MySQL, but you need to think about decoupling different parts of the process and to think about the implications of delays on the interfaces from the start, even if they aren't there.

Most likely you'll never reach Google scale, but, you'll be happy you did that as the application grows more complex and you don't have to test every part of it for each tiny change.

Re: Lessons for software developers from 1970s mainframe programming

#49

Post by rbanffy »

rf15 wrote: post #36
lykr0n wrote: post #26

Earlier quoted context omitted.

cough javascript cough

You can program efficiently in js. Just maybe drop the fat framework that dynamically checks each and every of your assigned variables to update other hidden functions (and maybe the dom) and avoid dragging things through N functions for "encapsulation" reasons and other inefficient OOP principle application. what I want to say is: cough javascript developers cough (for reference: I am a js "fullstack" dev)

cough https://twitter.com/rbanffy/status/950784408482648066/photo/... cough

Re: Lessons for software developers from 1970s mainframe programming

#50

Post by photon-torpedo »

This website fully pegs one CPU core on my laptop (Firefox 57.0.4 on Ubuntu 17.10, with uBlock and Ghostery enabled). Apparently these lessons haven't reached their web design team.

Edit: investigating closer, this even happens with JS disabled, and also in Chrome (with less load though).

Post reply on HN