5 ms·

In Vernor Vinge's book A Deepness in the Sky, humanity is spread out around the stars with only subluminal technology. Interstellar ships are very old and mix m

by cptaj 3y ago

In Vernor Vinge's book A Deepness in the Sky, humanity is spread out around the stars with only subluminal technology. Interstellar ships are very old and mix many technologies from different systems and civilizations. 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.

peter_l_downs 3y ago
Vinge definitely got it right. I love the title of "Programmer Archaeologist", it's an extremely good description of what we actually do every day. For more discussion, see http://lambda-the-ultimate.org/node/4424 http://lambda-the-ultimate.org/node/4424
- AlotOfReading 3y ago
  As someone who is separately both a programmer and an archeologist, I love the concept and the books. The real skills aren't always as far apart as you'd think either. I once spent a week deconstructing hardware to figure out what assembly language a project was written in. The assembly was only documented in a TRM in a dusty filing cabinet written before I was born. Once I could read the assembly I could read the source code and work my way up the stack to start answering the actual questions I had.
  - lloeki 3y ago
    The nice thing with software is that everyone gets to be an archaeologist in short order; ~6 months is more than enough... - 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.
    - jonathanlydall 3y ago
      I like to say that git blame is a great tool for working out that the problematic code you’re looking at was in fact written by yourself.
- lioeters 3y ago
  For sure, I imagine "software archaeology" will become a field of its own in the future. It reminds me of GitHub's Arctic Code Vault project, a snapshot of all public repositories as of 2020-02-02, meant to last for at least a thousand years. https://github.blog/2022-09-20-if-you-dont-make-it-beautiful-its-for-sure-doomed-putting-the-vault-in-githubs-arctic-code-vault/ 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.
  - otabdeveloper4 3y ago
    I can't even run a node.js project that was written two years ago.
    - Khaine 3y ago
      That's probably for the best
rvbissell 3y ago
Oh man, 3 more novels to read -- thanks!
- pavel_lishin 3y ago
  For what it's worth, while the first two are set in the same universe, you can read them in either order. The third one is a definite sequel, and imo, the weakest of the three.
smt88 3y ago
> They touch on the fact that computer systems have evolved for so long that nobody really knows most of the code anymore. This isn't far from the current reality, where critical systems rely on nearly-dead skills like COBOL programming.
- JohnFen 3y ago
  Indeed so. The highest-paid devs I personally know earn their living working with old COBOL code. It's highly paid simply because there aren't that many expert COBOL programmers around anymore. 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.
  - deleted 3y ago
    [deleted]
  - FirmwareBurner 3y ago
    >It's highly paid simply because there aren't that many expert COBOL programmers around anymore. 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.
    - DiggyJohnson 3y ago
      I don’t think this is as mutually exclusive as you imply. 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.
oreally 3y ago
Unfortunately knowing humanity and it's gatekeeping mechanisms he'd be near-unemployable. 'Oh you don't have XYZ framework experience? GTFO' 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.
preommr 3y ago
This reminds of Asimov's awful "The Feeling of Power" where in the future mankind has forgotten how to do basic math and someone has rediscovered it to the astonishment of the people in power who now intend to use it to their advantage in war. 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.
- vonjuice 3y ago
  I always considered Asimov to have good ideas but he's a pretty bad writer, specially of female characters.
  - CyberDildonics 3y ago
    specially I think you mean 'especially'.
    - vonjuice 3y ago
      No.
      - CyberDildonics 3y ago
        It's either especially or it doesn't make sense
  - flenserboy 3y ago
    Perhaps "human" would be a better substitution. There's a reason his robots are far more memorable than the other characters he crafted.
    - vonjuice 3y ago
      Yeah but it's more grating on the stories I read with female protagonists.
- 3y ago
geuis 3y ago
Reminds me of a character in one of Alastair Reynolds novels who is a software archaeologist. I think they're in Tau Ceti, but anyway. The character has a specialty in digging through code that's hundreds of years old. 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.
theamk 3y ago
There are two kinds of "nobody knows": "Nobody knows how to make room temperature semiconductors" and "Nobody knows why my washing machine failed" 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.
- fxtentacle 3y ago
  Unless, for example, you invested billions into trains that run on Windows 3.11 and retrofitting all of them with a modern control system is prohibitively expensive. Which means the second type of knowledge becomes as irreplaceable as the first one. https://web.archive.org/web/20240127140416/https://www.gulp.de/gulp2/g/projekte/agentur/C00929028 https://web.archive.org/web/20240127140416/https://www.gulp....
- valleyer 3y ago
  I guess you mean "room-temperature superconductors"; if you don't, I submit you and your laptop can come out of the walk-in freezer now. It'll still work. ;)
- sunsetonsaturn 3y ago
  How would you approach this problem https://github.com/pyasn1/pyasn1/issues/55 https://github.com/pyasn1/pyasn1/issues/55? 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?
- mcdonje 3y ago
  There's also the classic, "Nobody knows how to make a pencil." 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.
javajosh 3y ago
Gregory Benford made a similar statement about technology, where humans are in constant war with AI and often don't know how the tech they use work. IIRC there was a spaceship in Great Sky River[0] that could only be operated by humans because they did the tutorials. (Humanity's lack of knowledge was less a permanent regression and more a side-effect of constantly fighting, and losing, the war against the machines. Hard to study and learn when you're fighting all the time). 0 - https://en.wikipedia.org/wiki/Great_Sky_River_(novel) https://en.wikipedia.org/wiki/Great_Sky_River_(novel)
austin-cheney 3y ago
Yes Pham was considerably among the best talent due to the time spent training and diving deeper into the layers of abstractions while other were in stasis while drifting between the stars. That would later prove to become a superior advantage. This is among my most favorite books and not just because it’s about a long time soldier software developer like myself.
andai 3y ago
It's like physics, right? When you understand the deeper layers of what you're working with, you understand what it's built on it makes you much more powerful.

by cptaj 3y ago

peter_l_downs 3y ago

Vinge definitely got it right. I love the title of "Programmer Archaeologist", it's an extremely good description of what we actually do every day. For more discussion, see http://lambda-the-ultimate.org/node/4424 http://lambda-the-ultimate.org/node/4424

AlotOfReading 3y ago
As someone who is separately both a programmer and an archeologist, I love the concept and the books. The real skills aren't always as far apart as you'd think either. I once spent a week deconstructing hardware to figure out what assembly language a project was written in. The assembly was only documented in a TRM in a dusty filing cabinet written before I was born. Once I could read the assembly I could read the source code and work my way up the stack to start answering the actual questions I had.
- lloeki 3y ago
  The nice thing with software is that everyone gets to be an archaeologist in short order; ~6 months is more than enough... - 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.
  - jonathanlydall 3y ago
    I like to say that git blame is a great tool for working out that the problematic code you’re looking at was in fact written by yourself.
lioeters 3y ago
For sure, I imagine "software archaeology" will become a field of its own in the future. It reminds me of GitHub's Arctic Code Vault project, a snapshot of all public repositories as of 2020-02-02, meant to last for at least a thousand years. https://github.blog/2022-09-20-if-you-dont-make-it-beautiful-its-for-sure-doomed-putting-the-vault-in-githubs-arctic-code-vault/ 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.
- otabdeveloper4 3y ago
  I can't even run a node.js project that was written two years ago.
  - Khaine 3y ago
    That's probably for the best

rvbissell 3y ago

Oh man, 3 more novels to read -- thanks!

pavel_lishin 3y ago
For what it's worth, while the first two are set in the same universe, you can read them in either order. The third one is a definite sequel, and imo, the weakest of the three.

smt88 3y ago

> They touch on the fact that computer systems have evolved for so long that nobody really knows most of the code anymore. This isn't far from the current reality, where critical systems rely on nearly-dead skills like COBOL programming.

JohnFen 3y ago
Indeed so. The highest-paid devs I personally know earn their living working with old COBOL code. It's highly paid simply because there aren't that many expert COBOL programmers around anymore. 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.
- deleted 3y ago
  [deleted]
- FirmwareBurner 3y ago
  >It's highly paid simply because there aren't that many expert COBOL programmers around anymore. 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.
  - DiggyJohnson 3y ago
    I don’t think this is as mutually exclusive as you imply. 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.

oreally 3y ago

Unfortunately knowing humanity and it's gatekeeping mechanisms he'd be near-unemployable. 'Oh you don't have XYZ framework experience? GTFO' 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.

preommr 3y ago

This reminds of Asimov's awful "The Feeling of Power" where in the future mankind has forgotten how to do basic math and someone has rediscovered it to the astonishment of the people in power who now intend to use it to their advantage in war. 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.

vonjuice 3y ago
I always considered Asimov to have good ideas but he's a pretty bad writer, specially of female characters.
- CyberDildonics 3y ago
  specially I think you mean 'especially'.
  - vonjuice 3y ago
    No.
    - CyberDildonics 3y ago
      It's either especially or it doesn't make sense
- flenserboy 3y ago
  Perhaps "human" would be a better substitution. There's a reason his robots are far more memorable than the other characters he crafted.
  - vonjuice 3y ago
    Yeah but it's more grating on the stories I read with female protagonists.
3y ago

geuis 3y ago

Reminds me of a character in one of Alastair Reynolds novels who is a software archaeologist. I think they're in Tau Ceti, but anyway. The character has a specialty in digging through code that's hundreds of years old. 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.

theamk 3y ago

There are two kinds of "nobody knows": "Nobody knows how to make room temperature semiconductors" and "Nobody knows why my washing machine failed" 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.

fxtentacle 3y ago
Unless, for example, you invested billions into trains that run on Windows 3.11 and retrofitting all of them with a modern control system is prohibitively expensive. Which means the second type of knowledge becomes as irreplaceable as the first one. https://web.archive.org/web/20240127140416/https://www.gulp.de/gulp2/g/projekte/agentur/C00929028 https://web.archive.org/web/20240127140416/https://www.gulp....
valleyer 3y ago
I guess you mean "room-temperature superconductors"; if you don't, I submit you and your laptop can come out of the walk-in freezer now. It'll still work. ;)
sunsetonsaturn 3y ago
How would you approach this problem https://github.com/pyasn1/pyasn1/issues/55 https://github.com/pyasn1/pyasn1/issues/55? 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?
mcdonje 3y ago
There's also the classic, "Nobody knows how to make a pencil." 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.

javajosh 3y ago

Gregory Benford made a similar statement about technology, where humans are in constant war with AI and often don't know how the tech they use work. IIRC there was a spaceship in Great Sky River[0] that could only be operated by humans because they did the tutorials. (Humanity's lack of knowledge was less a permanent regression and more a side-effect of constantly fighting, and losing, the war against the machines. Hard to study and learn when you're fighting all the time). 0 - https://en.wikipedia.org/wiki/Great_Sky_River_(novel) https://en.wikipedia.org/wiki/Great_Sky_River_(novel)

austin-cheney 3y ago

Yes Pham was considerably among the best talent due to the time spent training and diving deeper into the layers of abstractions while other were in stasis while drifting between the stars. That would later prove to become a superior advantage. This is among my most favorite books and not just because it’s about a long time soldier software developer like myself.

andai 3y ago

It's like physics, right? When you understand the deeper layers of what you're working with, you understand what it's built on it makes you much more powerful.