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

51–60 of 65 posts

Re: Systems that defy detailed understanding

#51

Post by AgentOrange1234 »

dasyatidprime wrote: post #29
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…

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?

Re: Systems that defy detailed understanding

#52

Post by mntmoss »

karmakaze wrote: post #30
BurningFrog wrote: post #24

Earlier quoted context omitted.

> The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”. This is also what I wanted to say. One important part of that is that refactoring is a pretty difficult skill, and many programmers do not have it. So... for those people, some other advice is probably better.

I wish this process was called 'factoring' and you had to be able to name the concept that was being isolated. Often 'refactoring' just means moving code around or isolating code for it's own sake. If a factor was properly isolated you shouldn't have to do that one again. Sometimes you choose different factors, but that's much less common.

"Factoring" is sometimes used in the Forth world, since code being factored into small words is of such eminence.

And it offers good lessons about what's worth factoring and how. Forth words that are just static answers and aliases are OK! They're lightweight, and the type signatures are informal anyway. "Doing Forth" means writing it to exactly the spec and not generalizing, so there's a kind of match of expectations of the environment to its most devoted users.

On the other hand, in most modern environments the implied goal is to generalize and piling on function arguments to do so is the common weapon of choice, even when it's of questionable value.

Lately I've cottoned on to CUE as a configuration language and the beauty of it lies in how generalization is achieved while resorting to a minimum of explicit branches and checks, instead doing so through defining the data specification around pattern matching and relying on a solver to find logical incoherencies.

I believe that is really the way forward for a lot of domains: Get away from defining the implementation as your starting point, define things instead in a system with provable qualities, and a lot of possibilities open up.

Re: Systems that defy detailed understanding

#53

Post by savolai »

AgentOrange1234 wrote: post #51
dasyatidprime wrote: post #29

Earlier quoted context omitted.

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.

Re: Systems that defy detailed understanding

#54

Post by lucas_membrane »

I suspect that systems that defy understanding demonstrate something that ought to be a corollary of the halting problem, i.e. just as you can't figure out for sure how long an arbitrary system will take to halt, or even figure out for sure whether or not it will, neither can you figure out how long it will take to figure out what's going on when an arbitrary system reaches an erroneous state, or even figure out for sure whether or not you can figure it out.

Re: Systems that defy detailed understanding

#55

Post by nil-sec »

lucas_membrane wrote: post #54

I suspect that systems that defy understanding demonstrate something that ought to be a corollary of the halting problem, i.e. just as you can't figure out for sure how long an arbitrary system will take to halt, or even figure out for sure whether or not it will, neither can you figure out how long it will take to figure out what's going on when an arbitrary system reaches an erroneous state, or even figure out for…

I’m not sure about this. Define your “erroneous” state as “halt”. Now the question becomes, for a systems that halts, find out how it reached this state. The mathematical answer to this is simply the description of the Turing machine that produced this state. Whether you can understand this description or not isn’t relevant.

Re: Systems that defy detailed understanding

#56

Post by pas »

dnautics wrote: post #45
9wzYQbTYsAIc wrote: post #39

Earlier quoted context omitted.

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

Re: Systems that defy detailed understanding

#57

Post by h_r »

smitty1e wrote: post #2

Great article. Recalls Gall's Law[1]. "A complex system that works is invariably found to have evolved from a simple system that worked." Also, TFA invites a question: if handed a big ball of mud, is it riskier to start from scratch and go for something more triumphant, or try to evolve the mud gradually? I favor the former, but am quite often wrong. [1] https://en.m.wikiquote.org/wiki/John_Gall

With respect to evolving balls of mud, the only thing that mostly worked for me is to try to find those boundaries where you can apply the [Strangler Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns...)

Re: Systems that defy detailed understanding

#58

Post by AndrewKemendo »

carapace wrote: post #6

"Introduction to Cybernetics" W. Ross Ashby http://pespmc1.vub.ac.be/ASHBBOOK.html > ... still the only real textbook on cybernetics (and, one might add, system theory). It explains the basic principles with concrete examples, elementary mathematics and exercises for the reader. It does not require any mathematics beyond the basic high school level. Although simple, the book formulates principles at a high level of a…

I find it really sad that cybernetics completely evaporated as a field with the closest remnant being cognitive science. I think there is a huge need for more interdisciplinary fields

Re: Systems that defy detailed understanding

#59

Post by carapace »

AndrewKemendo wrote: post #58
carapace wrote: post #6

"Introduction to Cybernetics" W. Ross Ashby http://pespmc1.vub.ac.be/ASHBBOOK.html > ... still the only real textbook on cybernetics (and, one might add, system theory). It explains the basic principles with concrete examples, elementary mathematics and exercises for the reader. It does not require any mathematics beyond the basic high school level. Although simple, the book formulates principles at a high level of a…

I find it really sad that cybernetics completely evaporated as a field with the closest remnant being cognitive science. I think there is a huge need for more interdisciplinary fields

A lot of it was incorporated or duplicated in feedback control theory, but mostly in the context of industry, so it didn't really feed back (heh, sorry) into other, more academic, areas. And, on the other hand, it spun off into (IMO) fluffy "second-order" cybernetics and became a kind of toy philosophy.

I find it sad too. PID controllers are great but from my POV they're barely the first step.

However, another way to look at it is, you can study and apply "Intro to Cyb" and leapfrog into the future.

Re: Systems that defy detailed understanding

#60

Post by logicallee »

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…

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.

Post reply on HN