4 ms·

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

by 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

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.