5 ms·

Haskell is an oddball in that it’s an older language, created in the 90s, IIRC a year before Java, with concepts so cutting edge that it was utterly useless. In

Haskell is an oddball in that it’s an older language, created in the 90s, IIRC a year before Java, with concepts so cutting edge that it was utterly useless. Initially they hadn’t even worked out how to do IO. Probably it’s only been useable in industry for maybe 10 years. So Haskell is relatively old, but you’re unlikely to encounter a lot of old projects written in Haskell. Also, there’s a lot of hype about how difficult it is, I believe this has a lot to do with how different it is from popular languages people already know. In my experience, once learned it can be hard to go back to other development styles.

mrkeen 6y ago
> Initially they hadn’t even worked out how to do IO. I tried to find some date by which they'd figured it out, the best I can do is 1992[1]. To put it another way, Haskell's had a great story around IO for 29 years, or longer than Java's been around. All the modern future/io/concurrency frameworks have followed suit. We construct objects representing computations and we flatMap them together, which is all the IO monad is. Although for some reason the syntax from last millennium hasn't made it into the modern languages: str1 <- readFile file1 str2 <- readFile file2 let str3 = str1 ++ str2 writeFile file3 str3 vs: readFile(file1).flatMap(str1 -> { readFile(file2).flatMap(str2 -> { String str3 = str1 + str2; return writeFile(file3, str3); }}); [1] https://www.haskell.org/ghc/docs/papers/imperative.ps.gz https://www.haskell.org/ghc/docs/papers/imperative.ps.gz
- astrange 6y ago
  The popular syntax for this in newer imperative languages seems to be async/await, although I think I only like Swift's implementation. (unfair statement since I haven't used the rest much)
  - aranchelk 6y ago
    The cool thing about the syntax in Haskell is it’s not tied specifically to async, you can use it for synchronous IO, business logic, parsers, etc. It makes for small context switches when working on different parts of an application.
    - astrange 6y ago
      To adopt it in other languages don't you need non-strict evaluation, at which point it's hard to stop yourself from becoming Haskell?
      - aranchelk 6y ago
        Certain idioms in Haskell rely on laziness, but thankfully monads and do notation do not. They’re used in PureScript which is strict.
- aranchelk 6y ago
  > Haskell's had a great story around IO for 29 years, or longer than Java's been around. I like that a lot. I did not realize that problem was solved so early on. The things I was thinking of were more like good application frameworks, database libraries, etc. all the stuff you need to build commercial products and that you might have trouble justifying developing on an investor’s/shareholders’ dime.
- mavelikara 6y ago
  > To put it another way, Haskell's had a great story around IO for 29 years, or longer than Java's been around. That is a tall claim. LazyIO has been problematic in Haskell well into the 2010's until Iteratees became well-understood.
  - mavelikara 6y ago
    Care to explain the downvote? From Oleg Kiselyov's 2012 paper Iteratees [1]: Lazy IO is so irresistible that it was added to Haskell despite the reservations of its inventors and the failure to develop good techniques for reasoning about its correctness [7, Sec 10.5]. However benign, reading is an observable side-effect, whose occurrence may have to be correlated with other side effects. Such correlations are crucial when performing IO over communication pipes, which is typical of web servers.3 As Launchbury and Peyton Jones feared, Lazy IO indeed "gives rise to a very subtle class of programming errors". We have seen deadlocks; mishandling of IO errors; running out of file descriptors and similar scarce resources; unpredictable, volatile and sometimes unbearably excessive use of memory. We illustrate the splendors and miseries of Lazy IO in §2. This is a very famous Haskell programer's opinion on the default IO in Haskell, and he quotes that one of the main creators of the language himself anticipated such problems [2]. Why downvote a comment in 2021 challenging the claim that "Haskell's had a great story around IO for 29 years"? [1]: http://okmij.org/ftp/Haskell/Iteratee/describe.pdf http://okmij.org/ftp/Haskell/Iteratee/describe.pdf [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/state-lasc.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
    - tome 6y ago
      Iteratees (nowadays pipes, conduit etc.) are based on functionality that was already there in 1992. They didn't add anything to Haskell. They're just libraries. Lazy IO has indeed always been bad but it wasn't the only part of Haskell's IO story.
      - dllthomas 6y ago
        Lazy IO is great where lazy IO is great! Long running processes handling lots of different requests, not so much, and that's made up an increasing amount of what people want to do. But for "open a file, chew through it, errors when consuming it might as well take down the process" nothing could be easier.

mrkeen 6y ago

> Initially they hadn’t even worked out how to do IO. I tried to find some date by which they'd figured it out, the best I can do is 1992[1]. To put it another way, Haskell's had a great story around IO for 29 years, or longer than Java's been around. All the modern future/io/concurrency frameworks have followed suit. We construct objects representing computations and we flatMap them together, which is all the IO monad is. Although for some reason the syntax from last millennium hasn't made it into the modern languages: str1 <- readFile file1 str2 <- readFile file2 let str3 = str1 ++ str2 writeFile file3 str3 vs: readFile(file1).flatMap(str1 -> { readFile(file2).flatMap(str2 -> { String str3 = str1 + str2; return writeFile(file3, str3); }}); [1] https://www.haskell.org/ghc/docs/papers/imperative.ps.gz https://www.haskell.org/ghc/docs/papers/imperative.ps.gz

astrange 6y ago
The popular syntax for this in newer imperative languages seems to be async/await, although I think I only like Swift's implementation. (unfair statement since I haven't used the rest much)
- aranchelk 6y ago
  The cool thing about the syntax in Haskell is it’s not tied specifically to async, you can use it for synchronous IO, business logic, parsers, etc. It makes for small context switches when working on different parts of an application.
  - astrange 6y ago
    To adopt it in other languages don't you need non-strict evaluation, at which point it's hard to stop yourself from becoming Haskell?
    - aranchelk 6y ago
      Certain idioms in Haskell rely on laziness, but thankfully monads and do notation do not. They’re used in PureScript which is strict.
aranchelk 6y ago
> Haskell's had a great story around IO for 29 years, or longer than Java's been around. I like that a lot. I did not realize that problem was solved so early on. The things I was thinking of were more like good application frameworks, database libraries, etc. all the stuff you need to build commercial products and that you might have trouble justifying developing on an investor’s/shareholders’ dime.
mavelikara 6y ago
> To put it another way, Haskell's had a great story around IO for 29 years, or longer than Java's been around. That is a tall claim. LazyIO has been problematic in Haskell well into the 2010's until Iteratees became well-understood.
- mavelikara 6y ago
  Care to explain the downvote? From Oleg Kiselyov's 2012 paper Iteratees [1]: Lazy IO is so irresistible that it was added to Haskell despite the reservations of its inventors and the failure to develop good techniques for reasoning about its correctness [7, Sec 10.5]. However benign, reading is an observable side-effect, whose occurrence may have to be correlated with other side effects. Such correlations are crucial when performing IO over communication pipes, which is typical of web servers.3 As Launchbury and Peyton Jones feared, Lazy IO indeed "gives rise to a very subtle class of programming errors". We have seen deadlocks; mishandling of IO errors; running out of file descriptors and similar scarce resources; unpredictable, volatile and sometimes unbearably excessive use of memory. We illustrate the splendors and miseries of Lazy IO in §2. This is a very famous Haskell programer's opinion on the default IO in Haskell, and he quotes that one of the main creators of the language himself anticipated such problems [2]. Why downvote a comment in 2021 challenging the claim that "Haskell's had a great story around IO for 29 years"? [1]: http://okmij.org/ftp/Haskell/Iteratee/describe.pdf http://okmij.org/ftp/Haskell/Iteratee/describe.pdf [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/state-lasc.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
  - tome 6y ago
    Iteratees (nowadays pipes, conduit etc.) are based on functionality that was already there in 1992. They didn't add anything to Haskell. They're just libraries. Lazy IO has indeed always been bad but it wasn't the only part of Haskell's IO story.
    - dllthomas 6y ago
      Lazy IO is great where lazy IO is great! Long running processes handling lots of different requests, not so much, and that's made up an increasing amount of what people want to do. But for "open a file, chew through it, errors when consuming it might as well take down the process" nothing could be easier.