Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systems that defy detailed understanding

blog.nelhage.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Systems that defy detailed understanding

#41

Post by naringas »

I firmly believe that in theory all computer systems can be understood.

But I agree when he says, it has become impractical to do so. But I just don't like it personally, I got into computing because it was supposed to be the most explainable thing of all (until I worked with the cloud and it wasn't).

I highly doubt that the original engineers who designed the first microchips and wrote the first compilers, etc... relied on 'empirical' tests to understand their systems.

Yet, he is absolutely correct, it can no longer be understood, and when I wonder why I think the economic incentives of the industry might be one of the reasons?

for example, the fact that chasing crashes down the rabbit hole is "always a slow and inconsistent process" will make any managerial decision maker feel rather uneasy. This make sense.

Imagine if the first microprocessors where made by incrementally and empirically throwing together different logic gates until it just sort of worked??

Re: Systems that defy detailed understanding

#42

Post by maxerickson »

naasking wrote: post #33
Koshkin wrote: post #32

Earlier quoted context omitted.

Indeed, less rigidity and higher tolerances lead to reliability - similar to what we do in construction of buildings: a skyscraper would fall one day if it wasn't for its flexibility under effects of elements such as wind.

That's not an apt analogy. A system with tight tolerances can still be flexible, we just know more precisely how it can flex and when it will break. A better analogy would be if your construction workers didn't have standard or prescribed bolts in their design, so they just take what's lying around and hammer and weld bits together until it seemed sturdy enough. Suffice it to say, this is not a recipe that would work…

If you treat the browser as the skyscraper and web pages as environmental conditions, the approaches look more similar.

In that analogy, XHTML is weather control satellites.

Re: Systems that defy detailed understanding

#43

Post by mech422 »

Ididntdothis wrote: post #22

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

Personally, as a coder AND as a user - I want the program to flat out fail. As a user, a system that aborts on error maybe a PITA to use, but I have confidence in the output it provides.

As a programmer, I like that same confidence in output AND it requires me to address the failures in some way...

Re: Systems that defy detailed understanding

#44

Post by INTPnerd »

Even if you can reason about the code enough to come to a conclusion that seems like it must be true, that doesn't prove your conclusion is correct. When you figure something out about the code, whether through reason and research, or tinkering and logging/monitoring, you should embed that knowledge into the code, and use releases to production as a way test if you were right or not.

For example, in PHP I often find myself wondering if perhaps a class I am looking at might have subclasses that inherit from it. Since this is PHP and we have a certain amount of technical debt in the code, I cannot 100% rely on a tool to give me the answer. Instead I have to manually search through the code for subclasses and the like. If after such a search I am reasonably sure nothing is extending that class, I will change it to a "final" class in the code itself. Then I will rerun our tests and lints. If I am wrong, eventually an error or exception will be thrown, and this will be noticed. But if that doesn't happen, the next programmer who comes along and wonders if anything extends that class (probably me) will immediately find the answer in the code, the class is final. This drastically reduces possibilities for what is possible to happen, which makes it much easier to examine the code and refactor or make necessary changes.

Another example is often you come across some legacy code that seems like it no longer can run (dead code). But you are not sure, so you leave the code in there for now. In harmony with this article, you might log or in some way monitor if that path in the code ever gets executed. If after trying out different scenarios to get it to run down that path, and after leaving the monitoring in place on production for a healthy amount of time, you come to the conclusion the code really is dead code, don't just add this to your mental model or some documentation, embed it in the code as an absolute fact by deleting the code. If this manifests as a bug, it will eventually be noticed and you can fix it then.

By taking this approach you are slowly narrowing down what is possible and simplifying the code in a way that makes it an absolute fact, not just a theory or a model or a document. As you slowly remove this technical debt, you will naturally adopt rules like, all new classes must start out final, and only be changed to not be final when you need to actually extend them. Eventually you will be in a position to adopt new tools, frameworks, and languages that narrow down the possibilities even more, and further embedding the mental model of what is possible directly into the code.

Re: Systems that defy detailed understanding

#45

Post by dnautics »

9wzYQbTYsAIc wrote: post #39
Koshkin wrote: post #32

Earlier quoted context omitted.

Indeed, less rigidity and higher tolerances lead to reliability - similar to what we do in construction of buildings: a skyscraper would fall one day if it wasn't for its flexibility under effects of elements such as wind.

Interesting related trivia: engineers build safeguards around that flexibility - in the same way that a poorly built bridge will shake itself apart in the wind, a building without adaptive dampening or the right properties of flexibility could shake itself apart in the wind.

The inherent presumption is that software engineers are engineers in that sense of the word. How I wish more were.

Re: Systems that defy detailed understanding

#47

Post by INTPnerd »

Ididntdothis wrote: post #22

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

It is true that the underlying technology used to write the code to begin with should be less forgiving. If you use a strictly typed, compiled language instead of PHP, you would have no choice but to fix a lot more of the errors because it would not compile otherwise.

Once it is running on production though, things are quite different. You need the right combination of errors being well reported and gracefully handled without aborting or breaking the rest of the functionality unnecessarily. At that point people are relying on it to get their jobs done and they will usually find ways to work around the errors and even the corrupt data this might result in so they can keep meeting their deadlines while the programmers work on fixing the problem. This is much better than those same employees not being able to do their jobs or getting payed to stand around and do nothing. I guess this attitude is largely driven by the practicalities of where I work. If the employees that rely on the code to work get behind or can't complete their work on time, our company is nailed with thousands of dollars in fines as per the contract agreements we have to agree to in order to get the business/contracts to begin with, and then our customers can't bill their customers, so they are not happy.

Re: Systems that defy detailed understanding

#48

Post by uk_programmer »

Ididntdothis wrote: post #22

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

Even in languages like C# it will let you get away with lots of horrendous things. Generally unless you put on options like "Treat Warnings as Errors" most programmers will just ignore them, or wrap some statements in 'pragma' and disable the warnings. I've seen people just wrap an exception around the entire application or put a giant exception filter instead of actually fixing the problem.

Poor/Lazy developers will find ways around more stringent checks.

Re: Systems that defy detailed understanding

#49

Post by numpad0 »

andai wrote: post #38
twic wrote: post #34

Earlier quoted context omitted.

Systems need to be robust against uncontrollable failures, like a cosmic ray destroying an image as it travels over the internet, because we can never prevent those. But systems should quickly and reliably surface bugs, which are controllable failures. A layer of suffering on top of that simple story is that it's not always clear what is and what is not a controllable failure. Is a logic error in a dependency of some…

> systems should quickly and reliably surface bugs, which are controllable failures I was thinking, if the error exists between keyboard and chair, I want the strictest failure mode to both catch it and force me to do things right the first time. But once the thing is up and running, I want it to be as resilient as possible. Resource corrupted? Try again. Still can't load it? At this point, in "release mode" we want…

Are robustness and loose engineering the same/overlapping quality measurements?

If so makes sense to be not strict, if not it’s you(and us all) rolling up two different modes of failures into a single classification.

Re: Systems that defy detailed understanding

#50

Post by asfarley »

Ididntdothis wrote: post #22

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

This is what strict languages like Rust are for, right?
Post reply on HN