Live data from Hacker News

Lessons for software developers from 1970s mainframe programming

hpe.com

51–60 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#51

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?

In the end, it depends on return on investment. If it is something which will be deployed on running for years, it may worth the effort.

Re: Lessons for software developers from 1970s mainframe programming

#52

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

I did do mainframe programming and I do webapps and phone apps these days, so I've kept up. It's gotta be both approaches (yours and the articles) but the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered; the quality of the libraries, build systems, documentation, designs, interfaces, all of it. You can't magically drag all modern programmers throu…

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.

Re: Lessons for software developers from 1970s mainframe programming

#53
post #36
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)

Back in the day some devs said JavaScript devs weren't real programmers but script kiddies. I wonder how much of this came from wanting legitimacy? They were like, ok let's see how Java devs do it. Next thing you know the JS devs are also using 75 layers of abstraction.

Re: Lessons for software developers from 1970s mainframe programming

#54
post #33

Absolutely, 100%, should you optimise for your resources. In a lot of scenarios those resources aren't CPU, HD, memory and bandwidth, instead they are developers time. But certainly if computer hardware becomes more of a bottleneck (cost, time, etc) than man power, then optimising for hardware makes sense. Like most things in life, it isn't binary, and I believe most developers already embrace this, making compromise…

I don't see user time being mentioned. If your app is user facing then optimize for user time.

Re: Lessons for software developers from 1970s mainframe programming

#55
post #5
post #2

Unfortunately, the "best practice" of today says it's better to import a 2 Gb library than write a function, given the choice.

Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. The craftsman cares they can accomplish the task without needing a large library. The business cares that it can get to market quickly and profitably at minimal cost. “I prefer your competitor because their code was lovingly hand crafted inste…

It's not about developer time. Get over yourselves. It is about how long the user has to wait for a page to load or a compute to finish.

Re: Lessons for software developers from 1970s mainframe programming

#57
post #52

Earlier quoted context omitted.

I did do mainframe programming and I do webapps and phone apps these days, so I've kept up. It's gotta be both approaches (yours and the articles) but the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered; the quality of the libraries, build systems, documentation, designs, interfaces, all of it. You can't magically drag all modern programmers throu…

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 and when to question your tools.

Operating system containment and protection was more an intention than a reality and it was relatively easy to lock up or crash a machine through faulty code. Workstation uptimes of weeks was seen as impressive. These days, things are so stable that "uptime" just tells me when my last power outage was.

When we released software it was on physical media, which was either mailed to people in physical boxes or running on physical machines that were shipped out. Not making mistakes was much more important in that situation since you couldn't just deploy an update without a lot of cost and ceremony.

It's all changed so fundamentally; I'd be open to having an instruction course where people have to target some vintage machine (which we'd likely have to virtualize) and have them just deal with it for 6 months. I don't know how many signups you'd get though.

Re: Lessons for software developers from 1970s mainframe programming

#58

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 ideas can't scale.

Ex: If your building a game with N players that can see each other walking around then that's N^2 updates.

Now, plenty of ways of dealing with that problem, but it's something to keep in mind even if you solution is not yet worth implementing.

Re: Lessons for software developers from 1970s mainframe programming

#59
post #5

Earlier quoted context omitted.

Yes, because the primary cost to the company is the cost of developer time, not the download bandwidth cost or the power cost for increased utilization level of the user’s CPU. The craftsman cares they can accomplish the task without needing a large library. The business cares that it can get to market quickly and profitably at minimal cost. “I prefer your competitor because their code was lovingly hand crafted inste…

It's not about developer time. Get over yourselves. It is about how long the user has to wait for a page to load or a compute to finish.

And for that matter, it can take as long to select the library and learn the API as it would have to write the function to begin with.

Re: Lessons for software developers from 1970s mainframe programming

#60

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

Do you work for Intel ? /s

Post reply on HN