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

61–70 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#61

Post by criddell »

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.

I don't know if it counts as embedded, but about a month ago we bought a new TV (Sony xbr65x900e) and the built in software is unbelievably bad. Our three year old Roku has better software than this thing.

I wish Sony sold a non-smart version of this TV because other than the software, it's pretty nice.

Re: Lessons for software developers from 1970s mainframe programming

#63

Post by shakna »

photon-torpedo wrote: post #50

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

I'm not seeing anything like that, but you got my interest.

The page is only using 14mb of memory, which is a bit higher than some pages, but it's about 4mb of JS source, and another 4mb of objects held in memory. It isn't desirable, but shouldn't be causing any issues.

And though the page does load fairly quickly for me, a glance over what it does during that load makes me suspect I know your issue: Styles were recalculated more than 75 times, with the repaint happening more than 35 times.

There's also a huge peak in the middle of the JS being executed. The culprit [0] has a tightly packed for-each loop. Three nested for-each, with each one contained a lambda, which contains two or three more lambdas. It's not performant code. That particular script is also 500kb of more of the same kind of code. (Might also point out that the form-handler on that page is an even bigger script.)

So: I'd think it's the repaint from too many styles coming in overriding each other, but it might just be a reliance on a large library, which doesn't seem to be well thought out.

[0] https://www.hpe.com/etc/clientlibs/hpeweb/js/hpe.dll.libs.js

Re: Lessons for software developers from 1970s mainframe programming

#64

Post by user5994461 »

kristopolous wrote: post #57
z3t4 wrote: post #52

Earlier quoted context omitted.

You can't teach new people one by one, but you can write articles and blog posts, then post them here on HN just like this guy did.

it's a skill, not a fact. skills are learned tacitly through experience; such as riding a bicycle. You have to ride to learn. The problem is that everything has changed so much. When I started, compiling took serious time (hours sometimes). So you were much more careful about making mistakes. Compilers also had bugs, as did linkers, debuggers, you had to know how to spot these things and when to question your code an…

Software development is still in its infancy. It will slow down eventually and stabilize.

The last two decades were a madness of inventions, with computing doubling almost every 3 year, new languages and paradigm invented, new tools, the internet, the web, phones, giant displays, small displays with touch. We surely won't get that much change in the next two decades.

Re: Lessons for software developers from 1970s mainframe programming

#65

Post by user5994461 »

pfarnsworth wrote: post #37

No. I disagree with most of this article, and I have ~25 years experience. No, I didn't program mainframes, but I'm tired, as are younger programmers, of even older programmers trying to say that the way they did programming is still "better". The writer isn't entirely wrong, but the simple fact is that software isn't written the same way anymore. Stop trying to force antiquated methods down younger people's throats.…

Facebook doesn't make money by writing working software. They don't lose money when the software doesn't work as intended. It's a terrible example for reliability.

Re: Lessons for software developers from 1970s mainframe programming

#66

Post by falcolas »

scarface74 wrote: post #34
chiph wrote: post #17

Earlier quoted context omitted.

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.

I've made just the opposite argument. If you give me three weeks and a few EC2 instances,I can set up an integration environment that runs some automated test and we can cut the amount we spend on QA by x%.

Small tip from an ex-QAer: Don't worry, once the easy cases are automated, they'll have plenty of work to still do. At least the good ones will. They'll start doing more extreme exploratory testing, setting up combinatorial testing, fuzz testing...

A good QA analyst is like any other good employee - they always have something else they'd like to test.

Re: Lessons for software developers from 1970s mainframe programming

#67

Post by pfarnsworth »

kristopolous wrote: post #57
z3t4 wrote: post #52

Earlier quoted context omitted.

You can't teach new people one by one, but you can write articles and blog posts, then post them here on HN just like this guy did.

it's a skill, not a fact. skills are learned tacitly through experience; such as riding a bicycle. You have to ride to learn. The problem is that everything has changed so much. When I started, compiling took serious time (hours sometimes). So you were much more careful about making mistakes. Compilers also had bugs, as did linkers, debuggers, you had to know how to spot these things and when to question your code an…

What’s the point, though, in learning about a vintage machine? It’s fun for hobbyists but it’s not useful for real life. That’s the point. The industry has changed and old dinosaurs, which I consider myself a part of, have to adapt.

For example I hate dependency injection. I despise it, I think it’s stupid. But my company does this, so I do it. Many other companies are doing it. I adapt or die.

Re: Lessons for software developers from 1970s mainframe programming

#68

Post by pfarnsworth »

user5994461 wrote: post #64
kristopolous wrote: post #57

Earlier quoted context omitted.

it's a skill, not a fact. skills are learned tacitly through experience; such as riding a bicycle. You have to ride to learn. The problem is that everything has changed so much. When I started, compiling took serious time (hours sometimes). So you were much more careful about making mistakes. Compilers also had bugs, as did linkers, debuggers, you had to know how to spot these things and when to question your code an…

Software development is still in its infancy. It will slow down eventually and stabilize. The last two decades were a madness of inventions, with computing doubling almost every 3 year, new languages and paradigm invented, new tools, the internet, the web, phones, giant displays, small displays with touch. We surely won't get that much change in the next two decades.

I believe in the next 2 decades human programmers will be replaced by artificial intelligence.

Re: Lessons for software developers from 1970s mainframe programming

#69

Post by pfarnsworth »

username223 wrote: post #40
pfarnsworth wrote: post #37

No. I disagree with most of this article, and I have ~25 years experience. No, I didn't program mainframes, but I'm tired, as are younger programmers, of even older programmers trying to say that the way they did programming is still "better". The writer isn't entirely wrong, but the simple fact is that software isn't written the same way anymore. Stop trying to force antiquated methods down younger people's throats.…

> On some growth teams, code quality and maintainability don't matter, all that matters is getting customer growth with new features as quickly as possible. Is that inherently wrong? Yes. That "growth team" just added a bunch of inscrutable garbage to your code base, perhaps hoping that someone would clean it up later. Of course no one ever will, since they're too busy "getting customer growth with new features as qu…

My current job is converting a growth project into a sustainable and maintainable service. The code is the worst production code I’ve ever seen in 25 years. I’m shocked it works. Everyone that worked on it was fresh grads and it’s shit code for the most part.

But is it inherently wrong? No. It introduced a new feature quickly, a lot more quickly than I ever could. The code i produce is maintainable and relatively bug free but I couldn’t have gotten it up and running as quickly as these kids did.

Also the business decided this is what they wanted to do. Invest a low amount of money to see if the feature works and then if it does pass it onto more senior programmers that turn it into a real service. If it doesn’t stick then throw it away.

It’s not the best, and I would never employ it but it’s one strategy and works if your care more about growth than efficiency.

Re: Lessons for software developers from 1970s mainframe programming

#70

Post by megaman22 »

pfarnsworth wrote: post #68
user5994461 wrote: post #64

Earlier quoted context omitted.

Software development is still in its infancy. It will slow down eventually and stabilize. The last two decades were a madness of inventions, with computing doubling almost every 3 year, new languages and paradigm invented, new tools, the internet, the web, phones, giant displays, small displays with touch. We surely won't get that much change in the next two decades.

I believe in the next 2 decades human programmers will be replaced by artificial intelligence.

People have been beating this drum as long as I can remember. Nobody wants to have to have those pesky engineers around to actually do the work - they want to drag and drop some components around, provide an incredibly fuzzy description of what it should do, wave their finger in the air, and voila, working software materializes.

This is one of those "Next year, in Jerusalem" ideas that is perpetually 20 years away from reality.

Post reply on HN