This whole circumstance just reminds me of COBOL. Nowadays you have scant few programmers for it, but the ones who do demand a big salary because it’s such old specialized technology and often they have decades of experience in it. There’s simply less COBOL programmers than there were in the languages heyday, and the ones trying to enter that market nowadays have a huge learning curve ahead of them.
The only reason most of these places that do that though, is because they wrote in COBOL to begin with decades ago, and didn’t want to switch away to something more modern as other languages gained functionality and popularity.
I doubt C is ever going to go the way that COBOL has, it’s too ubiquitous, but it does make one consider the language you write in and how compatible it may be not just with what exists today but what’s going to exist years from the creation of that code.
The only reason most of these places that do that though, is because they wrote in COBOL to begin with decades ago, and didn’t want to switch away to something more modern as other languages gained functionality and popularity.
And it would’ve been much cheaper to rewrite once some years ago than to keep paying people to maintain it.
And in many cases, rewriting something improves the code substantially by finding bugs and fixing architectural issues. Old code doesn’t mean it’s correct, it’s just old, and just today we had a high severity bug from code that was never properly tested and sat unchanged since near the start of the project.
I think that many a time people begin a project coding in a far-far-far too-low level programming-language: they’re solving the wrong problem!
Build your prototype in a high level language, get the model/architecture correct … and THEN begin replacing the slow bits with faster languages…
To me that seems right.
Haskell to begin-with, & when it solves ALL of the problem, correctly … THEN you begin converting stuff to Crab-lang/Rust…
When you’re still bashing 'round, trying to discover the form of the underlying problems in your problem … that’s the wrong time to be doing low-level stuff, to my eyes…
I get the sentiment, but I think Rust does a pretty decent job even in the prototyping phase. I’ll run snippets in Python or Lua, but that’s mostly for data mangling, like generating code from a data format or preparing test data.
This whole circumstance just reminds me of COBOL. Nowadays you have scant few programmers for it, but the ones who do demand a big salary because it’s such old specialized technology and often they have decades of experience in it. There’s simply less COBOL programmers than there were in the languages heyday, and the ones trying to enter that market nowadays have a huge learning curve ahead of them.
The only reason most of these places that do that though, is because they wrote in COBOL to begin with decades ago, and didn’t want to switch away to something more modern as other languages gained functionality and popularity.
I doubt C is ever going to go the way that COBOL has, it’s too ubiquitous, but it does make one consider the language you write in and how compatible it may be not just with what exists today but what’s going to exist years from the creation of that code.
And it would’ve been much cheaper to rewrite once some years ago than to keep paying people to maintain it.
And in many cases, rewriting something improves the code substantially by finding bugs and fixing architectural issues. Old code doesn’t mean it’s correct, it’s just old, and just today we had a high severity bug from code that was never properly tested and sat unchanged since near the start of the project.
I think that many a time people begin a project coding in a far-far-far too-low level programming-language: they’re solving the wrong problem!
Build your prototype in a high level language, get the model/architecture correct … and THEN begin replacing the slow bits with faster languages…
To me that seems right.
Haskell to begin-with, & when it solves ALL of the problem, correctly … THEN you begin converting stuff to Crab-lang/Rust…
When you’re still bashing 'round, trying to discover the form of the underlying problems in your problem … that’s the wrong time to be doing low-level stuff, to my eyes…
_ /\ _
I get the sentiment, but I think Rust does a pretty decent job even in the prototyping phase. I’ll run snippets in Python or Lua, but that’s mostly for data mangling, like generating code from a data format or preparing test data.
So far it works pretty well.