4 ms·

I'm not deep into Haskell, but isn't the interpreter monad pattern effectively a language within the language that acts in a very conventional procedural way fo

by slver 5y ago

I'm not deep into Haskell, but isn't the interpreter monad pattern effectively a language within the language that acts in a very conventional procedural way for interacting with IO and other external concerns? I just wonder... does Haskell really need syntactic segregation for this, and how is that better than any language which can declare/enforce pure functions/modules without the entire language being like that by default.

tome 5y ago
Well, give it a go! Or alternatively, look for languages that have been successful in enforcing any kind of purity and that also permit unrestricted use of higher order functions.
- slver 5y ago
  It's very hard to make Haskell look attractive to me, I deal with open systems (i.e. systems which interact with many other heterogenous systems which evolve in time), and Haskell is optimized for precisely the opposite case (a walled garden built out of elaborate types for verifying correctness). Haskell is the weird introvert guy in an extrovert world.
  - valenterry 5y ago
    Interesting - for me it is the opposite. Non-functional languages usually work better if there is no concurrency involved. And 3rd party systems always introduce a certain amount of concurrency, sometimes more, sometimes less. I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.
    - slver 5y ago
      > I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing. ... That's good in your opinion?
      - valenterry 5y ago
        If your program is simple and LoC are executed one by one and that is totally fine, then FP just takes away the natural relation between LoC and execution and adds another layer of unnecessary complexity. But when the percentage of concurrent code grows bigger, then it is better - because you lose the LoC<->execution relation anyways. You can for example see that in Python. Python makes it really hard to break out of that model and have a line of code running while another one is running. That's why paralle and async/concurrent programming is such a PITA in python. So, in my opinion for some problems the FP style is much better, because instead of "working your way around", you embrace the fact that LoC and execution are inherently decoupled.
  - tome 5y ago
    Hmm, not really. See, for example, Clash, a Haskell compiler for synthesising hardware circuits, or Cardano, a massively distributed software system realising a cryptocurrency.

by slver 5y ago

tome 5y ago

Well, give it a go! Or alternatively, look for languages that have been successful in enforcing any kind of purity and that also permit unrestricted use of higher order functions.

slver 5y ago
It's very hard to make Haskell look attractive to me, I deal with open systems (i.e. systems which interact with many other heterogenous systems which evolve in time), and Haskell is optimized for precisely the opposite case (a walled garden built out of elaborate types for verifying correctness). Haskell is the weird introvert guy in an extrovert world.
- valenterry 5y ago
  Interesting - for me it is the opposite. Non-functional languages usually work better if there is no concurrency involved. And 3rd party systems always introduce a certain amount of concurrency, sometimes more, sometimes less. I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.
  - slver 5y ago
    > I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing. ... That's good in your opinion?
    - valenterry 5y ago
      If your program is simple and LoC are executed one by one and that is totally fine, then FP just takes away the natural relation between LoC and execution and adds another layer of unnecessary complexity. But when the percentage of concurrent code grows bigger, then it is better - because you lose the LoC<->execution relation anyways. You can for example see that in Python. Python makes it really hard to break out of that model and have a line of code running while another one is running. That's why paralle and async/concurrent programming is such a PITA in python. So, in my opinion for some problems the FP style is much better, because instead of "working your way around", you embrace the fact that LoC and execution are inherently decoupled.
- tome 5y ago
  Hmm, not really. See, for example, Clash, a Haskell compiler for synthesising hardware circuits, or Cardano, a massively distributed software system realising a cryptocurrency.