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?
Lessons for software developers from 1970s mainframe programming
51–60 of 89 posts
Re: Lessons for software developers from 1970s mainframe programming
#52No. 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…
Re: Lessons for software developers from 1970s mainframe programming
#53Earlier 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)
Re: Lessons for software developers from 1970s mainframe programming
#54Absolutely, 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…
Re: Lessons for software developers from 1970s mainframe programming
#55Unfortunately, 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…
Re: Lessons for software developers from 1970s mainframe programming
#56Re: Lessons for software developers from 1970s mainframe programming
#57Earlier 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.
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
#58Earlier 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.
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
#59Earlier 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.
Re: Lessons for software developers from 1970s mainframe programming
#60No. 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.…
Do you work for Intel ? /s