For more discussion, see http://lambda-the-ultimate.org/node/4424
- Howdy! there's a bug!
- Okie, lookie!
*dig dig dig, stares at line 47*
- Oh my, this horsemanure could not have possibly worked, ever! What kind of damaged wetware wrote this?!
$ git blame
- Oh.https://github.blog/2022-09-20-if-you-dont-make-it-beautiful...
I wonder what future humans will make of it, digging through such a massive amount of good, bad, and terrible code. Much of it probably won't run without serious effort.
This isn't far from the current reality, where critical systems rely on nearly-dead skills like COBOL programming.
In a prior job I had, we developed enterprise software aimed at large corporations. We had to support several old mainframes that don't actually exist anymore outside of museums -- but these companies ran emulators of the mainframes solely to continue to use the software they'd been using for decades. Nobody at those companies even has the source for that software, let alone know how it really works. It just works and they can't justify the expense of reworking their entire system just to get rid of it.
They're highly paid not because they're part of a short supply of COLOB devs, but because they have COBOL experience and the battle scars to know how to solve production issues that those new to Cobol might not know about, but which the old timers saw several times already in their careers and know how to fix
If you start learning Cobol now to cash in on the this market, as a Cobol junior you won't be remotely as valuable as those Cobol graybeards with battle scars, which is why nobody's pivoting to Cobol.
Good COBOL programmers are expensive because they’re rare, and the only way to become a good COBOL programmer is to spend a decent fraction of your education and/or career working with it. That doesn’t happen organically anymore for any significant fraction or junior devs.
You can't replicate years or decades of Cobol project experience to "get good at it", out of thin air by doing some side projects at home. No amount of individual self study can prepare you for industry specific cruft and issues you've never encountered. If it were that accessible, a lot of people would do it.
Right, this is what I meant by "expert COBOL programmers".
Heh - my backup retirement plan :-) Hell, COBOL paid really well during Y2K just add 2 characters to the date field :-P
Also it's frustrating working in such conditions where you have to dig through framework code to get to where it matters. It feels like your time is wasted.
I hate that short story because of how silly it is. I get the point that it's trying to make, but it's packaged in such an absurdly unrealistic way that it loses all impact.
https://scifi.stackexchange.com/questions/209233/short-story...
I think you mean 'especially'.
I think we're already dealing with this. My uncle is in his 60's and maintains old truck shipping software in COBOL. Btw there are job openings in old tech like this, for those that are interested. Happy to provide introductions.
But the basic problem stands, the left-pad issue.
We still deride this choice. Junior engineers without supervision hap-hazardly installing dependencies. But over the course of decades and generations of developers we still "sum to zero", where most software will rely on some number of unknown dependencies.
Say in 2100 an update needs to be issued. You push it through whatever is managing npm dependencies at the time. Meanwhile there is a solar system of dependent devices that need security updates. There could be trillions of dependent devices and any number of of independent intermediary caches that may or may not be recently updated. I can't event imagine what that dependency tree would look like.
In the former case, it's a genuine mystery that can be only solved by very smart people and modern science. In the latter, it's the lack of interest - sure, for $$$ a knowledgeable engineer will take the washing machine apart and figure out the exact defect, but no one is going to pay this, they'll just throw the washing machine away and get a new one.
The historical software knowledge is definitely the latter. It is eminently possible to dig into any part of software and eventually get a full understanding of this part. But most of the time, it's way cheaper and more practical to shrug and ignore the problem, or maybe add yet another layer to compensate.
https://web.archive.org/web/20240127140416/https://www.gulp....
There is a library called `pyasn1`, the author passed away and there are some challenges, such as intimidatingly long error messages that are not easy to interpret, or counter-intuitive behaviour of some of the functions in its API.
Do you have any tips for approaching this with the few resources that are available?
That kind of "nobody knows" is about the complexity of many large interconnected systems, and the deep wells of knowledge, theory, and history in each of the various domains.
I argue it's different from your washing machine type because the domains of computing are vast. Sure, you can dive in and figure some things out when necessary, but you can do that with pencil production too.
If you started today, you might not use graphite, or wood. That's ok for pencils. But it might mean we've forgotten a technique they used for making pencils that's also useful for tiny gear shafts. But we don't use it for gear shafts anymore because somebody invented the Swiss lithoscropy process.
There's the graphite core, the wood handle, the yellow paint, the eraser and the little metal ring holding the eraser.
No one person knows how to find, extract and refine the raw materials, then turn them into those components and put it all together.
I was fortunate to get a computer and electrical engineering education that ran the gamut from making basic organic semiconductor structures in the lab and up the pyramid through logic gates, adders, a custom processor on an FPGA, writing a custom RTOS, patching the Linux kernel, and writing a userspace application.
There are no black boxes anywhere on that stack - someone somewhere knows or knew how it worked - but the last time that some systems engineer could claim comprehensive understanding of the stack was probably no later than the early 80s.
Individually, one can build broad competence, comprehension, and a career at some height in the pyramid, and can have limited comprehension of things directly above and below your zone, but the whole pyramid is superhuman.
This is among my most favorite books and not just because it’s about a long time soldier software developer like myself.
They touch on the fact that computer systems have evolved for so long that nobody really knows most of the code anymore. They just use it and build on top of it.
One particular character has been traveling and in stasis so long that he is probably one of the oldest humans alive. A systems engineer of old. It turns out to be a big advantage to know the workings and vulnerabilities of his time because he can use them in the future when everyone else is building many layers on top of that and have no way of knowing exactly what he's doing.
Vernor had a point, I think.