Hacker News Reader

I like a lot of what Joel writes, but I profoundly disagree with him on this, and I'm not alone in my dislike of accidental complexity which, which I think is now an order of magnitude greater than essential complexity. So there is a "silver bullet". It just needs someone to bite it.

The author of the article recognizes there's a problem, but is less clear on how to go about solving it. A clue is in this article by Erik Naggum: http://naggum.no/erik/complexity.html

Dan Ingalls once wrote: "Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one." What he meant is we should migrate the functionality of the operating system into the programming language. This is possible if there's a REPL or something similar, so no need for the shell or command line. The language should be image-based, so no need for a file system. So, a bit like Squeak, or a Lisp with a structure editor.

There's still a gap between the processor and the language, which should be eliminated by making the processor run the language directly. This was done in Burroughs mainframes and Lisp machines.

Further up the "stack", software such as word processors and web browsers are at present written entirely separately but have much in common and could share much of their code.

Thanks for the link to Erik's essay - it was a great read.

I like the idea of an image based system, eliminating the need for the filesystem itself. I think the 'filesystem' and 'executable-process' ideas are so prevalent that they frame our thinking, and any new OSes tend to adopt these right away. But more interesting and powerful systems might emerge if we find a new pattern of operation and composition. Are you aware of any image based full stack systems that are in active development?

I don't think it's developed very actively, but a recent effort is PharoNOS: http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos

Android is one such system. Each app gets its own image (called Bundle) where it can store it's state. OS manages those state bundles to offer multitasking on memory-constrained devices and persist app state across reboots.

Android has a file system. It's a operating system (a Linux variant). I'm suggesting that neither a file system nor an operating system is necessary, or even desirable. Just run an interactive programming language continuously on the bare metal, with its image periodically backed up to secondary storage.

> "When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

But, sometimes, that's exactly what you should do. It brings to mind OpenSSL after Heartbleed. I remember reading that the LibreSSL people were ripping out all kinds of stuff (like kludges and workarounds to support OpenVMS), and rightly so. You might call it "knowledge [and] collected bug fixes," but sometimes the crap is just crap.

LibreSSL is a special case which doesn't fit your example. They threw away code and didn't rewrite most of it - because it was supporting useless stuff. Features like heartbeat (see Hearbleed), obsolete and insecure ciphers, tons of crap no one should ever use again but is supposed to be there for FIPS-140 or other compliance requirements which in 2017 do far, far more harm than good.

> You might call it "knowledge [and] collected bug fixes," but sometimes the crap is just crap.

Key word here is "Sometimes".

Reviewing code means you get to find out the reason these hacks were written in the first place, and then decide wheter to keep, rework or delete them.

Starting from scratch means you get rid of the worthless crap, yes, but you also lose all the valuable crap.

> ripping out all kinds of stuff

So, they weren't starting over. They forked, refactored and removed things no longer needed. Completely different thing.

> It brings to mind OpenSSL after Heartbleed.

It's three years later. What general-purpose OS other than OpenBSD is using LibreSSL?

Not LibreSSL, but Apple replaced OpenSSL with their own library, Common Crypto.

https://developer.apple.com/library/content/documentation/Se...

https://opensource.apple.com//source/CommonCrypto/CommonCryp...

> But the solution is NOT to throw out a bunch of those old layers and replace them with new layers!!!

Neither is keeping everything as it is and keep pretending it's fine!

> When you throw away code and start from scratch, you are throwing away all that knowledge.

I disagree with Joel on here. There's lots to be learned from throwing everything away and starting from scratch, and if anything those innovations could make their way into the current infrastructure, as it has happened with Midori and Windows.

Can you give an example of innovations from Midori making it into Windows?

It is vital to have regular cleanup in a code base to avoid the feeling that it should "all" be scrapped. There will always be code worth keeping for all the reasons mentioned (bugs fixed, etc.) but there will always be something that should just go away.

Absolutely. I suffer when I have to look at my crumby POC code that we don't have the hours to fix.

He doesn't suggest to trow away the old layers just because they're old, but because he suggests a different approach. Anyway that's a really good quote, I like it very much.

It is, but one just doesn't replace a proper BTree filesystem with a document database. Just because the author saw a document db, and thought it's cool, without looking at why BTrees won.

Not a big Joel Spolsky guy but this is truth of truths right here.

Related: "legacy code is code that doesn't have tests" not sure who said this but also very true IMO

> Related: "legacy code is code that doesn't have tests" not sure who said this but also very true IMO

Michael Feathers in "Working with legacy code" (A book I can highly recommend)

Michael Feathers quote I think.

Joel's assertion applies to the situation where the old code and the new code will reach roughly the same complexity at the end (for example, this is often the case when the requirements are complex enough and cannot be changed). If you have a very good idea to greatly reduce the complexity, ignore him and go ahead.

In the other words, the point is that you always have to do the cost-benefit analysis for any such endeavor and the history tells that rewriting is intrinsically very expensive.

It's also more fun to write it yourself! At least until you realise you've bitten off more than you can chew.