6 ms·

From my experience Haskellers spend more time talking about how perfect and pure Haskell is than building real-world applications.

dmix 7y ago
Which doesn't necessarily mean it's not useful for building real world things. Lumi [1][2] was built with Haskell (and PureScript) and looks like a great product. To me it just means more people need to a) build more real things in Haskell b) write about their experience and help advance the state for non-academic newbies and professionals c) avoid the weeds of the language theory stuff and stick the simple established stuff to stay productive (which does exist). You could also make the same argument for JavaScript. So many people are trying to reinvent the wheel every other week in the frontend world, it's just as easy to get distracted by the language/framework noise. Just be a mature developer and don't get suckered into the latest shiny objects. [1] https://www.lumi.com/ https://www.lumi.com/ [2] https://www.lumi.dev/blog/purescript-and-haskell-at-lumi https://www.lumi.dev/blog/purescript-and-haskell-at-lumi
- pteredactyl 7y ago
  Correct. Interesting you bring up JS, as the Haskellers I spoke of loathed JS and treated it and its developers as below them. But that's just my experience. I hope Lumi was able to gain efficiencies using PureScript and Haskell. And that they're able to attract talent. Thanks for sharing.
  - alexbanks 7y ago
    In my experience Haskellers speak that way about every language that isn't Haskell or Rust, which I found to be probably the biggest turnoff for me wrt learning Haskell.
- merijnv 7y ago
  Don't forget: XMonad, pandoc, and ShellCheck
hardwaresofton 7y ago
Probably because real-world applications mostly aren't that interesting -- they're assuming you're doing that stuff well on your own. You could write "real world applications" in any language you want, some faster (to develop) and others more efficient (at runtime) than haskell, but that's not what haskell brings to the table. Haskellers (well me) view Haskell as introducing reasoned and disciplined immutability, purity, type safety, etc to the mundane world of real-world applications, which is why Haskellers get excited when these benefits can be applied. Writing a database query? boring. Writing a database query that is guaranteed at compile time to contain the right columns to build the right domain object such that you can never write an incorrect one? that's interesting.
- pteredactyl 7y ago
  I hear you. Other languages have those properties. Including TypeScript. In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want. And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications. I'd love to be proven wrong as I'm into type safety and FP, in general.
  - hardwaresofton 7y ago
    I absolutely love TypeScript -- right now Node + TypeScript is my pick for the interpreted language wars (Node/Python/Ruby/Perl/etc). > In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want. This is actually one of haskell's greatest strengths IMO -- it enforces the kind of discipline that sidesteps this problem completely. The kind of functions you write with haskell don't allow bullshit -- non-nullable types are the biggest example of this I can think of, there's also the pervasive use of `Maybe Value` and `Either SomeError Value` types. In other places it's usually referred to as Domain Driven Design or the onion architecture -- but best practices for software development usually dictate that you get rid of bullshit as early as possible on the borders of your application. Put simply, don't let invalid/incorrect input make it into your system. > And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications. Totally true, we do get stuck in the mud, but it's such nice mud -- the things you worry about are just different (and I think this is what you're seeing). Roughly zero haskellers are worrying about NPEs -- there's no urge to get something to "just work" because "better" is right there, and haskell encourages you to strive for it. That said, it's absolutely the case that a ton of energy in haskell land is spent on academic pursuits, but that's actually good imo, languages that don't do this get stale. > I'd love to be proven wrong as I'm into type safety and FP, in general. Well I don't know that this is something someone else can prove to you, outside of people just writing more middling/regular software in haskell and getting it out there, which is a bit of a community thing. I do my best to write practical haskell software and write about it, but a bunch of my projects aren't open source (just yet -- I'm heavily considering making one of them open source right now). Rust is also proving to be a huge (welcome) distraction because it gives much of the haskell creature comforts with within-C++/C range efficiency. Maybe take haskell for a spin? The learning curve is high but it will bend your mind in a good way. Or if you're of the web persuasion, try Elm/Purescript, they're thoroughly practical.
allenleein 7y ago
We need more startup to use Haskell in production, like Dfinity.
- pteredactyl 7y ago
  Has Dfinity launched yet?
  - pteredactyl 7y ago
    No
- immad 7y ago
  Mercury.co uses Haskell. It’s been great so far. Mercury.co/jobs if you are interested.
- daegloe 7y ago
  Co–Star is hiring! costarastrology.com/jobs
alexbanks 7y ago
There was an article posted somewhere about why Haskell isn't used very much in the data science/ML community, and the feedback was that the tooling is mostly not so good. It was kind of amusing to read all of the comments on /r/haskell saying "no it's good." I don't think Haskellers would really understand, but lots of people (especially data scientists in my experience) view languages only as tools. The Haskell community seems to derive lots of value from spending tremendous time basking in the elegance of their tool, rather than actually using it to solve problems. So /r/haskell will continue basking, the rest of the world will continue not using it to solve problems. Or an extremely long winded "yeah I have the same experience as you."
- merijnv 7y ago
  I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!). For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go". And I get it, that last part is super appealing, especially for people who care more about answers to their problem than in technology, I don't blame people for wanting that. But my personal experience is that many of these magical single command tools break a lot when you try to use them in any non-standard environment (for example, something that is not Ubuntu and where you don't have sudo to fix/install system packages) and I work in environments like that a lot. So the fact that e.g. cabal-install requires a bit more explicit work to setup initially is outweighed by the fact that I can reliably install it on any *nix system where I have a login and sufficient diskspace and have it Just Work.
  - alexbanks 7y ago
    > I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!). Exactly, which is why Haskellers should listen to and respond to feedback rather than asserting it is the feedback-giver that is wrong. > For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go". I don't agree with this statement and I think demonstrates some of why Haskellers are kind of frustrating. Most data scientist (and most people in general) want to focus on solving the problem they're tasked with, not elegantly and efficiently positioning themselves to be able to do so. Jupyter and Numpy/Pandas are great because they allow the user to focus exclusively on solving their problem, not on language or framework-level concerns. This is not "a magic command that does the thing I want in one go." It is the separating the needs of the hammer maker from the needs of the carpenter.
iElectric2 7y ago
We're building https://hercules-ci.com/ https://hercules-ci.com/ and not talking much about purity :)

dmix 7y ago

Which doesn't necessarily mean it's not useful for building real world things. Lumi [1][2] was built with Haskell (and PureScript) and looks like a great product. To me it just means more people need to a) build more real things in Haskell b) write about their experience and help advance the state for non-academic newbies and professionals c) avoid the weeds of the language theory stuff and stick the simple established stuff to stay productive (which does exist). You could also make the same argument for JavaScript. So many people are trying to reinvent the wheel every other week in the frontend world, it's just as easy to get distracted by the language/framework noise. Just be a mature developer and don't get suckered into the latest shiny objects. [1] https://www.lumi.com/ https://www.lumi.com/ [2] https://www.lumi.dev/blog/purescript-and-haskell-at-lumi https://www.lumi.dev/blog/purescript-and-haskell-at-lumi

pteredactyl 7y ago
Correct. Interesting you bring up JS, as the Haskellers I spoke of loathed JS and treated it and its developers as below them. But that's just my experience. I hope Lumi was able to gain efficiencies using PureScript and Haskell. And that they're able to attract talent. Thanks for sharing.
- alexbanks 7y ago
  In my experience Haskellers speak that way about every language that isn't Haskell or Rust, which I found to be probably the biggest turnoff for me wrt learning Haskell.
merijnv 7y ago
Don't forget: XMonad, pandoc, and ShellCheck

hardwaresofton 7y ago

Probably because real-world applications mostly aren't that interesting -- they're assuming you're doing that stuff well on your own. You could write "real world applications" in any language you want, some faster (to develop) and others more efficient (at runtime) than haskell, but that's not what haskell brings to the table. Haskellers (well me) view Haskell as introducing reasoned and disciplined immutability, purity, type safety, etc to the mundane world of real-world applications, which is why Haskellers get excited when these benefits can be applied. Writing a database query? boring. Writing a database query that is guaranteed at compile time to contain the right columns to build the right domain object such that you can never write an incorrect one? that's interesting.

pteredactyl 7y ago
I hear you. Other languages have those properties. Including TypeScript. In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want. And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications. I'd love to be proven wrong as I'm into type safety and FP, in general.
- hardwaresofton 7y ago
  I absolutely love TypeScript -- right now Node + TypeScript is my pick for the interpreted language wars (Node/Python/Ruby/Perl/etc). > In my experience I've found real-world applications, by definition are never as pure and perfect as we like them to be. Users do stupid things, or vendor APIs don't quite fit what we want. This is actually one of haskell's greatest strengths IMO -- it enforces the kind of discipline that sidesteps this problem completely. The kind of functions you write with haskell don't allow bullshit -- non-nullable types are the biggest example of this I can think of, there's also the pervasive use of `Maybe Value` and `Either SomeError Value` types. In other places it's usually referred to as Domain Driven Design or the onion architecture -- but best practices for software development usually dictate that you get rid of bullshit as early as possible on the borders of your application. Put simply, don't let invalid/incorrect input make it into your system. > And personally it's why I think the Haskellers I know often get stuck in the mud. Seems the language, or just the Haskellers I know, are better suited for a academic applications. Totally true, we do get stuck in the mud, but it's such nice mud -- the things you worry about are just different (and I think this is what you're seeing). Roughly zero haskellers are worrying about NPEs -- there's no urge to get something to "just work" because "better" is right there, and haskell encourages you to strive for it. That said, it's absolutely the case that a ton of energy in haskell land is spent on academic pursuits, but that's actually good imo, languages that don't do this get stale. > I'd love to be proven wrong as I'm into type safety and FP, in general. Well I don't know that this is something someone else can prove to you, outside of people just writing more middling/regular software in haskell and getting it out there, which is a bit of a community thing. I do my best to write practical haskell software and write about it, but a bunch of my projects aren't open source (just yet -- I'm heavily considering making one of them open source right now). Rust is also proving to be a huge (welcome) distraction because it gives much of the haskell creature comforts with within-C++/C range efficiency. Maybe take haskell for a spin? The learning curve is high but it will bend your mind in a good way. Or if you're of the web persuasion, try Elm/Purescript, they're thoroughly practical.

allenleein 7y ago

We need more startup to use Haskell in production, like Dfinity.

pteredactyl 7y ago
Has Dfinity launched yet?
- pteredactyl 7y ago
  No
immad 7y ago
Mercury.co uses Haskell. It’s been great so far. Mercury.co/jobs if you are interested.
daegloe 7y ago
Co–Star is hiring! costarastrology.com/jobs

alexbanks 7y ago

There was an article posted somewhere about why Haskell isn't used very much in the data science/ML community, and the feedback was that the tooling is mostly not so good. It was kind of amusing to read all of the comments on /r/haskell saying "no it's good." I don't think Haskellers would really understand, but lots of people (especially data scientists in my experience) view languages only as tools. The Haskell community seems to derive lots of value from spending tremendous time basking in the elegance of their tool, rather than actually using it to solve problems. So /r/haskell will continue basking, the rest of the world will continue not using it to solve problems. Or an extremely long winded "yeah I have the same experience as you."

merijnv 7y ago
I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!). For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go". And I get it, that last part is super appealing, especially for people who care more about answers to their problem than in technology, I don't blame people for wanting that. But my personal experience is that many of these magical single command tools break a lot when you try to use them in any non-standard environment (for example, something that is not Ubuntu and where you don't have sudo to fix/install system packages) and I work in environments like that a lot. So the fact that e.g. cabal-install requires a bit more explicit work to setup initially is outweighed by the fact that I can reliably install it on any *nix system where I have a login and sufficient diskspace and have it Just Work.
- alexbanks 7y ago
  > I think the Haskell people saying the tools are good (like me!) are just using a very different criteria of "good" than you (and most data scientists!). Exactly, which is why Haskellers should listen to and respond to feedback rather than asserting it is the feedback-giver that is wrong. > For me a "good tool" is robust, reliable, and easy to fix. For most of the data scientists I know, a "good tool" is one where "a single easy to remember command magically does the thing I want in one go". I don't agree with this statement and I think demonstrates some of why Haskellers are kind of frustrating. Most data scientist (and most people in general) want to focus on solving the problem they're tasked with, not elegantly and efficiently positioning themselves to be able to do so. Jupyter and Numpy/Pandas are great because they allow the user to focus exclusively on solving their problem, not on language or framework-level concerns. This is not "a magic command that does the thing I want in one go." It is the separating the needs of the hammer maker from the needs of the carpenter.

iElectric2 7y ago

We're building https://hercules-ci.com/ https://hercules-ci.com/ and not talking much about purity :)