161–170 of 235 posts
Earlier quoted context omitted.
I guess the thing about Fortran, to circle back to your question, is that it isn't common in critical infrastructure.
are accurate weather forecasts not part of society's critical infrastructure?
Earlier quoted context omitted.
I propose that most of the code written in the old days, in COBOL in particular, was not done by computer scientists. There were many lanes for learning COBOL, and they included community colleges and industry training courses. The amount of "computer science / software engineering" concepts that were widely known (or even possible) in those days was very limited. 're-engineering' the code is a valid operation, but t…
This is true. Back in the day, COBOL was marketed to businiess people as an easy to learn code to just get stuff done. Serious programming was done with FORTRAN.
It's a trap. The problem with those old codebases that governments, hospitals, big businesses are struggling with is not really the language, it's the engineering practices of that time with regards to constraints of old technology. The language is not the problem - lack of comments, bad variable naming, bad structure (little or no procedures or readability), and just sheer volume of it, is. It would be very interest…
Not to mention GOTO. If your one of the people who hyperventilates when you see a goto because you learned that it was considered harmful in programmer school then Cobol might not be for you. ;) You might be surprised about the comments though - depending on the age of the codebase. Mainframes were rented back in the day, you paid by resources consumed, terminal time was precious, and mainframes were often turned off…
At night, nearly the whole machine was consumed by batch processing. If there was some problem that required a late-night fix, it was worked out first on green-bar print of the program, using hex to determine what was in the registers. Then the code could be submitted via ICCF, but the wait for a compile could take literally hours. If you mis-typed something (say a forgotten period), the compile would fail and you would have to resubmit the job. Waiting hours again!
It's a trap. The problem with those old codebases that governments, hospitals, big businesses are struggling with is not really the language, it's the engineering practices of that time with regards to constraints of old technology. The language is not the problem - lack of comments, bad variable naming, bad structure (little or no procedures or readability), and just sheer volume of it, is. It would be very interest…
I completely agree. I work with a large APL codebase and the main problem is not the language but the culture. Overly long expressions, one-letter variable names, gotos etc. make the code obfuscated.
Just like in math!
What other languages can we expect to see a similar surge in demand? FORTRAN? In the data analysis space my bet is on SAS
Fortran (standardized without caps for at least the last couple decades) is current to the 2018 release. I haven't come across anybody who cares or is using it. You do eventually see a lot of older code in it in symbolic and algebraic maths in the deeper code bases still because the algorithms are complex and nobody really wants to touch someone else work if it can still be wrapped in something like R or Python and i…
What other languages can we expect to see a similar surge in demand? FORTRAN? In the data analysis space my bet is on SAS
You joke but I still see FORTRAN jobs around where I live than Ruby. I even worked for a consultancy that did a Matlab -> FORTRAN rewrite.
Earlier quoted context omitted.
Your first suggestion might work, but having been there I know obnoxious programmers can be very obstructive, and put up some major barriers to newbies. That said, I think yours is a good solution if it can be afforded. Per your 2nd point about long-term management problems, no doubt of it at all, but sometimes the new (and sometimes good) management simply inherits what previous mismanagement left behind. Also perha…
The other side of the coin is that new hires can be very obstructive. 80% of new hires here are relentless politicians who snitch to management that they are "underappreciated" while making one idiotic suggestion after the next to show their relevance. In reality they cannot do anything, so they scheme to get rid of people who can. During the battle no useful work is being done.
It's a trap. The problem with those old codebases that governments, hospitals, big businesses are struggling with is not really the language, it's the engineering practices of that time with regards to constraints of old technology. The language is not the problem - lack of comments, bad variable naming, bad structure (little or no procedures or readability), and just sheer volume of it, is. It would be very interest…
Absolutely (and I say that as an erstwhile mainframe COBOL programmer). The language itself is dead easy.
I don't want to sound condescending but why can't these systems be rewritten in a modern language? Now is obviously not the right time to do this; I am wondering are there technical limitations to do his?
They’d have to be revalidated. Don’t fix it if it’s not broken. Edit: and when do you upgrade? If they upgraded in ‘85, it would be in C++. ‘95, and it would be Java 1.0. ‘05 and it would have been VB6. None of those would have been substantially better save that they would have been easier to hire maintenance programmers for.
Earlier quoted context omitted.
This is true. Back in the day, COBOL was marketed to businiess people as an easy to learn code to just get stuff done. Serious programming was done with FORTRAN.
still true today. (not really, but there is a lot of f77 out there...)