4 ms·

Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. The operative point is that, in Haskell, firstly

by tome 5y ago

Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. The operative point is that, in Haskell, firstly x = expression y = expression ... is the same as x = expression y = x ... and that, secondly x = expression ... is the same as ... when x does not appear in ... . Those are the important properties of Haskell (with regard to this discussion). Whether this advances the discussion is another matter ...

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.
pflanze 5y ago
> Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. It's what the current discussion is about, since I explained why I explicitly didn't make a statement about immutability being required for FP. > The operative point is that, in Haskell, firstly > x = expression > y = expression > ... > is the same as > x = expression > y = x > ... Sure but that's the pure part of a program. x <- expression y <- expression is not generally the same as x <- expression let y = x in ... and I pointed out that you can have such a program (i.e. with mutability) inside a function that is pure to the outside. The interesting feature of Haskell / Monads is that you can have mutability be both inside and around pure expressions (impure code making use of pure code and then impure code again inside the implementation of pure code). Not everything in a Haskell program needs to be pure. Of course, pure expressions are good since they are easier to reason about. Also, they are the core idea of FP as I mentioned earlier. But, I want to avoid people taking away the impression that you then never can use mutable data structures, and that's why in my original comment I didn't make a statement about immutability being required for functional programming. Functional programming has a core idea and that is pure expressions (referential transparency), and then features to help increase the area of programs which are pure expressions and increase the confidence / safety of them being so. With regards to that confidence, Haskell goes far (there's still unsafePerformIO (and non-total functions) so it's not completely perfect). And I'm not disputing that when I say that it still is and always was called functional programming when there were no language-provided features to give that confidence, or only "half-assed" ones if one wants to call them that. Or only culture and convention. My point in the whole discussion is to explain why functional programming doesn't mean the same thing for everyone, and how it can both be that @slver says "there's no clear definition of FP" and that there is at the same time. There is a clear definition for referential transparency, which is the core idea of FP. But the term FP also encompasses various approaches and tools with varying qualities to enable that core idea, and it's here where there's no clear definition.

by tome 5y ago

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.

pflanze 5y ago

> Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. It's what the current discussion is about, since I explained why I explicitly didn't make a statement about immutability being required for FP. > The operative point is that, in Haskell, firstly > x = expression > y = expression > ... > is the same as > x = expression > y = x > ... Sure but that's the pure part of a program. x <- expression y <- expression is not generally the same as x <- expression let y = x in ... and I pointed out that you can have such a program (i.e. with mutability) inside a function that is pure to the outside. The interesting feature of Haskell / Monads is that you can have mutability be both inside and around pure expressions (impure code making use of pure code and then impure code again inside the implementation of pure code). Not everything in a Haskell program needs to be pure. Of course, pure expressions are good since they are easier to reason about. Also, they are the core idea of FP as I mentioned earlier. But, I want to avoid people taking away the impression that you then never can use mutable data structures, and that's why in my original comment I didn't make a statement about immutability being required for functional programming. Functional programming has a core idea and that is pure expressions (referential transparency), and then features to help increase the area of programs which are pure expressions and increase the confidence / safety of them being so. With regards to that confidence, Haskell goes far (there's still unsafePerformIO (and non-total functions) so it's not completely perfect). And I'm not disputing that when I say that it still is and always was called functional programming when there were no language-provided features to give that confidence, or only "half-assed" ones if one wants to call them that. Or only culture and convention. My point in the whole discussion is to explain why functional programming doesn't mean the same thing for everyone, and how it can both be that @slver says "there's no clear definition of FP" and that there is at the same time. There is a clear definition for referential transparency, which is the core idea of FP. But the term FP also encompasses various approaches and tools with varying qualities to enable that core idea, and it's here where there's no clear definition.