61–70 of 103 posts
There are so many less layers of abstraction and "magic" to dig through that at I can always figure out what's going on easily enough. I think this article hits the nail on the head.
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When…
>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like paint…
I have known this for many years but found it difficult to explain to others. Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated. Though scalable backends are increasingly getting their own layers of complexity these days, but still, on the backend you will never d…
Something I've noticed is that when you're building a backend, your program only ever interfaces with other programs. You can establish a reasonably predictable protocol. But when you build a front-end, you're interfacing with the human brain and all the messiness that that entails. It's an incredibly difficult thing to do well.
Earlier quoted context omitted.
A lot of the times the part of the backend that renders pages and handles user input can be assumed to be part of the frontend, I'm not talking about those. I meant backend as an API. I honestly think you've never built a decent sized, non-trivial mobile app for example, and you probably have no idea how tedious and difficult it is to produce something that will be pleasant for the users to deal with.
I mean, if you say "parts of the backend are actually the frontend"[0] and "parts of the backend area actually the infra" and say "backend" is just a CRUD api that talks to a database: sure, that can be easy. But I've rarely seen backend jobs that don't require touching the 90% of the iceberg that's underwater... So it's a stupid definition. I haven't built a large mobile app, but I'm not claiming frontend dev is eas…
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When…
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When…
A logical error in an accounting package can probably often only be found by a checking tool that has the equivalent of all the functionality of the package under test.
OS bugs are more likely to have the side effect of violating language invariants (which eg KASan, UBSan and KCSan often detect), or violating protocols (so you can stress-test eg a TCP implementation and detect the bug), or it can violate API invariants (so you can use some API-level stress test like stress-ng to detect the bug.)
All of these tools are much less complex than the software under test. I think the warlord of Wu made the comment about debugging before massive automated testing, compiler instrumentation etc were a thing.
And I think a similar argument can be made wrt software and hardware-level visibility/tracing mechanisms - again an OS will end up being easier than higher-level software given a good investment in tooling.
Earlier quoted context omitted.
I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent during a network partition.” True, and interesting, and useful to know, but if “100% available” is in your requirements to begin with, you are doomed to fail and the CAP theorem is just more nails in the coffin. To me, the “you can’t have a perfect system” is re…
If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD. And remember the context of this thread: we have a claim here t…
Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd.
> …but "as available as possible because outages cost us $XXXX/minute" is.
“As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear.
You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied.
What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?”
> And remember the context of this thread…
I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem.
> Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.
503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500.
This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end.
Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.
I have known this for many years but found it difficult to explain to others. Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated. Though scalable backends are increasingly getting their own layers of complexity these days, but still, on the backend you will never d…
I wonder how much of this is due to the fact that the programming education today comes from a top-down approach, where one starts with a high-level language with little knowledge of the underlying system or the layers of abstraction on top of which it runs. Your upper year courses is where you begin learning more about operating systems, computer architecture, and the like. Naturally, those programmers become focuse…
Earlier quoted context omitted.
>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like paint…
But I think that even with all of that, writing an OS is still much easier than an accounting package. The way forward is paved smooth by hundreds that have gone before. And by that I mean, hundreds of Unix clones have been made and open-sourced. Things like microkernels and NT-style I/O architecture are esoteric things that you only see in the embedded world (which Google seems to be limiting Fuchsia to at the momen…