3 ms·

but why? maintaining features is cost

by tester756 5y ago

amelius 5y ago
Perhaps one day we can have a programming language that allows us to write software that doesn't rot or corrode.
- klodolph 5y ago
  You can continue to use most command-line FTP programs without problem. Since the terminal is a fairly stable interface, programs written long ago often have no problem compiling and running on modern systems, or only require small changes.
  - mananaysiempre 5y ago
    I wouldn’t actually say that, but it may be more of a problem of ecosystem maturity and priorities than it is one of interface stability: I work under Linux and love it, but getting a 20- or 30-year-old program to compile or run under it is surprisingly more painful than doing the same for a Win32 program of similar age, despite the ostensible stability and undeniably better documentation, including that of historical issues, in the former case. (To be fair, getting an old DOS program to compile or run anywhere except a full VM is an absolute nightmare, even if it can sometimes be offloaded to DOSBox maintainers.)
    - klodolph 5y ago
      I would say it—getting a 20-year-old CLI program to compile and run is often not much trouble at all. Not always, but often. Even if the program was never written from Linux, you can often get it to compile and run by fixing up headers and making some other minor changes to the source code. I’ve had plenty of success compiling and running programs that were only ever designed to run on IRIX or Solaris or other Unix systems.
- drewzero1 5y ago
  We can start by writing software that doesn't have any features at all, and save ourselves the trouble of removing them later. /s
  - zaat 5y ago
    Here you go: https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode
- andyp-kw 5y ago
  The main issue with old code, is that it slows down refactoring.
  - stirfish 5y ago
    Refactoring new code is not faster
    - winstonewert 5y ago
      refactoring no code (because it was removed) is certainly faster.
- skeeter2020 5y ago
  You can do that in any language; just write software that no one uses. The rest of it needs to be maintained regardless of what language was used.
- r00fus 5y ago
  As long as code connects to other code, it will need to be updated whenever the other code is updated. Maintenance-free code is a chimera.
  - Jach 5y ago
    Maintenance-free code exists. I'm sorry you haven't experienced work at an org that has 10+ year old code which hasn't changed at all, easily verified by source control. (Has Mozilla published something anywhere about exactly how much work it is to keep FTP support around?) And while not technically 100% free, something closely related that's basically free is lots of 10+ year old code which does need to change sometimes but only as part of a batch of the same change in many places, and that's basically free because it's done automatically by tooling.
    - r00fus 5y ago
      Small code segments may indeed be maintenance free. If a large codebase that interacts with any other system/code (either through usage of shared libraries, network connection or a common file format) has not changed, that means there's likely technical debt that hans't been addressed (or needed to address).

but why? maintaining features is cost

amelius 5y ago

Perhaps one day we can have a programming language that allows us to write software that doesn't rot or corrode.

klodolph 5y ago
You can continue to use most command-line FTP programs without problem. Since the terminal is a fairly stable interface, programs written long ago often have no problem compiling and running on modern systems, or only require small changes.
- mananaysiempre 5y ago
  I wouldn’t actually say that, but it may be more of a problem of ecosystem maturity and priorities than it is one of interface stability: I work under Linux and love it, but getting a 20- or 30-year-old program to compile or run under it is surprisingly more painful than doing the same for a Win32 program of similar age, despite the ostensible stability and undeniably better documentation, including that of historical issues, in the former case. (To be fair, getting an old DOS program to compile or run anywhere except a full VM is an absolute nightmare, even if it can sometimes be offloaded to DOSBox maintainers.)
  - klodolph 5y ago
    I would say it—getting a 20-year-old CLI program to compile and run is often not much trouble at all. Not always, but often. Even if the program was never written from Linux, you can often get it to compile and run by fixing up headers and making some other minor changes to the source code. I’ve had plenty of success compiling and running programs that were only ever designed to run on IRIX or Solaris or other Unix systems.
drewzero1 5y ago
We can start by writing software that doesn't have any features at all, and save ourselves the trouble of removing them later. /s
- zaat 5y ago
  Here you go: https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode
andyp-kw 5y ago
The main issue with old code, is that it slows down refactoring.
- stirfish 5y ago
  Refactoring new code is not faster
  - winstonewert 5y ago
    refactoring no code (because it was removed) is certainly faster.
skeeter2020 5y ago
You can do that in any language; just write software that no one uses. The rest of it needs to be maintained regardless of what language was used.
r00fus 5y ago
As long as code connects to other code, it will need to be updated whenever the other code is updated. Maintenance-free code is a chimera.
- Jach 5y ago
  Maintenance-free code exists. I'm sorry you haven't experienced work at an org that has 10+ year old code which hasn't changed at all, easily verified by source control. (Has Mozilla published something anywhere about exactly how much work it is to keep FTP support around?) And while not technically 100% free, something closely related that's basically free is lots of 10+ year old code which does need to change sometimes but only as part of a batch of the same change in many places, and that's basically free because it's done automatically by tooling.
  - r00fus 5y ago
    Small code segments may indeed be maintenance free. If a large codebase that interacts with any other system/code (either through usage of shared libraries, network connection or a common file format) has not changed, that means there's likely technical debt that hans't been addressed (or needed to address).