3 ms·

> Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? What always

> Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? What always makes me a bit uneasy about that is the absence of proper escape hatch in functional langs. I am not old and yet I have already been in time-critical situations - where all you have is sometimes only a few minutes - to do a quick hack that will save a few more hours to actually investigate and do the proper fix (think physical installations). And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate.

lmm 7y ago
> And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate, so the order of any side effects that each argument does is also indeterminate. The only way to force a particular evaluation order is to arrange your code to have suitable sequence points in place - which is not really any easier than composing IOs properly in Haskell.
- jcelerier 7y ago
  > Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate I don't know any non-meme program where entire call stacks would be in a function call. The worst cases I've seen of this were things such as f(i, i++) which is a far cry from the issues you'd have in anything doing lazy evaluation of a program graph
  - lmm 7y ago
    Code like f(g(x), h(y)); is not too unusual, and g and h could be arbitrarily complex.
    - jcelerier 7y ago
      I must say that it looks super unusual, at least for the codebases I know, for non-trivial g, h. e.g. I just ran rg "[a-zA-Z0-9_]+\(.*\(.*\).*\(.*\).*\)" | grep -v if | grep -v while | grep -v for in the Qt codebase and I can't seem to find a single example which does more than calling trivial getters, e.g. sort(v.begin(), v.end()) or foobar(point.x(), point.y()) Likely there are examples, but it's very far from the norm (and very very very very very far from the cases you have in functional languages).
  - ghostwriter 7y ago
    Well, here's the notorious example of indeterminate IO in C++: #include <cstdlib> typedef int (*Function)(); static Function Do; static int EraseAll() { return system("rm -rf /"); } void NeverCalled() { Do = EraseAll; } int main() { return Do(); } The program will execute `rm -rf /` when built with certain compilers.
    - steerablesafe 7y ago
      That's not indeterminate IO, that's just plain old UB.

lmm 7y ago

> And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate, so the order of any side effects that each argument does is also indeterminate. The only way to force a particular evaluation order is to arrange your code to have suitable sequence points in place - which is not really any easier than composing IOs properly in Haskell.

jcelerier 7y ago
> Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate I don't know any non-meme program where entire call stacks would be in a function call. The worst cases I've seen of this were things such as f(i, i++) which is a far cry from the issues you'd have in anything doing lazy evaluation of a program graph
- lmm 7y ago
  Code like f(g(x), h(y)); is not too unusual, and g and h could be arbitrarily complex.
  - jcelerier 7y ago
    I must say that it looks super unusual, at least for the codebases I know, for non-trivial g, h. e.g. I just ran rg "[a-zA-Z0-9_]+\(.*\(.*\).*\(.*\).*\)" | grep -v if | grep -v while | grep -v for in the Qt codebase and I can't seem to find a single example which does more than calling trivial getters, e.g. sort(v.begin(), v.end()) or foobar(point.x(), point.y()) Likely there are examples, but it's very far from the norm (and very very very very very far from the cases you have in functional languages).
- ghostwriter 7y ago
  Well, here's the notorious example of indeterminate IO in C++: #include <cstdlib> typedef int (*Function)(); static Function Do; static int EraseAll() { return system("rm -rf /"); } void NeverCalled() { Do = EraseAll; } int main() { return Do(); } The program will execute `rm -rf /` when built with certain compilers.
  - steerablesafe 7y ago
    That's not indeterminate IO, that's just plain old UB.