Comment

Comment by Cthulhu_

I wouldn't write software as such, but a standard; that is, a description of input, expected output, and the processes in between.

Maybe even more important than to describe expected behaviour though, is to reduce the scope to the bare minimum. I like using e.g. Git's file format as an example, because you can wrap your head around it in less than an hour. If you have a Git repository and a description of the Git file format, I'm confident you could write an application that could read the contents within a day.

I mean yeah you could probably create a codebase based on e.g. the C standard, package it together with all the necessary tools and documentation to make it compile, but you can also wonder whether that would even be relevant in 100 years. What if in 100 years it has to process a million times more data? What if in 100 years computer architecture has changed so vastly that you need a completely different programming paradigm to make it work? (think science fiction). What if instead of trying to make it work in 100 year old code, you could feed the description to an AI that can do the work?

Long story short, I think that if you want to future proof software, you should understand and describe the problem first and foremost. Write a specification of e.g. the Git file format and spec, instead of the Git application.

parent Cthulhu_ 7 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton