4 ms·

Yes, existing desktop applications and operating systems are hairballs with software layers built atop older software layers built atop even older software laye

by cs702 9y ago

Yes, existing desktop applications and operating systems are hairballs with software layers built atop older software layers built atop even older software layers. Yes, if you run the popular editor Atom on Linux, you're running an application built atop Electron, which incorporates an entire web browser with a Javascript runtime, so the application is using browser drawing APIs, which in turn delegate drawing to lower-level APIs, which interact with a window manager that in turn relies on X... Yes, it's complexity atop complexity atop complexity all the way down. But the solution is NOT to throw out a bunch of those old layers and replace them with new layers!!! Quoting Joel Spolsky[1]: "There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it. ... The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. ... 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." [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

GTP 9y ago
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.
- quickben 9y ago
  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.
steinuil 9y ago
> 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.
- mwcampbell 9y ago
  Can you give an example of innovations from Midori making it into Windows?
DashRattlesnake 9y ago
> "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.
- lou1306 9y ago
  > 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.
- sgift 9y ago
  > ripping out all kinds of stuff So, they weren't starting over. They forked, refactored and removed things no longer needed. Completely different thing.
- gruturo 9y ago
  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.
- vacri 9y ago
  > It brings to mind OpenSSL after Heartbleed. It's three years later. What general-purpose OS other than OpenBSD is using LibreSSL?
  - smitherfield 9y ago
linkmotif 9y ago
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
- sgift 9y ago
  > 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)
- u02sgb 9y ago
  Michael Feathers quote I think.
makecheck 9y ago
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.
- Boothroid 9y ago
  Absolutely. I suffer when I have to look at my crumby POC code that we don't have the hours to fix.
Boothroid 9y ago
It's also more fun to write it yourself! At least until you realise you've bitten off more than you can chew.
DonaldFisk 9y ago
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 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.
- shalabhc 9y ago
  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?
  - nailuj 9y ago
    I don't think it's developed very actively, but a recent effort is PharoNOS: http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos
  - mafik 9y ago
    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.
lifthrasiir 9y ago
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.

by cs702 9y ago

GTP 9y ago

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.

quickben 9y ago
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.

steinuil 9y ago

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

mwcampbell 9y ago
Can you give an example of innovations from Midori making it into Windows?

DashRattlesnake 9y ago

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

lou1306 9y ago
> 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.
sgift 9y ago
> ripping out all kinds of stuff So, they weren't starting over. They forked, refactored and removed things no longer needed. Completely different thing.
gruturo 9y ago
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.
vacri 9y ago
> It brings to mind OpenSSL after Heartbleed. It's three years later. What general-purpose OS other than OpenBSD is using LibreSSL?
- smitherfield 9y ago

linkmotif 9y ago

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

sgift 9y ago
> 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)
u02sgb 9y ago
Michael Feathers quote I think.

makecheck 9y ago

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.

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

Boothroid 9y ago

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

DonaldFisk 9y ago

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

shalabhc 9y ago
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?
- nailuj 9y ago
  I don't think it's developed very actively, but a recent effort is PharoNOS: http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos
- mafik 9y ago
  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.

lifthrasiir 9y ago

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.