9 ms·

Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. They had promises and async/await in 1995.

Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. They had promises and async/await in 1995. They're trailblazers that other languages can follow (like rust did). I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages. Still, as a language, Haskell is not ideal for teaching and productivity. There too many different ways of doing things (eg. strings, records); compiler errors need improvement, prelude has too many exceptions-throwing functions (eg. head); exceptions handling is not something I want in a pure language; ghc extensions change the language so much that using some extensions almost feel like having to learn another language. On documentation, I can't say I feel the need for it, but I understand some developers may be used to program against documentation and feel lost without it. I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX. The reason I stopped using Haskell is because I was bit by exception handling (which is a feature shared by many other languages, incidentally!) and by GC spikes. I still like Haskell, it's closest to my "ideal" language than any other, but for production Rust is more useable (albeit being a bit uglier)

dom96 6y ago
> They had promises and async/await in 1995. Really? Do you have a source on this? I was under the impression that C# was the pioneer here.
- jcelerier 6y ago
  promises, futures, etc... are much older - it takes 15 years for stuff pioneered in research to make it into general purpose langs :p - https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.pdf?1480599977=&response-content-disposition=inline%3B+filename%3DPromises_linguistic_support_for_efficien.pdf&Expires=1610200011&Signature=BEYyYwFDSL5eQAXnTHmvqVZh0MndxFKi0qmtUzmm1M41Zzk2uPeHTAwo9mMd74sTsn8Ap1W3yG15qYYOrUusIEWQ-ShmdVwWnm3x-bdQL4qrpS8Nq7M~mTM~pqSHquaG-~DqO7-dSvvFCsMqO3dJTg9rRxbkLnQSZdJoAOrJ~qSPm917gVCYLkqXSw-xTEP~oERVPe8i5DymDRssnIrCdl2BtgzY9ZiJP4rNdjHTYTby80hc-UHkNfUJ1RSQ6lXsuCDzZuBscwS1lZIN2452m1NUC6wCEv0vAw65Dix-mQt1ClZDpAtvpQfpBmbGEWUxtNLUdnt85slAlJoay6i1vg__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.p... - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.1841&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97....
- jokethrowaway 6y ago
  More precisely, I was referring to monads and do-notation with that phrase. Here are some references on when it was invented / implemented: https://www.reddit.com/r/haskell/comments/8rkrgq/when_was_donotation_introduced/ https://www.reddit.com/r/haskell/comments/8rkrgq/when_was_do... Also a JS gist on async/await and do-notation: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...
- arianvanp 6y ago
  Async/await is specialised syntax for a more generic concept of monads which haskell was the language in which this was heavily researched. Specifically continuation monad describes asynchronous computation (promises) and was one of the motivating examples In the early 90s going back all the way to Moggis original "notions of computations" paper from 1991 http://homepages.inf.ed.ac.uk/wadler/topics/monads.html http://homepages.inf.ed.ac.uk/wadler/topics/monads.html Async/await and LINQ were the brainchild of Erik Meijer. A haskell researcher. Also see https://news.ycombinator.com/item?id=25565229 https://news.ycombinator.com/item?id=25565229 from a recent discussion here. Specifically http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.868&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.... where Eric tells his story about bringing haskell concepts to .NET
  - daxfohl 6y ago
    Fwiw, c# wasn't even the first dotnet language with it. F# had async computation expressions a few years earlier.
    - sideeffffect 6y ago
      But F# doesn't have async/await. As you write, it has "computation expressions", which are inspired by Haskell's "do-notation", but are more generalised and powerful (than both Haskell's "do-notation" or Scala's "for-comprehension", let alone async/await). One of the things I liked best about F#.
      - daxfohl 6y ago
        Idk if you can strictly say that. Haskell allows more generalized do blocks because of HKTs. I blogged about this a few years ago. https://www.sparxeng.com/blog/software/higher-kinded-fun-in-haskell https://www.sparxeng.com/blog/software/higher-kinded-fun-in-.... (Granted, I've never had a use for that beyond code golf). And C# is nice because you can await anywhere in an expression instead of just at a "let!" declaration. This is something I do miss when using F#. But agreed, F# is usually my language of choice.
- paavohtl 6y ago
  Even though the concepts weren't invented for C#, you are technically correct in that C# pioneered the keywords async and await.
knuthsat 6y ago
Exactly. It's a research vehicle. Not everything in Haskell is useful for business or productivity. The reason I stopped using it is because of performance. Despite having state of the art optimizations there it's still too slow for my needs and writing fast code is way to hard compared to C++ or C. I was also quite disappointed to learn that a lot of useful concepts (Monad transformers/stacks) have a runtime performance impact when it looked to me like I was just playing with types.
- Quekid5 6y ago
  > It's a research vehicle. Well, it's also one that happens to make people lots and lots of money. Standard Chartered, for example, uses it extensively to earn lots of money. Facebook uses it for spam filtering logic. Niche, perhaps, but painting it as purely for research is just incorrect. Yes, it's not going to be great if all you're writing is integrations with various vendors using SOAP or just legacy or odd protocols. Those have libraries or code generators on the JVM/.Net/etc. platforms... not so much in Haskell. However, this has nothing to do with the language, it's just a matter of people actually doing the work to support those things. Everything else, though... you're golden. It has a learning curve, but there's a reason that Scala is moving ever closer to monads, adopting proper syntax for type classes, etc.
  - qwantim1 6y ago
    This is a good point. The language doesn’t have to be good to make money, in fact in can be quite bad. Oddly, while modern development embraces agility, many things often benefit from small changes, and a bad language has small change built-in. Why? Well, if the language is bad, you have to pay your developers well to retain them, since there are few that want to program in that language. The developer comes aboard because of the money and the challenge. Once they join the company and become a developer in a bad language, there are fewer alternatives for the developer to find another job in that bad language. This means that they have to stay around and get to know that bad language better, making to even harder for the business to hire others to help or replace them. So, the development doesn’t suffer as much from team scaling problems, and change can’t happen as quickly. This isn’t what you want for everything of course. Especially when talking with a VC about a startup. But JS, an ok language, has gotten to a similar level of nonsense through the difficulty and complexity of its rapidly changing ecosystem and changing browsers. And few languages have really avoided unnecessary difficulty over time in their ecosystems.
Blikkentrekker 6y ago
> prelude has unsafe functions (eg. head), `head` is not unsafe, it is a partial function. An unsafe function can lead to u.b.; the behavior of `head` on an empty list is very much defined. Haskell is not a total language.
- jokethrowaway 6y ago
  Thanks for the correction, changed to exception-throwing - that's the behaviour I don't like
  - Quekid5 6y ago
    I think it's worth pointing out that your values[0] may not align with Haskell's values. That's absolutely fine, but it doesn't mean that Haskell is "bad" in some objective sense. AFAICT, most of your 'complaints' would apply equally to, say, Java or C#. [0] I can't recall which exact presentation it was, but Bryan Cantrill had a brilliant segment on this in one of them. Perhaps others around here can remember?
    - girvo 6y ago
      They didn’t argue that it was “bad in some objective sense”, they pointed out a feature in Haskell that they specifically don’t like. Unless you consider Haskell to be a perfect language, discarding an opinion that was labeled as exactly that seems silly to me. Especially with such a broad strokes “love it or leave it” reply... Those complaints apply to those languages too, yes. What’s your point here?
      - Quekid5 6y ago
        I may have overreacted to the title of the blog post and carried that over to the post I replied to :). That's my bad.
    - codesections 6y ago
      > I can't recall which exact presentation it was, but Bryan Cantrill had a brilliant segment on this in one of them. Perhaps others around here can remember? I think that's his discussion of language values in "Rust and Other Interesting Things" at Scale By The Bay 2018. https://www.youtube.com/watch?v=2wZ1pCpJUIM https://www.youtube.com/watch?v=2wZ1pCpJUIM [edit: This talk is also titled "Platform values, Rust, and implications for systems software". I'm not sure which title is preferred.]
dan00 6y ago
> I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages. In a way Cabal 3 is even ahead of cargo, by being able of sharing build libraries between different projects and still having a sandbox like build for each project. > There too many different ways of doing things (eg. strings, records), compiler errors need improvement, prelude has unsafe functions (eg. head), exceptions handling is not something I want in a pure language, ghc extensions change the language so much that using some extensions almost feel like having to learn another language. For such a self called safe language, some things are almost comedy like, like getting exceptions for uninitialised record fields or unhandled alternatives in case expressions. But Haskell still has a place in my heart and I‘m still following its development. But for my side projects Rust has replaced it, by being at some things even safer, but foremost safe at the places it‘s most important for me and also quite a bit more pragmatic. For me Rust combines the best parts of Haskell and C++.
- Ericson2314 6y ago
  > some things are almost comedy We're trying to fix that! https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351
blippage 6y ago
> Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. It's somewhat facetious motto is "Avoid success at all cost".
- yrimaxi 6y ago
  Avoid $ success at all costs
  - ernst_klim 6y ago
    I dunno why people downvote, obviously this means Avoid (success at all costs)
_query 6y ago
> I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX. This is very true. We recently started https://github.com/digitallyinduced/haskell-ux https://github.com/digitallyinduced/haskell-ux to keep track of haskell DX improvements. Some of our suggestions are already issues on the GHC (haskell compiler) bug tracker. Here's an example of a great UX improvement in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4711 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4711
- ludamad 6y ago
  Good to see that the article is at least underselling that people are actively working on this
ookdatnog 6y ago
> Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. You rightfully point to Rust, which took a lot of inspiration from Haskell, but I think it's worth emphasizing just how much of the progress in programming languages in the last two decades was inspired by functional programming (many features were not invented in Haskell, but some like type inference were popularized by it). For example: proper type inference, algebraic data types (enums in Rust) and consequently option types, pattern matching, property-based testing, immutability by default, parametric polymorphism (generics), ad-hoc polymorphism (type classes/traits/...), first class functions (very old idea but only recently common in mainstream languages), ...
- pjmlp 6y ago
  I learned type inference in Caml Light, Haskell was still Miranda back then, and I bet any language designer of all major languages has similar backgrounds in regards to ML type inference. Even type classe ideas can be found in CLU, ML, Objective-C, before the paper that gave origin to their adoption in Haskell.
  - Quekid5 6y ago
    For history buffs: https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy... was invented in 1969 (and rediscovered my Milner in 1978). AFAIK, that was the basis of type inference in many of the non-mainstream languages before they branched off into their own more powerful type systems.
- brabel 6y ago
  The Rust docs claim most things actually came from ML and OCaml: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html They only mention Haskell's type classes and type families as inspiring a Rust feature directly (traits).
  - yen223 6y ago
pjmlp 6y ago
> It's not as good and polished as rust's cargo but it's ahead several other languages. Until cargo supports sharing of binary crates it isn't as polished as I care about. All the languages I use, except for scripting languages, support distribution of binary artifacts, including Haskell.
agentultra 6y ago
Hi. I am a professional software developer and my full time job is currently writing software in Haskell for a bank. I also stream projects and open source work I do in Haskell once a week. I am not a researcher. I don’t have a horse in that race. Although I am thankful for the research that is done as things like STM and type system extensions benefit my work greatly. I really wish Haskell could shed this meme that it’s a “research,” language and that, “nobody uses it.” I’m Nobody. I use Haskell every day. It’s a practical language for industrial strength programming in a pure functional language.
- jokethrowaway 6y ago
  The fact that Haskell is a good industrial strength language is a byproduct of its quest for language design excellence. Avoid success at all cost, implies an unwillingness to sacrifice on design to please corporate needs. I don't think it's a "meme", there really is a focus on research over being production ready. Monads, Arrows, Dependent Types - Haskell is where a lot language research happens (and the language chosen by a lot of researchers). Sure, you can ship Haskell in production if you're happy to fill in the gaps. I did some of that for a non-Haskell company and it wasn't as easy to deploy apps written in other languages and community-provided solutions for logging / monitoring were lacking. That said, I'm always happy to hear about people using Haskell in production and wish you the best
whereistimbo 6y ago
But since industries used Haskell, now they are concerned with backward compatibility, which AFAIK makes some parts of Haskell ugly. I wish there would be something like RHEL/Fedora model rather than letting Simon Peyton Jones being dictated by industry by ceding towards backward compatibility.
kazinator 6y ago
> async/await in 1995 Unix had fork and wait before 1979. Unix shell: # run some commands asynchronously $ command1 & $ command2 & $ command3 & # wait for all of them $ wait
- OskarS 6y ago
  Multiprocessing and parallel programming is a different thing from async/await, which primarily has to do with with green threads and coroutines. You're right that the ideas go way back (hell, Knuth was writing about coroutines in TAoCP in the 70s!), but this does not qualify.
  - kazinator 6y ago
    Unix was originally green threads, at least in kernel mode: it was a non-preemptable kernel running on a uniprocessor. This means that kernel code ran until hitting a voluntary context switch. User space was preemptible. (User space being preemptible doesn't really make a semantic difference to the shell & and wait examples, unless some of the commands contain lengthy CPU-bound loops.)

dom96 6y ago

> They had promises and async/await in 1995. Really? Do you have a source on this? I was under the impression that C# was the pioneer here.

jcelerier 6y ago
promises, futures, etc... are much older - it takes 15 years for stuff pioneered in research to make it into general purpose langs :p - https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.pdf?1480599977=&response-content-disposition=inline%3B+filename%3DPromises_linguistic_support_for_efficien.pdf&Expires=1610200011&Signature=BEYyYwFDSL5eQAXnTHmvqVZh0MndxFKi0qmtUzmm1M41Zzk2uPeHTAwo9mMd74sTsn8Ap1W3yG15qYYOrUusIEWQ-ShmdVwWnm3x-bdQL4qrpS8Nq7M~mTM~pqSHquaG-~DqO7-dSvvFCsMqO3dJTg9rRxbkLnQSZdJoAOrJ~qSPm917gVCYLkqXSw-xTEP~oERVPe8i5DymDRssnIrCdl2BtgzY9ZiJP4rNdjHTYTby80hc-UHkNfUJ1RSQ6lXsuCDzZuBscwS1lZIN2452m1NUC6wCEv0vAw65Dix-mQt1ClZDpAtvpQfpBmbGEWUxtNLUdnt85slAlJoay6i1vg__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.p... - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.1841&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97....
jokethrowaway 6y ago
More precisely, I was referring to monads and do-notation with that phrase. Here are some references on when it was invented / implemented: https://www.reddit.com/r/haskell/comments/8rkrgq/when_was_donotation_introduced/ https://www.reddit.com/r/haskell/comments/8rkrgq/when_was_do... Also a JS gist on async/await and do-notation: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb1376c80 https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...
arianvanp 6y ago
Async/await is specialised syntax for a more generic concept of monads which haskell was the language in which this was heavily researched. Specifically continuation monad describes asynchronous computation (promises) and was one of the motivating examples In the early 90s going back all the way to Moggis original "notions of computations" paper from 1991 http://homepages.inf.ed.ac.uk/wadler/topics/monads.html http://homepages.inf.ed.ac.uk/wadler/topics/monads.html Async/await and LINQ were the brainchild of Erik Meijer. A haskell researcher. Also see https://news.ycombinator.com/item?id=25565229 https://news.ycombinator.com/item?id=25565229 from a recent discussion here. Specifically http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.868&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.... where Eric tells his story about bringing haskell concepts to .NET
- daxfohl 6y ago
  Fwiw, c# wasn't even the first dotnet language with it. F# had async computation expressions a few years earlier.
  - sideeffffect 6y ago
    But F# doesn't have async/await. As you write, it has "computation expressions", which are inspired by Haskell's "do-notation", but are more generalised and powerful (than both Haskell's "do-notation" or Scala's "for-comprehension", let alone async/await). One of the things I liked best about F#.
    - daxfohl 6y ago
      Idk if you can strictly say that. Haskell allows more generalized do blocks because of HKTs. I blogged about this a few years ago. https://www.sparxeng.com/blog/software/higher-kinded-fun-in-haskell https://www.sparxeng.com/blog/software/higher-kinded-fun-in-.... (Granted, I've never had a use for that beyond code golf). And C# is nice because you can await anywhere in an expression instead of just at a "let!" declaration. This is something I do miss when using F#. But agreed, F# is usually my language of choice.
paavohtl 6y ago
Even though the concepts weren't invented for C#, you are technically correct in that C# pioneered the keywords async and await.

knuthsat 6y ago

Exactly. It's a research vehicle. Not everything in Haskell is useful for business or productivity. The reason I stopped using it is because of performance. Despite having state of the art optimizations there it's still too slow for my needs and writing fast code is way to hard compared to C++ or C. I was also quite disappointed to learn that a lot of useful concepts (Monad transformers/stacks) have a runtime performance impact when it looked to me like I was just playing with types.

Quekid5 6y ago
> It's a research vehicle. Well, it's also one that happens to make people lots and lots of money. Standard Chartered, for example, uses it extensively to earn lots of money. Facebook uses it for spam filtering logic. Niche, perhaps, but painting it as purely for research is just incorrect. Yes, it's not going to be great if all you're writing is integrations with various vendors using SOAP or just legacy or odd protocols. Those have libraries or code generators on the JVM/.Net/etc. platforms... not so much in Haskell. However, this has nothing to do with the language, it's just a matter of people actually doing the work to support those things. Everything else, though... you're golden. It has a learning curve, but there's a reason that Scala is moving ever closer to monads, adopting proper syntax for type classes, etc.
- qwantim1 6y ago
  This is a good point. The language doesn’t have to be good to make money, in fact in can be quite bad. Oddly, while modern development embraces agility, many things often benefit from small changes, and a bad language has small change built-in. Why? Well, if the language is bad, you have to pay your developers well to retain them, since there are few that want to program in that language. The developer comes aboard because of the money and the challenge. Once they join the company and become a developer in a bad language, there are fewer alternatives for the developer to find another job in that bad language. This means that they have to stay around and get to know that bad language better, making to even harder for the business to hire others to help or replace them. So, the development doesn’t suffer as much from team scaling problems, and change can’t happen as quickly. This isn’t what you want for everything of course. Especially when talking with a VC about a startup. But JS, an ok language, has gotten to a similar level of nonsense through the difficulty and complexity of its rapidly changing ecosystem and changing browsers. And few languages have really avoided unnecessary difficulty over time in their ecosystems.

Blikkentrekker 6y ago

> prelude has unsafe functions (eg. head), `head` is not unsafe, it is a partial function. An unsafe function can lead to u.b.; the behavior of `head` on an empty list is very much defined. Haskell is not a total language.

jokethrowaway 6y ago
Thanks for the correction, changed to exception-throwing - that's the behaviour I don't like
- Quekid5 6y ago
  I think it's worth pointing out that your values[0] may not align with Haskell's values. That's absolutely fine, but it doesn't mean that Haskell is "bad" in some objective sense. AFAICT, most of your 'complaints' would apply equally to, say, Java or C#. [0] I can't recall which exact presentation it was, but Bryan Cantrill had a brilliant segment on this in one of them. Perhaps others around here can remember?
  - girvo 6y ago
    They didn’t argue that it was “bad in some objective sense”, they pointed out a feature in Haskell that they specifically don’t like. Unless you consider Haskell to be a perfect language, discarding an opinion that was labeled as exactly that seems silly to me. Especially with such a broad strokes “love it or leave it” reply... Those complaints apply to those languages too, yes. What’s your point here?
    - Quekid5 6y ago
      I may have overreacted to the title of the blog post and carried that over to the post I replied to :). That's my bad.
  - codesections 6y ago
    > I can't recall which exact presentation it was, but Bryan Cantrill had a brilliant segment on this in one of them. Perhaps others around here can remember? I think that's his discussion of language values in "Rust and Other Interesting Things" at Scale By The Bay 2018. https://www.youtube.com/watch?v=2wZ1pCpJUIM https://www.youtube.com/watch?v=2wZ1pCpJUIM [edit: This talk is also titled "Platform values, Rust, and implications for systems software". I'm not sure which title is preferred.]

dan00 6y ago

> I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages. In a way Cabal 3 is even ahead of cargo, by being able of sharing build libraries between different projects and still having a sandbox like build for each project. > There too many different ways of doing things (eg. strings, records), compiler errors need improvement, prelude has unsafe functions (eg. head), exceptions handling is not something I want in a pure language, ghc extensions change the language so much that using some extensions almost feel like having to learn another language. For such a self called safe language, some things are almost comedy like, like getting exceptions for uninitialised record fields or unhandled alternatives in case expressions. But Haskell still has a place in my heart and I‘m still following its development. But for my side projects Rust has replaced it, by being at some things even safer, but foremost safe at the places it‘s most important for me and also quite a bit more pragmatic. For me Rust combines the best parts of Haskell and C++.

Ericson2314 6y ago
> some things are almost comedy We're trying to fix that! https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351

blippage 6y ago

> Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. It's somewhat facetious motto is "Avoid success at all cost".

yrimaxi 6y ago
Avoid $ success at all costs
- ernst_klim 6y ago
  I dunno why people downvote, obviously this means Avoid (success at all costs)

_query 6y ago

> I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX. This is very true. We recently started https://github.com/digitallyinduced/haskell-ux https://github.com/digitallyinduced/haskell-ux to keep track of haskell DX improvements. Some of our suggestions are already issues on the GHC (haskell compiler) bug tracker. Here's an example of a great UX improvement in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4711 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4711

ludamad 6y ago
Good to see that the article is at least underselling that people are actively working on this

ookdatnog 6y ago

> Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research. You rightfully point to Rust, which took a lot of inspiration from Haskell, but I think it's worth emphasizing just how much of the progress in programming languages in the last two decades was inspired by functional programming (many features were not invented in Haskell, but some like type inference were popularized by it). For example: proper type inference, algebraic data types (enums in Rust) and consequently option types, pattern matching, property-based testing, immutability by default, parametric polymorphism (generics), ad-hoc polymorphism (type classes/traits/...), first class functions (very old idea but only recently common in mainstream languages), ...

pjmlp 6y ago
I learned type inference in Caml Light, Haskell was still Miranda back then, and I bet any language designer of all major languages has similar backgrounds in regards to ML type inference. Even type classe ideas can be found in CLU, ML, Objective-C, before the paper that gave origin to their adoption in Haskell.
- Quekid5 6y ago
  For history buffs: https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy... was invented in 1969 (and rediscovered my Milner in 1978). AFAIK, that was the basis of type inference in many of the non-mainstream languages before they branched off into their own more powerful type systems.
brabel 6y ago
The Rust docs claim most things actually came from ML and OCaml: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html They only mention Haskell's type classes and type families as inspiring a Rust feature directly (traits).
- yen223 6y ago

pjmlp 6y ago

> It's not as good and polished as rust's cargo but it's ahead several other languages. Until cargo supports sharing of binary crates it isn't as polished as I care about. All the languages I use, except for scripting languages, support distribution of binary artifacts, including Haskell.

agentultra 6y ago

Hi. I am a professional software developer and my full time job is currently writing software in Haskell for a bank. I also stream projects and open source work I do in Haskell once a week. I am not a researcher. I don’t have a horse in that race. Although I am thankful for the research that is done as things like STM and type system extensions benefit my work greatly. I really wish Haskell could shed this meme that it’s a “research,” language and that, “nobody uses it.” I’m Nobody. I use Haskell every day. It’s a practical language for industrial strength programming in a pure functional language.

jokethrowaway 6y ago
The fact that Haskell is a good industrial strength language is a byproduct of its quest for language design excellence. Avoid success at all cost, implies an unwillingness to sacrifice on design to please corporate needs. I don't think it's a "meme", there really is a focus on research over being production ready. Monads, Arrows, Dependent Types - Haskell is where a lot language research happens (and the language chosen by a lot of researchers). Sure, you can ship Haskell in production if you're happy to fill in the gaps. I did some of that for a non-Haskell company and it wasn't as easy to deploy apps written in other languages and community-provided solutions for logging / monitoring were lacking. That said, I'm always happy to hear about people using Haskell in production and wish you the best

whereistimbo 6y ago

But since industries used Haskell, now they are concerned with backward compatibility, which AFAIK makes some parts of Haskell ugly. I wish there would be something like RHEL/Fedora model rather than letting Simon Peyton Jones being dictated by industry by ceding towards backward compatibility.

kazinator 6y ago

> async/await in 1995 Unix had fork and wait before 1979. Unix shell: # run some commands asynchronously $ command1 & $ command2 & $ command3 & # wait for all of them $ wait

OskarS 6y ago
Multiprocessing and parallel programming is a different thing from async/await, which primarily has to do with with green threads and coroutines. You're right that the ideas go way back (hell, Knuth was writing about coroutines in TAoCP in the 70s!), but this does not qualify.
- kazinator 6y ago
  Unix was originally green threads, at least in kernel mode: it was a non-preemptable kernel running on a uniprocessor. This means that kernel code ran until hitting a voluntary context switch. User space was preemptible. (User space being preemptible doesn't really make a semantic difference to the shell & and wait examples, unless some of the commands contain lengthy CPU-bound loops.)