5 ms·

> majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fund

by psibi 12y ago

> majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?

jbooth 12y ago
I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.
- tree_of_item 12y ago
  I don't think they are acknowledging any impedance mismatch there. The point of that paragraph is to emphasize that Haskell retains the usual feel of imperative programming, with the important difference that the imperative bits of your code are cleanly separated from the pure bits due to the IO type. There's no theoretical stuff here, it's just making sure that the caller knows about callees having side effects.
- imanaccount247 12y ago
  >At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. No, you have a tiny, very simple type that allows for type safe IO. It also happens to make haskell a more powerful imperative language than most imperative languages, as IO actions are first class and can be passed around and manipulated like anything else. >So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere) No, they acknowledge that doing IO is so important that it should be done correctly. You are going to some pretty extreme mental gymnastics to misrepresent a language you want to hate.
  - yarou 12y ago
    To be fair, understanding I/O in Haskell takes quite a bit of mental gymnastics. :) The I/O monad modifies the Universe that contains the set of all functions that comprise your program (if I even understand the concept correctly).
    - tome 12y ago
      > The I/O monad modifies the Universe that contains the set of all functions that comprise your program That sounds rather complicated. My way of thinking of it is simpler than that. a -> IO b is just a function from a to b that can do some I/O. Nothing more complicated than that.
      - wbillingsley 12y ago
        It is (slightly) more complicated than that. Your return type is not b but IO b. Your callers will be performing functions that are defined on IO b with the result (such as bind)
      - SamReidHughes 12y ago
        I recommend just regarding IO a as an action, or some description of an action, that returns a value of type a. And (>>=) constructs bigger actions by attaching continuations to actions.
- deleted 12y ago
  [deleted]
- rastapasta42 12y ago
  Clearly you have no idea what you're talking about. I suggest first learning the language before spreading FUD about it. Separation of pure and unpure components greatly simplifies the reasoning about the problem domain. Traditional imperative programs are often full of subtle bugs because calling a procedure can have arbitrary effect on your system. For example calling function with the same arguments can return different values based on arbitrary hard-to-track reasons (such as your OS's scheduler). It's just too much details to keep in your head. But in Haskell pure functions are guaranteed to have same result with same input. It enables the programmer to create logically isolated blocks without messy interdependencies. It's especially helpful for concurrent programming by freeing you from all the non-deterministic spaghetti. Haskell has a steep learning curve, but it'll make you a better programmer in the long run.
  - nbevans 12y ago
    "But in Haskell pure functions are guaranteed to have same result with same input." I'm pretty sure that same law applies to a pure function in any language, not just Haskell. #shitthatHNsays
    - codygman 12y ago
      Correct. Though many languages don't encourage and as a result don't have nearly as many pure functions as Haskell code.
      - guscost 12y ago
        In fairness, I could also say that hammers don't encourage carpentry best practices and as a result they cause many more smashed fingers than wood glue. The fact that a tool doesn't prevent counterproductive usage patterns doesn't automatically make it inappropriate for every job.
      - jbooth 12y ago
        Point being, I/O doesn't square with that concept. For some reason, every time I point this out, I'm accused of not appreciating the beauty of pure functions. I love pure functions. Maybe they're not appreciating the ugly reality of I/O?

by psibi 12y ago

> majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?

jbooth 12y ago

I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.

tree_of_item 12y ago
I don't think they are acknowledging any impedance mismatch there. The point of that paragraph is to emphasize that Haskell retains the usual feel of imperative programming, with the important difference that the imperative bits of your code are cleanly separated from the pure bits due to the IO type. There's no theoretical stuff here, it's just making sure that the caller knows about callees having side effects.
imanaccount247 12y ago
>At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. No, you have a tiny, very simple type that allows for type safe IO. It also happens to make haskell a more powerful imperative language than most imperative languages, as IO actions are first class and can be passed around and manipulated like anything else. >So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere) No, they acknowledge that doing IO is so important that it should be done correctly. You are going to some pretty extreme mental gymnastics to misrepresent a language you want to hate.
- yarou 12y ago
  To be fair, understanding I/O in Haskell takes quite a bit of mental gymnastics. :) The I/O monad modifies the Universe that contains the set of all functions that comprise your program (if I even understand the concept correctly).
  - tome 12y ago
    > The I/O monad modifies the Universe that contains the set of all functions that comprise your program That sounds rather complicated. My way of thinking of it is simpler than that. a -> IO b is just a function from a to b that can do some I/O. Nothing more complicated than that.
    - wbillingsley 12y ago
      It is (slightly) more complicated than that. Your return type is not b but IO b. Your callers will be performing functions that are defined on IO b with the result (such as bind)
    - SamReidHughes 12y ago
      I recommend just regarding IO a as an action, or some description of an action, that returns a value of type a. And (>>=) constructs bigger actions by attaching continuations to actions.
deleted 12y ago
[deleted]
rastapasta42 12y ago
Clearly you have no idea what you're talking about. I suggest first learning the language before spreading FUD about it. Separation of pure and unpure components greatly simplifies the reasoning about the problem domain. Traditional imperative programs are often full of subtle bugs because calling a procedure can have arbitrary effect on your system. For example calling function with the same arguments can return different values based on arbitrary hard-to-track reasons (such as your OS's scheduler). It's just too much details to keep in your head. But in Haskell pure functions are guaranteed to have same result with same input. It enables the programmer to create logically isolated blocks without messy interdependencies. It's especially helpful for concurrent programming by freeing you from all the non-deterministic spaghetti. Haskell has a steep learning curve, but it'll make you a better programmer in the long run.
- nbevans 12y ago
  "But in Haskell pure functions are guaranteed to have same result with same input." I'm pretty sure that same law applies to a pure function in any language, not just Haskell. #shitthatHNsays
  - codygman 12y ago
    Correct. Though many languages don't encourage and as a result don't have nearly as many pure functions as Haskell code.
    - guscost 12y ago
      In fairness, I could also say that hammers don't encourage carpentry best practices and as a result they cause many more smashed fingers than wood glue. The fact that a tool doesn't prevent counterproductive usage patterns doesn't automatically make it inappropriate for every job.
    - jbooth 12y ago
      Point being, I/O doesn't square with that concept. For some reason, every time I point this out, I'm accused of not appreciating the beauty of pure functions. I love pure functions. Maybe they're not appreciating the ugly reality of I/O?