3 ms·

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 d

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?

skywhopper 7y ago
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.
- smilliken 7y ago
  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.
  - pmiller2 7y ago
    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.”
- jimbokun 7y ago
  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.
- crimsonalucard 7y ago
  >"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.
  - kikimora 7y ago
    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.
  - neilwilson 7y ago
    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
    - crimsonalucard 7y ago
      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.

skywhopper 7y ago

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.

smilliken 7y ago
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.
- pmiller2 7y ago
  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.”
jimbokun 7y ago
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.
crimsonalucard 7y ago
>"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.
- kikimora 7y ago
  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.
- neilwilson 7y ago
  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
  - crimsonalucard 7y ago
    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.