This quote from the article is interesting: > Find me a file in a codebase that has been under active development for more than three years, and it will be har

This quote from the article is interesting: > Find me a file in a codebase that has been under active development for more than three years, and it will be hard to follow. It might be true of enterprise [1] software, but is not generally the case. The question is whether code quality is valued in a given environment. If it's not, it doesn't matter what language is used, a mess will be created. Despite words to the contrary from most enterprise software shops, code quality is usually not valued at all - if it were the patterns which prevail would... not. By contrast, at random just now, I chose a popular device (Intel E1000 NICs), and looked at one of the files from the FreeBSD driver code for it [2]. This code written in C was added in 2008. The code is not "hard to follow" despite not being an expert on FreeBSD drivers, it has not atrophied or suffered from rot, while remaining under active development for at least 13 years. I didn't track the history beyond the addition of that file, so it's likely the code is actually older. I could have performed this experiment on any project that values quality: Illumos, the Linux Kernel, LLVM, the Go standard library, and I'd wager the results would be similar more often than not. [1]: "Enterprise" software is the (pejorative) term I tend to use to mean over engineered software with liberal use of frameworks and ORMs, generally at least 4-5 layers of mapping code adding no value, and an "architecture committee" - even if that committee consists of a single individual who also writes all the code for the project... [2]: https://github.com/freebsd/freebsd-src/blob/main/sys/dev/e1000/if_em.c https://github.com/freebsd/freebsd-src/blob/main/sys/dev/e10...