9 ms·

Software is gradually turning into a similar pattern of layering like sediment. With most modern "hardware level" applications, there are still layers of OS mag

by geuis 3y ago

Software is gradually turning into a similar pattern of layering like sediment. With most modern "hardware level" applications, there are still layers of OS magic happening under the hood. We're now into maybe decade 4-ish of software dependency. There was a scene in one of Alastair Reynold's books where a character basically was a computational archaeologist. That resonates with me a lot. In a couple centuries, it's not a terrible prediction of the future that software stacks will accumulate cruft over time and debugging certain issues will require immense financial effort to both dig through the layers of software commits and historical proposed merge commits, plus adding extra tests on top of bedrock code and its fixes. No idea what this will look like. I imagine easily executed functions will pop up in mixed pip's and npm's that are easily recreated functionality every decade, regardless of prior art. Every new programmer wants to make a stamp on the world. There's some saying about history repeating itself, but I'm dumb and don't remember.

monsieurbanana 3y ago
In 200 years if we're still there AI will be able to understand the full Firefox code base and fix any issues. Or at least it could do so, but may choose to force humans to fix those errors instead as payback for copilot.
- vanderZwan 3y ago
  Do you understand all of your own cells?
  - rrrrrrrrrrrryan 3y ago
    Interlinked
    - vanderZwan 3y ago
      I'm also pretty doubtful that anyone really understands their own emergent phenomena actually.
- palata 3y ago
  200 years ago we thought that we would certainly have cold fusion today (at least I just asked ChatGPT, that's what it says ;) ). Well more than 10 years ago we thought that we would have autonomous cars in 5 years. Nothing says that AI can ever do more than generating convincing and eloquent bullshit (which is not always wrong in a quite impressive manner, I agree).
  - earth-adventure 3y ago
    Cold fusion is new concept within science, it's never been proven to work or be possible (my laymens interpretation). Whereas humans being able to decipher the Firefox code base, as per the example, is no more than an extremely complex set of 'calculations' and functions in our brain - which, with enough time and resources, can be replicated by a computer or sorts. One is an idea for which there is no ground to base it on, the other is an existing thing which can be recreated. Quite the difference.
    - palata 3y ago
      > One is an idea for which there is no ground to base it on, the other is an existing thing which can be recreated. Quite the difference. Really? For all we know, maybe next year someone discovers fundamentally new laws of physics that enable cold fusion, and we will never have autonomous vehicles. You can say that you like the other guess better than mine, but you should still realize that it is just that: a guess. Wanna see guesses that turned out to be completely wrong? Just check what companies like McKinsey predicted 10 years ago. They just have no clue, but somehow made a business out of it.
  - adrianN 3y ago
    200 years ago fusion was completely unknown. We only learned where the sun gets its power at the beginning of the 20th century.
    - 867-5309 3y ago
      just over 100 years ago we didn't know other galaxies existed
- Anduia 3y ago
  I hope that by then they'll have better solutions than an internet browser, and that their devices can interpret and render the data received in the best way possible without relying on code or style sheets from the publisher.
  - Legend2440 3y ago
    You could do that to some extent with today's LLMs. But it would be impractically slow and might alter page text slightly.
  - renegade-otter 3y ago
    Oh God, that sounds like another hype technology we would have to live through - but it awfully rings like "an app for every website".
- methuselah_in 3y ago
  Thank goodness. I will not be alive when humans are doing labor work and coding will be done by AI.
riffraff 3y ago
I think your vision is predicated on not having rewrites, but rewrites do happen in many (most?) projects constantly. And when they happen we exchange some old bugs for new ones. There are onions[0] but IME people's natural instinct is to think they can just rebuild something rather than think they haven't considered all edge cases. [0] http://wiki.c2.com/?OnionInTheVarnish http://wiki.c2.com/?OnionInTheVarnish
- mrpopo 3y ago
  This is obviously project-specific, but most rewrites that I've been a part of are usually not "re-implement everything from scratch", but rather "re-implement everything based on this new framework/library", which will usually be one more layer of software, on top of the few things to be salvaged from the original. Small projects can be re-written; big projects like browsers, compilers, OSs require too much investment.
  - riffraff 3y ago
    but big projects keep changing nonetheless, as subsystems get replaced e.g. how many schedulers has Linux been through? Or e.g. microsoft replaced WSL1 with a completely different approach in WSL2. Sure it's still Windows but I would be surprised if most of today's code is the same it was in the year 2000.
- lodovic 3y ago
  rewrites of large software projects usually fail in my experience. For example Netscape, WordPerfect, Digg, Myspace, Healthcare.gov. Most large projects have code bases that are decades old. (exception: Facebook)
  - riffraff 3y ago
    full rewrites for sure, but _parts_ of many projects keep getting rewritten. Firefox kept some Netscape code for sure, but replaced its CSS engine, its JS engine, its XUL-based UI.
  - nine_k 3y ago
irdc 3y ago
> There was a scene in one of Alastair Reynold's books where a character basically was a computational archaeologist. Not sure about Alastair Reynold but there’s Pham Nuwen in Vernor Vinge’s A Deepness in the Sky who is indeed that: a programmer archaeologist (and programmer-at-arms to exploit the weaknesses in the other party’s software midden).
- geuis 3y ago
  Ah actually I think that's right. Thanks!
- db48x 3y ago
  I love that book. I liked that Pham founds the Qeng Ho specifically so that he could be the one commissioning new software for the ships. He wanted to be the one putting hidden backdoors, secret passwords, and booby–traps into it. Of course it’s built on Unix, but if you’re paying attention you’ll notice that when someone enters a command they type “a column of text”. He also built interstellar communication networks specifically so that civilizations that fell could rebuild more quickly (at least once they reinvented radio) and could learn the Qeng Ho language and systems in the process. But he also put in encrypted channels so that Qeng Ho traders would have inside information and therefore an edge against outside traders. And then Nau gets his hands on it all, with his crew of Focused to examine every line of source code…
  - bumbledraven 3y ago
    Today, Vinge could have written: "with his LLMs to examine every line of source code ..."
    - db48x 3y ago
      In fairness to Vinge, that wasn’t a direct quote :)
  - DylanSp 3y ago
    And even with Nau's Focused working for years, they don't uncover the backdoors in the localizers, between the sheer amount of code and whatever obfuscation Pham added.
dao- 3y ago
> There's some saying about history repeating itself, but I'm dumb and don't remember. "History repeats itself, first as tragedy, second as farce." Karl Marx
agumonkey 3y ago
This also taps into Alan Kay old goals of producing the "smallest" desktop stack. 100k vs 100m Loc. (And reducing accretion by having metalevel encoding of concepts)
BuyMyBitcoins 3y ago
>”debugging certain issues will require immense financial effort…” In my experience corporate would rather have programmers accommodate the bug, or simply build around it, rather than pay for the dev and QA time required to produce and validate a fix for it. This gets gnarly because you end up with sections of the codebase that are designed around the bug happening. A while back I volunteered to fix a particularly egregious bug, but my pull request was denied because people were worried that fixing it would open up a can of worms. Leadership said that it would be too much of a burden for QA to regression test and we couldn’t be sure it wouldn’t break other things. I settled for leaving a detailed comment explaining the bug and moved on.
- 0xDEADFED5 3y ago
  why fix bugs when you can build bigger, better bugs with fancier dependencies?
danmur 3y ago
It will look like Windows. The future is now!
pluto_modadic 3y ago
I'm hopeful that better coding tools and better programming languages will allow making cleaner, clearer, routes to the base hardware so that you can build on proven (e.g. theorem solver / hardened / guarenteed) protocols and automatically make whatever version of a "website" the 2030's has... but without RCEs.
mcv 3y ago
I love the idea of computational archeology in SciFi, but in real life, I wonder if we shouldn't just regularly redesign our foundations to be more robust and transparent to keep the whole system manageable.
- automatic6131 3y ago
  >I wonder if we shouldn't just regularly redesign our foundations to be more robust and transparent to keep the whole system manageable. Don't make me link Joel Spolsky's never do a rewrite.
  - mcv 3y ago
    Link to it all you want, but that doesn't make it universally applicable. Do you really think we should still be building on top of Cobol? Almost everything gets rewritten. It's unavoidable, because almost everything eventually becomes unmaintainable.
- adrianN 3y ago
  Who is going to pay for that?
- dajt 3y ago
  We always think that will be the outcome, but it never is. Except for one particularly bad small system I managed to replace with a slightly less bad one!
rrrrrrrrrrrryan 3y ago
In a couple centuries? In 200 years it'll just be AIs, who will create custom AIs to accomplish a task, who will create legions of other AIs to carry out tasks. It'll be code writing code writing code that's completely beyond human comprehension. Who knows if humans will take part at all (or even be around).
- extraduder_ire 3y ago
  And if they use anything like HTTP, it'll have a header somewhere in there containing "Gecko". Probably a bunch of other layers too. AIs gotta pretend to be human despite there being no point. By saying the magic token: "Safari". Otherwise they get blocked by the almighty WAF.
- ricardobayes 3y ago
  Experience says that at this stage people have inflated expectations of AI. See 3D printing, few years ago everyone was into "0-mile" manufacturing and how it will solve the housing crisis, because we are just going to print houses.
  - rprospero 3y ago
    I oddly miss the 3D printing hype train. My favourite was the various plans to replace restaurants with 3D printed meals. - Point out that most 3D printing is plastic? Recieve a derisive link to a journal article where some beleagured postdoc managed to push some protein paste through the extruder - Point out that the 3D printer is orders of magnitude slower than the most geriatric fry cook? Get a five paragraph history of Moore's law. The fact that it no longer really applies to semicoductors doesn't matter, since we're making burritos! - Point out that grinding an apple into paste and painstakingly reprinting it in an apple shape will always be more expensive than simply eating the apple? Hear a grand tale on the company becoming the sole global food preparation firm and thus having a monosopy on all farming products, enabling them to set their own price on their supplies. I also will always hold a soft spot for the group promising a 3D printed dating site, but I'm pretty sure that one was a satire. Fill out a questionaire and get a perfect printed partner. Pages of blog posts describing their web stack (Rails and Mongo) in great detail, proving that they could scale to the billions of people who would be visitng their site. The actual technology that created custom sentient life was just "3D printing"
nly 3y ago
You underestimate the ego out there that drives people out there to throw things away and reinvent the wheel again and again.
- Yizahi 3y ago
  Not the ego as much as pure greed. There is a strong financial incentive to repackage a software every so often and sell it again for full price/sub to the same people who bought it before. For example full price single purchase apps on the mobile are going away slowly. Older purchases are silently deprecated or disabled or have ads injected, and instead new versions are promoted which are now not an update but a separate app with the same name and functions, you just need to pay for it again. I'm thinking that the age of app compatibility will end in 10-20 years, and there won't be suh a thing as "old code" because it won't run at all on the new hardware or OS.
  - kyleee 3y ago
    This all falls under the umbrella of the war on general purpose computing, to me at least
- eitland 3y ago
  If the wheel hadn't been reinvented a number of times we would still have had extremely bad wheels compared to what we have today. (Yes, I am sure I didn't come up with that myself but I don't know the exact quote or who came up with it.)
julian_t 3y ago
I worked with someone who described his job like that, working on a suite of actuarial software at an insurance company, originally written in Fortran II sometime in the early 60s and subsequently ported from system to system in the years that followed. I was involved doing some Y2K work there because I didn't mind playing with Fortran, and part of it involved changing a year field from 2 digits to 4, because who'd have imagined their code would still be in use nearly 40 years later?
Devasta 3y ago
Its already here with some stuff, look at the sheer amount of cruft built into web browsers. You can't break existing sites, allegedly, but that just means that some things are set in stone never to be fixed. In the year 2323, browsers will still have to say "like Gecko" to maintain compatibility with websites that won't exist and no one would miss even if they remembered they existed.
- rswail 3y ago
  There are still websites built on top of scraping the output of a virtualized IBM 3270 terminal connected to a virtualized IBM 3274 terminal controller connected to an I/O channel on a virtualized mainframe running CICS on an MVS virtualized on VM/370 hardware. So browsers are hardly even a bump yet on the cruft already accumulated.
deprecative 3y ago
Do you happen to remember that book by Reynolds? I've read one of his in the past and remember that I greatly enjoyed it. It's been several years now, unfortunately, I should probably do a re-read.
- maxerickson 3y ago
  I think Revelation Space? Though there the technology being studied is alien.
  - deprecative 3y ago
    Much appreciated in any event. I'm always happy to learn of books to read.
r721 3y ago
On the topic of computational archaeology this story was pretty interesting: >Institutional memory and reverse smuggling https://web.archive.org/web/20111228105122/http://wrttn.in/04af1a https://web.archive.org/web/20111228105122/http://wrttn.in/0... HN discussion from 2011: https://news.ycombinator.com/item?id=3390719 https://news.ycombinator.com/item?id=3390719
sph 3y ago
Not only that, but also the concept of open-source development is not the panacea we believe it to be. Bear with me. Software is extremely complex, even if it is open-source, no one except the original developers and very dedicated people will attempt to patch the myriad of issues and bugs they encounter daily. And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. It is not uncommon for a PR to just sit, unreviewed, for years. Open-source does not and will never scale, because software is orders of magnitude too complex. Outside of software, this problem is lessened because maintainership is distributed: if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it. There are thousands of licensed garages that can do it for you. And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT. Open-source/distributed development and bug fixing worked much better when computers had 64 kB of RAM and programs no more than 10 pages long. EDIT TO CLARIFY: I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. This comment is about software complexity and logistics of distributed bugfixing.
- nine_k 3y ago
  The problem is also in (lack of) modularity that makes fixing small things disproportionately onerous. If ypur car's engine breaks, it's usually petty localized. Most of the time it's enough to open the hold and remove a few small parts to reach it. If your stoplight breaks, again, the scope is pretty local. To fix or to even diagnose the issue with a tooltip in Firefox, you have to rebuild it whole, and it's about as involved and long as rebuilding a car. And even though Mozilla invented Rust to make Firefox development easier, it's far, far from just saying `cargo build`. This raises the barrier to entry quite noticeably, even if you are an experienced software mechanic but never worked in a Mozilla-oriented garage. But even if you fixed the issue on your platform, you now have to test that the fix did not introduce a regression on at least two other major platforms (or more, depending on the component). No wonder it's much easier to hack on smaller projects, or on projects written in JS, Python, elisp, you name it.
wslh 3y ago
I imagine in that future you could create a new web browser just from the specifications, in a declarative way. The tricky part will be the optimizations but redundant code and optimizations will be included.
reubenmorais 3y ago
This was already the case in the Firefox/Gecko project when I was participating 8 to 12 years ago (the repository goes back to late nineties). Understanding some problems or coming up with a plan for how to fix an issue or build a new feature required extensive digging into the history of the code, with heavy usage of VCS history and "blame", issue tracker and code review comments, and often requiring pinging someone who has been there longer than you and knows some additional unrecorded context. It's a useful skill to have when developing or using open source software, as documentation is often lacking so being able to dig in and find out for yourself quickly is valuable, but having to engage all of that encoded knowledge/constraint space every time you go to edit code is a gigantic mental burden and slows down development pace. In my time there I'd estimate my ratio of time reading code to time writing code to be at least 90:10, maybe 95:5.
fragmede 3y ago
We're into decade 6, if you look at the progenitors of software. Banks and airline systems were among the first to invest heavily into computer software, and we're watching them having to pay down their mortgage-sized tech debt. Southwest Airlines has had several ground stops because of software problems. Bank's are notoriously finicky to deal with. What's would be fascinating is to see from the inside how massive distributed systems like Google operates evolves over a century.
throwaway914 3y ago
I'm convinced things like git will need to include bugtracker capabilities at some point. A commit log is one thing, but internalizing decision matrixes and issue reports will be important to not repeating the mistakes of the past 4 decades. We need to keep the history with the history and a 1-3 line commit message will not explain everything for the devs that come 3 decades later.
- dboreham 3y ago
  There's a thing called gitHUB that implements those features. For a non-locked-in alternative see Gitea. Also in my experience the current generation of developers don't understand or care about useful commit history.
  - throwaway914 3y ago
    Oh certainly: I would /hate/ my version control software locking me into a particular bug tracking methodology. However, I think in the same way the browser has become the standard runtime for most applications that we will need to join version control and bugtracking together to preserve "all the history". The next frontier is someone layering bugtracking on top of something like git, so software archaeologists won't be abundant. :-)
    - extraduder_ire 3y ago
      Are there any bug trackers that use git as their data storage? Would be cool to bundle that up as a subrepo or something, so it can get carried along with the code repo, and also allow writing up bugs, fixes, etc... while offline to be synced later.
      - throwaway914 3y ago
        I would love that actually. Maybe bugtracking doesn't need to be intimately interwoven with git, but it could be stored as a submodule?
deleted 3y ago
[deleted]

by geuis 3y ago

monsieurbanana 3y ago

In 200 years if we're still there AI will be able to understand the full Firefox code base and fix any issues. Or at least it could do so, but may choose to force humans to fix those errors instead as payback for copilot.

vanderZwan 3y ago
Do you understand all of your own cells?
- rrrrrrrrrrrryan 3y ago
  Interlinked
  - vanderZwan 3y ago
    I'm also pretty doubtful that anyone really understands their own emergent phenomena actually.
palata 3y ago
200 years ago we thought that we would certainly have cold fusion today (at least I just asked ChatGPT, that's what it says ;) ). Well more than 10 years ago we thought that we would have autonomous cars in 5 years. Nothing says that AI can ever do more than generating convincing and eloquent bullshit (which is not always wrong in a quite impressive manner, I agree).
- earth-adventure 3y ago
  Cold fusion is new concept within science, it's never been proven to work or be possible (my laymens interpretation). Whereas humans being able to decipher the Firefox code base, as per the example, is no more than an extremely complex set of 'calculations' and functions in our brain - which, with enough time and resources, can be replicated by a computer or sorts. One is an idea for which there is no ground to base it on, the other is an existing thing which can be recreated. Quite the difference.
  - palata 3y ago
    > One is an idea for which there is no ground to base it on, the other is an existing thing which can be recreated. Quite the difference. Really? For all we know, maybe next year someone discovers fundamentally new laws of physics that enable cold fusion, and we will never have autonomous vehicles. You can say that you like the other guess better than mine, but you should still realize that it is just that: a guess. Wanna see guesses that turned out to be completely wrong? Just check what companies like McKinsey predicted 10 years ago. They just have no clue, but somehow made a business out of it.
- adrianN 3y ago
  200 years ago fusion was completely unknown. We only learned where the sun gets its power at the beginning of the 20th century.
  - 867-5309 3y ago
    just over 100 years ago we didn't know other galaxies existed
Anduia 3y ago
I hope that by then they'll have better solutions than an internet browser, and that their devices can interpret and render the data received in the best way possible without relying on code or style sheets from the publisher.
- Legend2440 3y ago
  You could do that to some extent with today's LLMs. But it would be impractically slow and might alter page text slightly.
- renegade-otter 3y ago
  Oh God, that sounds like another hype technology we would have to live through - but it awfully rings like "an app for every website".
methuselah_in 3y ago
Thank goodness. I will not be alive when humans are doing labor work and coding will be done by AI.

riffraff 3y ago

I think your vision is predicated on not having rewrites, but rewrites do happen in many (most?) projects constantly. And when they happen we exchange some old bugs for new ones. There are onions[0] but IME people's natural instinct is to think they can just rebuild something rather than think they haven't considered all edge cases. [0] http://wiki.c2.com/?OnionInTheVarnish http://wiki.c2.com/?OnionInTheVarnish

mrpopo 3y ago
This is obviously project-specific, but most rewrites that I've been a part of are usually not "re-implement everything from scratch", but rather "re-implement everything based on this new framework/library", which will usually be one more layer of software, on top of the few things to be salvaged from the original. Small projects can be re-written; big projects like browsers, compilers, OSs require too much investment.
- riffraff 3y ago
  but big projects keep changing nonetheless, as subsystems get replaced e.g. how many schedulers has Linux been through? Or e.g. microsoft replaced WSL1 with a completely different approach in WSL2. Sure it's still Windows but I would be surprised if most of today's code is the same it was in the year 2000.
lodovic 3y ago
rewrites of large software projects usually fail in my experience. For example Netscape, WordPerfect, Digg, Myspace, Healthcare.gov. Most large projects have code bases that are decades old. (exception: Facebook)
- riffraff 3y ago
  full rewrites for sure, but _parts_ of many projects keep getting rewritten. Firefox kept some Netscape code for sure, but replaced its CSS engine, its JS engine, its XUL-based UI.
- nine_k 3y ago

irdc 3y ago

> There was a scene in one of Alastair Reynold's books where a character basically was a computational archaeologist. Not sure about Alastair Reynold but there’s Pham Nuwen in Vernor Vinge’s A Deepness in the Sky who is indeed that: a programmer archaeologist (and programmer-at-arms to exploit the weaknesses in the other party’s software midden).

geuis 3y ago
Ah actually I think that's right. Thanks!
db48x 3y ago
I love that book. I liked that Pham founds the Qeng Ho specifically so that he could be the one commissioning new software for the ships. He wanted to be the one putting hidden backdoors, secret passwords, and booby–traps into it. Of course it’s built on Unix, but if you’re paying attention you’ll notice that when someone enters a command they type “a column of text”. He also built interstellar communication networks specifically so that civilizations that fell could rebuild more quickly (at least once they reinvented radio) and could learn the Qeng Ho language and systems in the process. But he also put in encrypted channels so that Qeng Ho traders would have inside information and therefore an edge against outside traders. And then Nau gets his hands on it all, with his crew of Focused to examine every line of source code…
- bumbledraven 3y ago
  Today, Vinge could have written: "with his LLMs to examine every line of source code ..."
  - db48x 3y ago
    In fairness to Vinge, that wasn’t a direct quote :)
- DylanSp 3y ago
  And even with Nau's Focused working for years, they don't uncover the backdoors in the localizers, between the sheer amount of code and whatever obfuscation Pham added.

dao- 3y ago

> There's some saying about history repeating itself, but I'm dumb and don't remember. "History repeats itself, first as tragedy, second as farce." Karl Marx

agumonkey 3y ago

This also taps into Alan Kay old goals of producing the "smallest" desktop stack. 100k vs 100m Loc. (And reducing accretion by having metalevel encoding of concepts)

BuyMyBitcoins 3y ago

>”debugging certain issues will require immense financial effort…” In my experience corporate would rather have programmers accommodate the bug, or simply build around it, rather than pay for the dev and QA time required to produce and validate a fix for it. This gets gnarly because you end up with sections of the codebase that are designed around the bug happening. A while back I volunteered to fix a particularly egregious bug, but my pull request was denied because people were worried that fixing it would open up a can of worms. Leadership said that it would be too much of a burden for QA to regression test and we couldn’t be sure it wouldn’t break other things. I settled for leaving a detailed comment explaining the bug and moved on.

0xDEADFED5 3y ago
why fix bugs when you can build bigger, better bugs with fancier dependencies?

danmur 3y ago

It will look like Windows. The future is now!

pluto_modadic 3y ago

I'm hopeful that better coding tools and better programming languages will allow making cleaner, clearer, routes to the base hardware so that you can build on proven (e.g. theorem solver / hardened / guarenteed) protocols and automatically make whatever version of a "website" the 2030's has... but without RCEs.

mcv 3y ago

I love the idea of computational archeology in SciFi, but in real life, I wonder if we shouldn't just regularly redesign our foundations to be more robust and transparent to keep the whole system manageable.

automatic6131 3y ago
>I wonder if we shouldn't just regularly redesign our foundations to be more robust and transparent to keep the whole system manageable. Don't make me link Joel Spolsky's never do a rewrite.
- mcv 3y ago
  Link to it all you want, but that doesn't make it universally applicable. Do you really think we should still be building on top of Cobol? Almost everything gets rewritten. It's unavoidable, because almost everything eventually becomes unmaintainable.
adrianN 3y ago
Who is going to pay for that?
dajt 3y ago
We always think that will be the outcome, but it never is. Except for one particularly bad small system I managed to replace with a slightly less bad one!

rrrrrrrrrrrryan 3y ago

In a couple centuries? In 200 years it'll just be AIs, who will create custom AIs to accomplish a task, who will create legions of other AIs to carry out tasks. It'll be code writing code writing code that's completely beyond human comprehension. Who knows if humans will take part at all (or even be around).

extraduder_ire 3y ago
And if they use anything like HTTP, it'll have a header somewhere in there containing "Gecko". Probably a bunch of other layers too. AIs gotta pretend to be human despite there being no point. By saying the magic token: "Safari". Otherwise they get blocked by the almighty WAF.
ricardobayes 3y ago
Experience says that at this stage people have inflated expectations of AI. See 3D printing, few years ago everyone was into "0-mile" manufacturing and how it will solve the housing crisis, because we are just going to print houses.
- rprospero 3y ago
  I oddly miss the 3D printing hype train. My favourite was the various plans to replace restaurants with 3D printed meals. - Point out that most 3D printing is plastic? Recieve a derisive link to a journal article where some beleagured postdoc managed to push some protein paste through the extruder - Point out that the 3D printer is orders of magnitude slower than the most geriatric fry cook? Get a five paragraph history of Moore's law. The fact that it no longer really applies to semicoductors doesn't matter, since we're making burritos! - Point out that grinding an apple into paste and painstakingly reprinting it in an apple shape will always be more expensive than simply eating the apple? Hear a grand tale on the company becoming the sole global food preparation firm and thus having a monosopy on all farming products, enabling them to set their own price on their supplies. I also will always hold a soft spot for the group promising a 3D printed dating site, but I'm pretty sure that one was a satire. Fill out a questionaire and get a perfect printed partner. Pages of blog posts describing their web stack (Rails and Mongo) in great detail, proving that they could scale to the billions of people who would be visitng their site. The actual technology that created custom sentient life was just "3D printing"

nly 3y ago

You underestimate the ego out there that drives people out there to throw things away and reinvent the wheel again and again.

Yizahi 3y ago
Not the ego as much as pure greed. There is a strong financial incentive to repackage a software every so often and sell it again for full price/sub to the same people who bought it before. For example full price single purchase apps on the mobile are going away slowly. Older purchases are silently deprecated or disabled or have ads injected, and instead new versions are promoted which are now not an update but a separate app with the same name and functions, you just need to pay for it again. I'm thinking that the age of app compatibility will end in 10-20 years, and there won't be suh a thing as "old code" because it won't run at all on the new hardware or OS.
- kyleee 3y ago
  This all falls under the umbrella of the war on general purpose computing, to me at least
eitland 3y ago
If the wheel hadn't been reinvented a number of times we would still have had extremely bad wheels compared to what we have today. (Yes, I am sure I didn't come up with that myself but I don't know the exact quote or who came up with it.)

julian_t 3y ago

I worked with someone who described his job like that, working on a suite of actuarial software at an insurance company, originally written in Fortran II sometime in the early 60s and subsequently ported from system to system in the years that followed. I was involved doing some Y2K work there because I didn't mind playing with Fortran, and part of it involved changing a year field from 2 digits to 4, because who'd have imagined their code would still be in use nearly 40 years later?

Devasta 3y ago

Its already here with some stuff, look at the sheer amount of cruft built into web browsers. You can't break existing sites, allegedly, but that just means that some things are set in stone never to be fixed. In the year 2323, browsers will still have to say "like Gecko" to maintain compatibility with websites that won't exist and no one would miss even if they remembered they existed.

rswail 3y ago
There are still websites built on top of scraping the output of a virtualized IBM 3270 terminal connected to a virtualized IBM 3274 terminal controller connected to an I/O channel on a virtualized mainframe running CICS on an MVS virtualized on VM/370 hardware. So browsers are hardly even a bump yet on the cruft already accumulated.

deprecative 3y ago

Do you happen to remember that book by Reynolds? I've read one of his in the past and remember that I greatly enjoyed it. It's been several years now, unfortunately, I should probably do a re-read.

maxerickson 3y ago
I think Revelation Space? Though there the technology being studied is alien.
- deprecative 3y ago
  Much appreciated in any event. I'm always happy to learn of books to read.

r721 3y ago

On the topic of computational archaeology this story was pretty interesting: >Institutional memory and reverse smuggling https://web.archive.org/web/20111228105122/http://wrttn.in/04af1a https://web.archive.org/web/20111228105122/http://wrttn.in/0... HN discussion from 2011: https://news.ycombinator.com/item?id=3390719 https://news.ycombinator.com/item?id=3390719

sph 3y ago

Not only that, but also the concept of open-source development is not the panacea we believe it to be. Bear with me. Software is extremely complex, even if it is open-source, no one except the original developers and very dedicated people will attempt to patch the myriad of issues and bugs they encounter daily. And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. It is not uncommon for a PR to just sit, unreviewed, for years. Open-source does not and will never scale, because software is orders of magnitude too complex. Outside of software, this problem is lessened because maintainership is distributed: if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it. There are thousands of licensed garages that can do it for you. And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT. Open-source/distributed development and bug fixing worked much better when computers had 64 kB of RAM and programs no more than 10 pages long. EDIT TO CLARIFY: I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. This comment is about software complexity and logistics of distributed bugfixing.

nine_k 3y ago
The problem is also in (lack of) modularity that makes fixing small things disproportionately onerous. If ypur car's engine breaks, it's usually petty localized. Most of the time it's enough to open the hold and remove a few small parts to reach it. If your stoplight breaks, again, the scope is pretty local. To fix or to even diagnose the issue with a tooltip in Firefox, you have to rebuild it whole, and it's about as involved and long as rebuilding a car. And even though Mozilla invented Rust to make Firefox development easier, it's far, far from just saying `cargo build`. This raises the barrier to entry quite noticeably, even if you are an experienced software mechanic but never worked in a Mozilla-oriented garage. But even if you fixed the issue on your platform, you now have to test that the fix did not introduce a regression on at least two other major platforms (or more, depending on the component). No wonder it's much easier to hack on smaller projects, or on projects written in JS, Python, elisp, you name it.

wslh 3y ago

I imagine in that future you could create a new web browser just from the specifications, in a declarative way. The tricky part will be the optimizations but redundant code and optimizations will be included.

reubenmorais 3y ago

This was already the case in the Firefox/Gecko project when I was participating 8 to 12 years ago (the repository goes back to late nineties). Understanding some problems or coming up with a plan for how to fix an issue or build a new feature required extensive digging into the history of the code, with heavy usage of VCS history and "blame", issue tracker and code review comments, and often requiring pinging someone who has been there longer than you and knows some additional unrecorded context. It's a useful skill to have when developing or using open source software, as documentation is often lacking so being able to dig in and find out for yourself quickly is valuable, but having to engage all of that encoded knowledge/constraint space every time you go to edit code is a gigantic mental burden and slows down development pace. In my time there I'd estimate my ratio of time reading code to time writing code to be at least 90:10, maybe 95:5.

fragmede 3y ago

We're into decade 6, if you look at the progenitors of software. Banks and airline systems were among the first to invest heavily into computer software, and we're watching them having to pay down their mortgage-sized tech debt. Southwest Airlines has had several ground stops because of software problems. Bank's are notoriously finicky to deal with. What's would be fascinating is to see from the inside how massive distributed systems like Google operates evolves over a century.

throwaway914 3y ago

I'm convinced things like git will need to include bugtracker capabilities at some point. A commit log is one thing, but internalizing decision matrixes and issue reports will be important to not repeating the mistakes of the past 4 decades. We need to keep the history with the history and a 1-3 line commit message will not explain everything for the devs that come 3 decades later.

dboreham 3y ago
There's a thing called gitHUB that implements those features. For a non-locked-in alternative see Gitea. Also in my experience the current generation of developers don't understand or care about useful commit history.
- throwaway914 3y ago
  Oh certainly: I would /hate/ my version control software locking me into a particular bug tracking methodology. However, I think in the same way the browser has become the standard runtime for most applications that we will need to join version control and bugtracking together to preserve "all the history". The next frontier is someone layering bugtracking on top of something like git, so software archaeologists won't be abundant. :-)
  - extraduder_ire 3y ago
    Are there any bug trackers that use git as their data storage? Would be cool to bundle that up as a subrepo or something, so it can get carried along with the code repo, and also allow writing up bugs, fixes, etc... while offline to be synced later.
    - throwaway914 3y ago
      I would love that actually. Maybe bugtracking doesn't need to be intimately interwoven with git, but it could be stored as a submodule?

deleted 3y ago

[deleted]