Hacker News Reader

Comment by Ididntdothis | Hacker News Reader

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 “why? It works.” My answer usually is “are you sure? “.

On the other hand maybe this forgiveness allowed us to build complex systems.

View on HN

This often devolves into extremely fragile systems instead. For instance, let's say you failed to load an image on your web site. Would you rather the web site still work with the image broken or just completely fail? What if that image is a tracking pixel? What if you failed to load some experimental module?

Being able to still do something useful in the face of something not going according to plan is essential to being reliable enough to trust.

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 infrastructure tooling somewhere in your stack controllable or not? Somebody somewhere could have avoided making that mistake, but it's not clear that you could.

An additional layer of suffering is that we have a habit of allowing this complexity to creep or flood into our work and telling ourselves that it's inevitable. The author writes:

> Once your system is spread across multiple nodes, we face the possibility of one node failing but not another, or the network itself dropping, reordering, and delaying messages between nodes. The vast majority of complexity in distributed systems arises from this simple possibility.

But somehow, the conclusion isn't "so we shouldn't spread the system across multiple nodes". Yo Martin, can we get the First Law of Distributed Object Design a bit louder for the people at the back?

https://www.drdobbs.com/errant-architectures/184414966

And let us never forget to ask ourselves this question:

https://www.whoownsmyavailability.com/

> 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 a graceful fallback -- also to prevent eventual bit rot. But during development it should be a red flag of the highest order.

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.

That's an interesting distinction. I think each resource should be self contained. Malformed HTML? HTML error. Malformed or missing image? Browser displays an image error.

The key here is that the web wasn't designed for engineers but for amateurs to slap something together sloppily in the first place.

As an aside it's curious how ridiculously forgiving HTML and JS are while CSS craps itself on a single missing semicolon. As though it were okay for the thing to be semantically and functionally malformed and malfunctioning... as long as it looks good!

> This often devolves into extremely fragile systems instead.

as if the systems we have today aren't fragile? instead, they're fragile but their fragility is hidden and obfuscated.

being robust and reliable is different than just letting systems do whatever they think is best.

XHTML tried to do this after the webmasters (loosely defined) had fled the barn, and then it fell out of the world and the WHATWG ate everything.

I remember being very fond of xhtml. It seemed much more logical and sensible, every beginning having an end, all things in balance. I don’t really know what the argument against it is/was?

It is a valid usecase of html to be used to splash a layer of paint on top of your business model in a situation where you’re too busy to think in a mode where the concept of ”system correctness” makes any sense. It’s not a system in this context at all, it’s my flyer in a trade show so don’t you dare come being all pedantic on me :)! (Sure, CMS manages the markup usually nowadays. In the nineties html was used as the actual user facing layer though.)

Of course, we can discuss whether that culture of busýness was ever actually constructive, but that’s a discussion for another day.

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.

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 to build today's sky scrapers. There is considerable design and sanity checking that goes into this stuff which the web at every point completely lacked.

XHTML was a promising start in the right direction, but they unfortunately bungled it.

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.

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.

In my experience clients make business decisions that trade-off reliability, robustness, high-avaibility, etc. all the time. Because they can.

Just look at the F31, recently they opted to "test in prod" for a lot of components. And not because of the engineers/developers.

Were it a nuclear reactor control software they wouldn't have decided that way. (Hopefully.)

"I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS."

This was strongly suggested by those who fought for strict XHTML, but then Sam Ruby, who was leading the HTML5 effort, asked the question, "I find an image that I know my daughter will like. I send it to her. It is SVG. She wants to upload it to her Myspace page. However, the image won't render, because SVG is a form of XML, and Myspace is non-compliant. And yet, if I send her a JPEG or GIF image, she can upload that to Myspace."

The point was we typically embed content from one page into another page, and no one believed there would ever come a day when every page on the Web would be strict compliant. So HTML5 went in the other direction, dropping most requirements and allowing pretty much anything.

As I've written elsewhere, the fundamental problem we face is that a markup language, such as HTML, is completely unsuitable to the apps we now like to build and run over the Web. We rely on HTML to function as the GUI of TCP/IP, but it was not actually designed for that, as it was descended from SGML, and it carries with it a publishing history. What would make more sense would be use of a data format, such as JSON or EDN, which can then be given visual characteristics, without ever having to participate in one hierarchy or any one understanding of a DOM. Developers understandably complain that Java/Swing had 9 different layout options, the product of much experimentation, but having a variety of layout options does allow more flexibility of styles of building a GUI, with some approaches being simpler than what we get with the React/JS translation into HTML.

If the web worked like that, it probably wouldn't be so popular today.

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

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.

Well, there is the Robustness Principle:

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

the wisdom of that policy just accrues over time.

[1] https://en.wikipedia.org/wiki/Robustness_principle

Hyrum's Law challenges that supposed wisdom.

https://www.hyrumslaw.com/

Postel's Law creates debt that we pay interest on forever

Since Hyrum's law is a naturalist observation and Postel's Law is a suggestion, Hyrum's law is a more definitive truth.

I can see that too. You end up possibly supporting a bug-compatible interface or other nonsense.

Amusing but unrelated I looked to see if that law was on wikipedia and clicked on this thinking it might be another spelling:

https://en.wikipedia.org/wiki/Yhprum%27s_law

Are you sure? Your comment contains a minor syntax error.

Should you have been unable to submit it, or should people not be able to view it, until you correct it?

  >My answer usually is “are you sure? “.                         
                                       ^

   Line 1:
   Syntax error: "“" not allowed here.

JavaScript is quite forgiving, but that's usually okay. If something doesn't work it's usually not the end of the world.

In this case everyone correctly read your second opening quotation mark as a closing quotation mark.

This allows us to focus on what you're saying (functionality.)

If we couldn't figure out why you included some typos, we would just ignore that part and focus on the rest of your comment.

When someone replies with the nitpicking style it doesn't help anyone. (In fact my first version of this comment was downvoted, before I wrote out the rest of my explanation.)

I think all the leniency in front end JS is pretty good for the same reason. It lets us communicate, and the sandboxed client environment (browser security is built assuming web sites could be malicious) means that the stakes are quite low.

This is what strict languages like Rust are for, right?

On a sidenote, I intensely dislike statements like this that hedge their point.

To me this kind of thing is the difference between furniture you buy from a decent store or from IKEA. It's craftsmanship, not complexity.

Reply on news.ycombinator.com