3 ms·

They might even make it worse. Imagine filtering a list using a predicate that hits a remote service on every call. What is correct behavior for higher-order

They might even make it worse. Imagine filtering a list using a predicate that hits a remote service on every call. What is correct behavior for higher-order functions which accept function arguments that may time out? The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s. A better answer would be to say that you use something like Erlang's actor model. At which point you've proposed something very similar to - perhaps indistinguishable from - microservices.

lmm 12y ago
> The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s. I don't think it is the same, because the distinction is visible. Monadic code looks almost but not quite the same as pure code; it's not a lot of syntactic overhead, but it's enough to make it clear that something's going on. You can see right there in the type that this is invoking a remote call, and if you try to pretend that a distributed function is a regular function then the compiler will catch you and stop you. I don't think this is at all the same as CORBA, where there was literally no visible difference.
dragonwriter 12y ago
> Imagine filtering a list using a predicate that hits a remote service on every call. If its not a pure function of the type of the lists elements, its not really a predicate. (Though, in a language which doesn't distinguish pure from impure code, it might look like one.) So the question is somewhat incoherent from the start, though the problem is a real issue. > What is correct behavior for higher-order functions which accept function arguments that may time out? No different from any other operation that can timeout (or otherwise fail). > The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. Monads don't sweep mess under the carpet, they expose it. And they aren't really an answer to "what is the correct behavior...", they are an answer to "once you've determined the correct behavior, what language featuers do you use to implement it in a pure functional language." But, yes, in Haskell or a similar language, the question of "how do you deal with this external interaction that can fail" does likely involve the use of monads. > At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s. That's quite a leap, since invoking monads doesn't specify anything about functionality. > A better answer would be to say that you use something like Erlang's actor model. That's actually an orthogonal (non-)answer, since (1) the Actor model isn't an alternative which excludes monads, they operate in different conceptual domains, and (2) it still doesn't answer the "What is the correct behavior...?" question. > At which point you've proposed something very similar to - perhaps indistinguishable from - microservices. Yes, microservices are closely related to the actor model. Yes, monads are part of how you'd implement either in Haskell or a similar language. One isn't "better" than the other.
- deleted 12y ago
  [deleted]

lmm 12y ago

> The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s. I don't think it is the same, because the distinction is visible. Monadic code looks almost but not quite the same as pure code; it's not a lot of syntactic overhead, but it's enough to make it clear that something's going on. You can see right there in the type that this is invoking a remote call, and if you try to pretend that a distributed function is a regular function then the compiler will catch you and stop you. I don't think this is at all the same as CORBA, where there was literally no visible difference.

dragonwriter 12y ago

> Imagine filtering a list using a predicate that hits a remote service on every call. If its not a pure function of the type of the lists elements, its not really a predicate. (Though, in a language which doesn't distinguish pure from impure code, it might look like one.) So the question is somewhat incoherent from the start, though the problem is a real issue. > What is correct behavior for higher-order functions which accept function arguments that may time out? No different from any other operation that can timeout (or otherwise fail). > The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. Monads don't sweep mess under the carpet, they expose it. And they aren't really an answer to "what is the correct behavior...", they are an answer to "once you've determined the correct behavior, what language featuers do you use to implement it in a pure functional language." But, yes, in Haskell or a similar language, the question of "how do you deal with this external interaction that can fail" does likely involve the use of monads. > At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s. That's quite a leap, since invoking monads doesn't specify anything about functionality. > A better answer would be to say that you use something like Erlang's actor model. That's actually an orthogonal (non-)answer, since (1) the Actor model isn't an alternative which excludes monads, they operate in different conceptual domains, and (2) it still doesn't answer the "What is the correct behavior...?" question. > At which point you've proposed something very similar to - perhaps indistinguishable from - microservices. Yes, microservices are closely related to the actor model. Yes, monads are part of how you'd implement either in Haskell or a similar language. One isn't "better" than the other.

deleted 12y ago
[deleted]