8 ms·

Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic i

Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update. Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on. It's like asking why a person can't be just done learning so they can live their life. Well, they can, but pretty soon the world is inaccessible to them. They can't use a computer or a phone because they stopped learning in 1995 and they're utterly dependant on others to do things for them. But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.

estaseuropano 5y ago
No building stands for 100 years without maintenance. 100 years ago heating and light by coal or gas were still common, so every single old building has had upgrades to electricity (or first gas, then electric). The roof leaked, the wood rotted, a bunch of people died in a fire and now all buildings in a similar style need to add a fire escape...
- titzer 5y ago
  There are hundreds of churches in Europe who have stood for centuries without the "maintenance" you are talking about. You are talking about upgrades, not maintenance. Adding gas and electricity are modern (< 150 years ago) things, as are earthquake codes, fire escapes, etc. I'm not suggesting people go live in cathedrals, but there's a huge hole in your reasoning.
  - lexicality 5y ago
    Every old church I've ever been in has had some kind of donation drive on the notice board asking for help replacing missing tiles, rotting roof beams etc. I don't know if the British were just exceptionally bad church builders and contemporary European churches are doing just fine but I would hazard a guess that no, they also require spectacularly large amounts of maintenance to keep the weather out too.
    - TeMPOraL 5y ago
      True, but this is preventing a kind of decay that software is, by its digital nature, immune to. Information doesn't weather or rot. There's no software equivalent to "missing tiles" or "rotting roof beams".
      - et1337 5y ago
        “Link rot” and “bit rot” are terms that have entered our common vocabulary. I think information gets weathered down by contact with humans, who are an incredible source of entropy.
    - titzer 5y ago
      Yes, this kind of upkeep is definitely required. Replacing little things as they break and keeping an eye out for issues. Old things require this upkeep, which is a different thing from rebuilding, replacing, or upgrading. But the goal of upkeep is to keep the thing in good shape, and usually without any visible change at all, rather than transforming it into something different (assumedly better, but not really). Upkeep is preservation, conservation. We've somehow forgotten how to do that for the vast majority of things.
    - jart 5y ago
      Then consider NASA Voyager. It's been floating around the galaxy for 44 years. If all goes well, its onboard computer won't run out of power until October 10, 2166.
  - stefanfisk 5y ago
brian_cloutier 5y ago
> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. Believe it or not this is a core design goal of the Urbit ecosystem. The core bytecode should be simple (and stable) enough that some future archaeologist can implement an interpreter in a weekend and run programs. They take it so far that their version numbers run _backwards_, with the idea that once they reach version 0 nothing will ever change again: https://urbit.org/blog/toward-a-frozen-operating-system https://urbit.org/blog/toward-a-frozen-operating-system
strangetortoise 5y ago
> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least? Linux is famous for "we do not break user space" (yes, I know it's not 100% true, but it's closer than anything else I've seen), and afaik the posix standards are pretty stable too. The C language also has a stable ABI, which is basically the ffi for most languages, and most static libraries that were developed decades ago can link just fine. In my mind, the problem is caused by at least two things: - Languages that are not compiled to machine code have no incentive to have a stable API or ABI. This has the effect that code reuse now necessitates replicating the state of the machine it was developed on (Which might be using a different language version, runtime, etc). - Programming culture has progressed to a "get it done quickly, just grab a library" culture. This is not to say you should develop everything in-house, but on a spectrum, I have the hunch that this easy accumulation of dependencies induces a culture that does not vet the stability of the dependencies. Once one of your dependencies is unstable, the project on which it depends cannot be stable.
- moonbug 5y ago
  > a programming language and OS that does its best to not change you've heard of this thing called Windows?
  - Jensson 5y ago
    Since when do windows break most programs every few months? Having to write a patch every few years when Microsoft releases a new OS is pretty low maintenance. And most of the time windows is backwards compatible nowadays, so usually you don't even need to do that. Most 10 year old games still runs on modern windows even without patches etc.
  - selcuka 5y ago
    Yes. Windows is extremely backwards compatible. This could be, ironically, one of the reasons some people don't like it too much. See Raymond Chen's The Old New Thing [1] for some technical details. [1] http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...
prox 5y ago
We perhaps need a LongNow Smartphone.
jcelerier 5y ago
> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free. you can fire up QBasic on dosbox just fine
- 3pt14159 5y ago
  The last update to MS-Dos was over twenty years ago. I'm longing for something more than mere backwards compatibility.
  - gmfawcett 5y ago
    So you want "there should at least be a programming language and OS that does its best to not change", and you also want updates for it?
  - jcelerier 5y ago
    FreeDOS is regularly updated
sagichmal 5y ago
> Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update. You only need to update dependencies that interact with things that change autonomously. For the types of programs I write, that describes very few, sometimes none, of my dependencies. Continuous updating of dependencies is valuable in some circumstances. Not all.
FpUser 5y ago
>"Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on." I have 17 years old Windows desktop product that I've long abandoned. But it is exactly this: single exe with everything compiled in. It uses DirectX 9 and Directshow. It still runs fine without any tweaking. It even compiles fine from source code. So from a practical standpoint it is maintenance free.
cxr 5y ago
> there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time A passable implementation of Lorie's UVC concept[1] is sitting right in our lap, it's just hardly ever put to use in this way, and it's considered by some not to be very sexy—or rather, it's popular to dump on it for various reasons. But you're probably using it right now to read this comment, and the reason is that its availability and reliability is a foregone conclusion by every stakeholder in this conversation—whether that be me, you, or our hosts involving Y Combinator &co. And with respect to the article, it's a foregone conclusion that it will also be involved in the tech tree of the example projects given. Jeff even mentions its longevity explicitly—in a comparison to Python, where Python is considered the worse of the two. How about just not depending on Python at all? If you click through to Jeff's "makerss.py" script and look at the kinds of machinations that it does, consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root. No implicit[2] assumptions about what software is installed on the machine in question—since it's using the UVC after all—and none of the Python 2/Python 3 fuss. (It'd have to forego the symlinking that makerss.py does near the end (currently line 1717 and 1719), but that should arguably already be handled elsewhere, anyway.) 1. https://news.ycombinator.com/item?id=11512892 https://news.ycombinator.com/item?id=11512892 2. https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033
- jefftk 5y ago
  > consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root I'm not sure what you mean?
  - cxr 5y ago
    From <https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936>: > If folks were really committed to improving the developer experience, then instead of what we do now [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html If this is still unclear, please let me know. (Please also let me know if it is clear. I'm very interested getting this explanation "right", so it's easy to understand.)
closeparen 5y ago
Software would be incredibly "low upkeep" to last as long as HTTP. You don't have to use a new programming language just because it exists. Time zone info is a data file managed by the OS and has no business being baked into specific programs. Translations are likewise data files and should be modular so that you can add or replace them without invalidating the program. Sensors change much slower than software; the oldest and crustiest operating system image you'll ever meet is the one coupled to a multi-million-dollar sensor in a lab or a hospital.

estaseuropano 5y ago

No building stands for 100 years without maintenance. 100 years ago heating and light by coal or gas were still common, so every single old building has had upgrades to electricity (or first gas, then electric). The roof leaked, the wood rotted, a bunch of people died in a fire and now all buildings in a similar style need to add a fire escape...

titzer 5y ago
There are hundreds of churches in Europe who have stood for centuries without the "maintenance" you are talking about. You are talking about upgrades, not maintenance. Adding gas and electricity are modern (< 150 years ago) things, as are earthquake codes, fire escapes, etc. I'm not suggesting people go live in cathedrals, but there's a huge hole in your reasoning.
- lexicality 5y ago
  Every old church I've ever been in has had some kind of donation drive on the notice board asking for help replacing missing tiles, rotting roof beams etc. I don't know if the British were just exceptionally bad church builders and contemporary European churches are doing just fine but I would hazard a guess that no, they also require spectacularly large amounts of maintenance to keep the weather out too.
  - TeMPOraL 5y ago
    True, but this is preventing a kind of decay that software is, by its digital nature, immune to. Information doesn't weather or rot. There's no software equivalent to "missing tiles" or "rotting roof beams".
    - et1337 5y ago
      “Link rot” and “bit rot” are terms that have entered our common vocabulary. I think information gets weathered down by contact with humans, who are an incredible source of entropy.
  - titzer 5y ago
    Yes, this kind of upkeep is definitely required. Replacing little things as they break and keeping an eye out for issues. Old things require this upkeep, which is a different thing from rebuilding, replacing, or upgrading. But the goal of upkeep is to keep the thing in good shape, and usually without any visible change at all, rather than transforming it into something different (assumedly better, but not really). Upkeep is preservation, conservation. We've somehow forgotten how to do that for the vast majority of things.
  - jart 5y ago
    Then consider NASA Voyager. It's been floating around the galaxy for 44 years. If all goes well, its onboard computer won't run out of power until October 10, 2166.
- stefanfisk 5y ago

brian_cloutier 5y ago

> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. Believe it or not this is a core design goal of the Urbit ecosystem. The core bytecode should be simple (and stable) enough that some future archaeologist can implement an interpreter in a weekend and run programs. They take it so far that their version numbers run _backwards_, with the idea that once they reach version 0 nothing will ever change again: https://urbit.org/blog/toward-a-frozen-operating-system https://urbit.org/blog/toward-a-frozen-operating-system

strangetortoise 5y ago

> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least? Linux is famous for "we do not break user space" (yes, I know it's not 100% true, but it's closer than anything else I've seen), and afaik the posix standards are pretty stable too. The C language also has a stable ABI, which is basically the ffi for most languages, and most static libraries that were developed decades ago can link just fine. In my mind, the problem is caused by at least two things: - Languages that are not compiled to machine code have no incentive to have a stable API or ABI. This has the effect that code reuse now necessitates replicating the state of the machine it was developed on (Which might be using a different language version, runtime, etc). - Programming culture has progressed to a "get it done quickly, just grab a library" culture. This is not to say you should develop everything in-house, but on a spectrum, I have the hunch that this easy accumulation of dependencies induces a culture that does not vet the stability of the dependencies. Once one of your dependencies is unstable, the project on which it depends cannot be stable.

moonbug 5y ago
> a programming language and OS that does its best to not change you've heard of this thing called Windows?
- Jensson 5y ago
  Since when do windows break most programs every few months? Having to write a patch every few years when Microsoft releases a new OS is pretty low maintenance. And most of the time windows is backwards compatible nowadays, so usually you don't even need to do that. Most 10 year old games still runs on modern windows even without patches etc.
- selcuka 5y ago
  Yes. Windows is extremely backwards compatible. This could be, ironically, one of the reasons some people don't like it too much. See Raymond Chen's The Old New Thing [1] for some technical details. [1] http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...

prox 5y ago

We perhaps need a LongNow Smartphone.

jcelerier 5y ago

3pt14159 5y ago
The last update to MS-Dos was over twenty years ago. I'm longing for something more than mere backwards compatibility.
- gmfawcett 5y ago
  So you want "there should at least be a programming language and OS that does its best to not change", and you also want updates for it?
- jcelerier 5y ago
  FreeDOS is regularly updated

sagichmal 5y ago

> Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update. You only need to update dependencies that interact with things that change autonomously. For the types of programs I write, that describes very few, sometimes none, of my dependencies. Continuous updating of dependencies is valuable in some circumstances. Not all.

FpUser 5y ago

>"Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on." I have 17 years old Windows desktop product that I've long abandoned. But it is exactly this: single exe with everything compiled in. It uses DirectX 9 and Directshow. It still runs fine without any tweaking. It even compiles fine from source code. So from a practical standpoint it is maintenance free.

cxr 5y ago

> there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time A passable implementation of Lorie's UVC concept[1] is sitting right in our lap, it's just hardly ever put to use in this way, and it's considered by some not to be very sexy—or rather, it's popular to dump on it for various reasons. But you're probably using it right now to read this comment, and the reason is that its availability and reliability is a foregone conclusion by every stakeholder in this conversation—whether that be me, you, or our hosts involving Y Combinator &co. And with respect to the article, it's a foregone conclusion that it will also be involved in the tech tree of the example projects given. Jeff even mentions its longevity explicitly—in a comparison to Python, where Python is considered the worse of the two. How about just not depending on Python at all? If you click through to Jeff's "makerss.py" script and look at the kinds of machinations that it does, consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root. No implicit[2] assumptions about what software is installed on the machine in question—since it's using the UVC after all—and none of the Python 2/Python 3 fuss. (It'd have to forego the symlinking that makerss.py does near the end (currently line 1717 and 1719), but that should arguably already be handled elsewhere, anyway.) 1. https://news.ycombinator.com/item?id=11512892 https://news.ycombinator.com/item?id=11512892 2. https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033

jefftk 5y ago
> consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root I'm not sure what you mean?
- cxr 5y ago
  From <https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936>: > If folks were really committed to improving the developer experience, then instead of what we do now [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html If this is still unclear, please let me know. (Please also let me know if it is clear. I'm very interested getting this explanation "right", so it's easy to understand.)

closeparen 5y ago

Software would be incredibly "low upkeep" to last as long as HTTP. You don't have to use a new programming language just because it exists. Time zone info is a data file managed by the OS and has no business being baked into specific programs. Translations are likewise data files and should be modular so that you can add or replace them without invalidating the program. Sensors change much slower than software; the oldest and crustiest operating system image you'll ever meet is the one coupled to a multi-million-dollar sensor in a lab or a hospital.