undefined | Better HN

0 pointsamelius4y ago0 comments

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

0 comments

We can start by writing software that doesn't have any features at all, and save ourselves the trouble of removing them later. /s

zaat4y ago

Here you go: https://github.com/kelseyhightower/nocode

r00fus4y 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.

Jach4y 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.

r00fus4y 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).

klodolph4y 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.

mananaysiempre4y 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.)

klodolph4y 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.

skeeter20204y 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.

andyp-kw4y ago

The main issue with old code, is that it slows down refactoring.

stirfish4y ago

Refactoring new code is not faster

winstonewert4y ago

refactoring no code (because it was removed) is certainly faster.

j / k navigate · click thread line to collapse