Hacker News Reader

Comment by neilwilson | Hacker News Reader

I'm with Dijkstra

"Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."

As Systems Engineers we're probably better than 99% of the population at visualising the dynamics of the system, and even then we're still pretty bad at it.

Humility in the face of this human limitation helps enormously I find.

View on HN

I really like this quote, and humility in this case helps to more clearly view the problem (and hopefully solve it adequately)

Can anyone give me examples of what trivializing the correspondence between the program and the process looks like?

* Tests

* Types (Classes, Structures, ...)

* State management

* Documentation

* Formal models

Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed.

Have you heard of functional programming?

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relatively consistent and immutable, but that's only helpful so long as all the rest of your infrastructure is infallible. Which it isn't.

It's not about eliminating effects! It's about controlling them. A program that had no effect would be perfectly useless.

In distributed systems, it's important to be very intentional about effects, instead of letting them creep into any part of your program.

Specifically, it’s about controlling side effects by isolating them. That is, code with side effects has to explicitly declare that it has them, and calling any code with side effects allows the compiler to infer the calling code has side effects. Typically, the isolation mechanism is either explicitly monads, or, is equivalent to monads.

This is incredibly useful for debugging, as is single assignment style code, although single assignment is not necessarily implied by “functional programming.”

The state of the art in distributed programming is Erlang, which uses functional programming to enable levels of scalability very difficult to achieve with any other development stack.

This also applies specifically to the problem of lacking "infallible" infrastructure. Because of the largely stateless nature of an Erlang process, they can be killed, migrated to other machines, and quickly scaled up and down to meet changing demands.

>"utmost to shorten the conceptual gap between the static program and the dynamic process"

I'm mostly referring to this part of the quote. Pure FP is basically a static program and not a dynamic process. Nothing is changing in FP, nothing is dynamic.

FP makes this gap zero. Outside of FP (the distributed system) is a different story of course.

I think Djeikstra was talking about our limited ability to reason about what program actually does by looking at it source code. FP helps but there is still a long way ahead of us. For example I can create spaghetti code in any language and any programming paradigm. FP helps me to eliminate state, next big thing should help me to eliminate unclear and complex control flow, bad abstractions and clunky API’s.

The abstraction of FP, which is the same as mathematics, is that all functions can be treated as resolved instantly in time and from a given starting point you'll always get the same answer.

However in the real world things take time and time flows in one direction, and have a nasty habit of being non linear. FP abstracts away these complications with the notion of 'actions' which are then dealt with by some outside 'runtime system'.

Hence System.Time.getClockTime >>= print

Yes I know about the IO loop. FP reduces the gap to zero when segregated away from IO.

However I literally said for distributed systems this does not apply. This is IO. If you're referring to something like the DOM, the architecture is similar for redux. Within the bounds of IO your program is not dynamic.

Reply on news.ycombinator.com