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

81–89 of 89 posts

Re: Lessons for software developers from 1970s mainframe programming

#81

Post by collyw »

bandrami wrote: 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.

I am usually in favor of imports over writing my own code, but the honest answer depends on a number of other factors. I don't think there is a "best practice" in this area.

Does the imported function do exactly what you need? No not quite - maybe write your own. Is it a complex function that will require a lot of testing? yes - an import is probably best. Are you likely to use other parts of the imported library in the future? Yes, then import may be a better choice. Will it look good on your CV? Lets face it everyone does it.

Re: Lessons for software developers from 1970s mainframe programming

#82

Post by collyw »

kristopolous wrote: post #38
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.…

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…

"the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered"

Interestingly I see a whole world of difference in quality between Python and Perl libraries compared to JavaScript libraries. OK not all Python libraries are perfect and not all JS libraries are shit, but in general the backend stuff seems of a far higher quality.

Re: Lessons for software developers from 1970s mainframe programming

#83

Post by kristopolous »

collyw wrote: post #82
kristopolous wrote: post #38

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…

"the real problem is the demand for programmers is so high and the barrier to entry is so low that the quality has suffered" Interestingly I see a whole world of difference in quality between Python and Perl libraries compared to JavaScript libraries. OK not all Python libraries are perfect and not all JS libraries are shit, but in general the backend stuff seems of a far higher quality.

There's always a "first" language - the first programming language that's learned and taught. It was qbasic in the 90s for instance, then vbasic, java, php for a bit, then ruby - it's certainly javascript now.

The first languages, during their reign as first languages are always derided. When something snatches the crown from JavaScript (it'll happen however inconceivable this is), I'm sure things will settle and it won't be so bad any more.

It's like how at the end of its life, most of the people still using AOL instant messenger were respectable computer experts. Same idea.

Re: Lessons for software developers from 1970s mainframe programming

#84

Post by TimJYoung »

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)

In terms of performance, bad code is bad code. There's nothing about OOP that inherently results in non-performant code. Like all things, one needs to know what they're doing and, more importantly, what their compiler/runtime is doing.

For example, anyone that has been using OO in a non-GC'ed language for a reasonable amount of time will know that it's bad news to constantly create and free small objects due to the MM overhead. However, I constantly encounter JS-heavy web sites/apps that a) become slower as you use them and use an inordinate amount of memory, and b) really thrash the GC because they simply don't pay attention to allocations at all and constantly use constructs that result in one-off allocations that then need to be recycled.

The fact is that the browser and the DOM is a UI layer, and UI frameworks fit perfectly when implemented using OO architecture.

Re: Lessons for software developers from 1970s mainframe programming

#85

Post by rf15 »

klibertp wrote: post #71
rf15 wrote: post #36

Earlier quoted context omitted.

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)

It's not that simple. My impression - I'm not very knowledgeable about this - is that JS and others started getting around as fast (in best conditions and a lot of voodoo) as unmanaged C code, but they are still behind in terms of memory footprint. For embedded applications, where you may be forced to count every KB of memory and every CPU cycle, the JITted systems are simply not a good fit right now. You certainly c…

Your assessment is definitely sufficiently true, although I would argue that, looking at how v8 essentially increases speed down to just twice the time of a comparable C program (as opposed to a magnitude or two) it is worth the convenience it brings to the table for devs (though c++ 11 and later catch up quite a bit)

Re: Lessons for software developers from 1970s mainframe programming

#86

Post by [deleted] »

hprotagonist wrote: post #19
bandrami wrote: 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.

When that library is, e.g., numpy: absolutely. God help you if you think you're better at linear algebra than BLAS or LAPACK is.

[deleted]

Re: Lessons for software developers from 1970s mainframe programming

#87

Post by ggm »

Experientally, learning to code in constrained systems and with constrained tools does (ren)force a lot more pre-checks before execution, because the cost of failure is higher on your process.

A lot of the language around "why functional programming" goes to the same space. Strongly typed, functional solutions expose problems during code development which avoid runtime problems from sloppy thinking.

I also think simpler is good. So, coding discipline which favour simple techniques (within limits, this is not one dimensional) are good. If you have to exploit a very complex mechanism, the old world old school method was to look in the NAG library for a well written solution (presuming numeric problems, which predominated then) -and now, we do much the same: look for a solution in your language compatible runtime library space, which is a well trodden path.

Re: Lessons for software developers from 1970s mainframe programming

#88

Post by criddell »

walshemj wrote: post #78
criddell wrote: post #61

Earlier quoted context omitted.

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.

I don't use my sonny's smart function just use an xbox to feed it.

How can you not use it? IIRC, you have to go through the setup steps for the TV to work.

Even if you aren't actively using it, there are things running in the background that crash. I was watching football yesterday and I kept getting "The Samba Service has Stopped" messages. The only option in the box was OK to acknowledge it. What am I supposed to do with that? It kept coming back so I googled it and found how to disable notifications for that app and that eventually stopped the problem.

I also found the Samba service watches what you watch so that it can target ads better.

Re: Lessons for software developers from 1970s mainframe programming

#89

Post by z3t4 »

pfarnsworth wrote: post #67
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…

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.

With Amazon and Google et.al cloud computing we are back to pay-per-cycle, so at least some of it makes sense, if you are for example deploying millions of CPU's.
Post reply on HN