11 ms·

I am the person that would be the one most likely to adopt haskell in the company I work in. Now, I don't and I won't even though I used it for several pet proj

I am the person that would be the one most likely to adopt haskell in the company I work in. Now, I don't and I won't even though I used it for several pet projects and I would say have learned a lot of haskell and associated patterns. It's not that haskell doesn't have merits. However I feel like they are oversold. While you can build programs that lack certain error classes, they are not bug free and at the same time debugging often was a lot harder than in other languages. The laziness is especially problematic in that regard. Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. Another important problem is the docs. For some reasons they hardly contain examples. You don't get adoption that way. Even if the maintainers feel that the type signatures are documentation enough. And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process.

lambdasquirrel 6y ago
> Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.
- a1369209993 6y ago
  I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.
- derefr 6y ago
  Not a Haskeller, but I'd like to try to change your mind about this point: > We are just trying to build things here. Some languages are built to do engineering first-and-foremost. Languages like Haskell are built to do mathematics in first-and-foremost. This doesn't mean that such languages aren't also well-engineered, or that they aren't also tuned to do engineering in; but the engineering concerns must be subordinated to not breaking the model that mathematicians rely upon to do math in the language. So you can't just e.g. change whether a particular kind of function can emit IO or not; or change what values exist as part of the lattice of a type; or any number of other things visible within the language's abstraction; because those very properties/constraints are also syllogisms which are relied upon in mathematics done in the language. And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem, because those properties that a function presents to the runtime are also used by the compiler to optimize (or memoize, or fuse, or eliminate) code. You can't really declare something as a pure function without the runtime thinking it can do all sorts of things that result in the function being called less. In theory, Haskell could have something like a "volatile" qualifier for functions, sort of like C's volatile qualifier for data, to tell the runtime that while the function has type X, all optimization opportunities that would normally apply to type X are off the table. Then you could have special debug functions of type X. It's just that getting this working would require a lot of re-work throughout the compiler, since the compiler mostly deduces optimization opportunities from the type (and marks something as having more optimization opportunities by proving that it has an extra applicable type), rather than just tracking some separate metadata that can be arbitrarily written to.
  - pron 6y ago
    And in theory, Haskell could be exceptionally fast, or exceptionally correct, or exceptionally maintainable while in practice it is none of those things. It is, however, a relatively elegant language that explores interesting ideas and that some people enjoy, and that's great!
    - dddbbb 6y ago
- markstos 6y ago
  I used to contribute to the Darcs project, which is written in Haskell. It read like a series of math equations, with frequent single letter variable names. It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names. I like the language but this cultural aspect made it harder to get up to speed and contribute.
  - gowld 6y ago
    That same issue hasn't slowed Go down, so something else is getting in the way.
  - yakshaving_jgt 6y ago
    What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?
    - markstos 6y ago
      I randomly opened a file in the Darcs code base and picked a line: mReadFilePS p = B.concat `fmap` BL.toChunks `fmap` TM.readFile p To understand this, you need to know what "m", "PS", "B", "BL" and "TM" mean. In Node.js, the convention is that classes are named after the modules they import-- they are full words: const config = require('config') In Darcs, we find this: import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as BL import qualified Data.Map as M import qualified Darcs.Util.Tree.Monad as TM I guess you get used to it, but it's a steeper learning curve for contributors to memorize more items to get up to speed.
      - yakshaving_jgt 6y ago
        I don't understand. There is no memorisation necessary. The modules are imported, qualified by an alias. I'll accept the learning curve for Haskell is at least longer (rather than steeper) than in most languages, but to hold this up as an example to me is just bizarre. And I say this is someone who only knew JavaScript and PHP for some years before learning a bunch of other languages including Haskell. Moreover, you've conveniently left out the type signature which I expect would normally accompany this function, which would tell the reader what the `p` variable is.
- exdsq 6y ago
  I've found the opposite - I work with quite a few 'prominent' figures in the Haskell community and they are very approachable and friendly. The most hostile I've experienced was Stack Overflow as a beginner...
  - shivasword 6y ago
    Hostility toward beginners is a poor strategy if growth is the goal.
smallnamespace 6y ago
Regarding the lack of examples, the type system is strong enough that in many cases, if you write the types that you expect up front, there's only one or few possible implementations. A common workflow for Haskellers is to specify type signatures and interactively edit until the compiler is satisfied. Often, the code gives you correct results on the first try. This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself.
- Silhouette 6y ago
  Regarding the lack of examples, the type system is strong enough that in many cases, if you write the types that you expect up front, there's only one or few possible implementations. This is a common counter-argument. It is a true statement. And, in the nicest possible way, it is also completely missing the point. When you're playing with cute mathematical code and almost everything is written in terms of totally generic types, it's cute that you get free theorems and automatic derivations of some basic functions and all that stuff. However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. This remains true notwithstanding the possibility that some of that cute generic code was used to implement various small parts of the function you actually care about if you dig down far enough. This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself. I would argue that the problem from a marketing and adoption standpoint is that it still isn't visible even if you do do those things, unless you're interested in writing heavily mathematical generic code rather than completing the job your boss told you to do within a reasonable timeframe.
  - dragonwriter 6y ago
    > However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. But, on the gripping hand, using types unspecific enough that that is the case is often a sign of underusing the type system. E.g., very few domains actually deal with bare numbers as domain values, and when you express concrete types specific enough, there may be more than one possible correct function, Bru very often the one actually correct function will be much more obvious, and the mistakes possible by omitting a step when using less-robust sets of types become impossible because you effectively have statically verified dimensional analysis.
hopia 6y ago
So what kind of bugs do you commonly experience then in Haskell programs? From my limited experience I agree that debugging a bug that passes compilation is more difficult than on other platforms.
StreamBright 6y ago
Same here. We have adopted F# instead of Haskell. We get most of the benefits and none of the downsides. F# is a truly multi platform environment (I know Haskell claims that too but fails in practice). If we want to write impure, imperative code without monads, we can. We can also use every single opensource project out there without learning a new operator DSL and style. There are some annoying things, but the benefits outweigh those. The development velocity is also great. We can implement prototypes in a few hours and put a new service into production in a matter of days. There are few things that you need to set in your projects as opposed to learning a ton of compiler flags. I have never thought that I am going to be on a Microsoft platform once but here we go. It works and it is very convenient.
- probst 6y ago
  I went from Haskell to F# too. For more or less the same reasons you outline. Better and more consistent tooling. Significantly easier debugging. Not all the benefits of the Haskell type system sure, but enough of them to make classes of errors vanish and programming a joy. A welcoming and friendly community looking to solve problems and build things is also boon (the open source community around Fable is one example).
  - StreamBright 6y ago
    >> A welcoming and friendly community O yeah, I totally forgot that. There is a very senior guy on SO who literally helped to fix all our non-trivial problems. I still need to investigate if we could move from Elm to Elmish (or more like SAFE).
- klipt 6y ago
  F# was inspired more by Ocaml than Haskell I think? Ocaml also takes a more practical approach to allowing side effects etc.
  - StreamBright 6y ago
    Yes, and I think this is why it wins. Practical implications matter the most for end users. I like OCaml too. However, F# has way more libraries, and I think it is easier to get buy-in from all sorts of developers, at least this is my experience.
mlthoughts2018 6y ago
Same for me - I used Haskell and Scala as my primary two languages for over 6 years. In retrospect I question whether many of the stated benefits of Haskell are even benefits at all. In terms of reducing development time or cost, reducing defects, improving design, or really improving any business outcomes whatsoever, Haskell showed no success, only failure. How could that be in contrast to “ugly” and “complex” languages like Java and C++, or free for all languages like Python and Node js? The reason is simple: 1. imperative structure is actually clearer and easier to understand, easily amenable to all the upsides of function-oriented programming with far fewer downsides. 2. removing whole categories of bugs through compilation and type system patterns is a hugely overrated waste of time. Lightweight unit tests get you 99% of the way there with far less rigid design commitment 3. safety and correctness are resources just like memory or runtime complexity, not absolutes. Being able to tradeoff safety against other concerns, at a moment’s notice, deep in the guts of a large system, is one of the most critical requirements of business software 4. Premature abstraction costs you way more in pure functional languages than most other imperative or OO situations.
- wirrbel 6y ago
  I agree on all points which pains me because I like the idea of functional programming and find it pretty. At least for smaller programs.
jbreckmckye 6y ago
I was a Haskell developer in my last gig. I entered that job determined to make a success of it, because I was excited about the language and felt I wanted to "prove" that it had value in a "boring" domain like financial services. But I was stymied at every opportunity by Haskell itself. My biggest complaints are 1) the lack of good libraries, and 2) the apalling state of documentation for the few that exist. Too many Haskell projects read like "I figured out this neat family of types for thinking about X - at last URL parsing is provably safe - now you figure out the rest". Let's take a practical example: HTTP requests. If I'm a budding JavaScript developer, or Kotlin developer, or Python developer, I can read through copious search results and tutorials on Axios / OkHttp / Requests / delete as appropriate. These tutorials not only walk me through the common use cases but also show me their APIs in the context of the new and alien syntax of the language I'm grappling with. They give me enough template code that I can use an incomplete understanding of whatever language it is I'm learning to figure out the rest without recourse to a textbook. What does Haskell have? It has Req (and a bunch of other also rans), and the docs for Req are atrocious, spanning a staggering 1 (one) example and then a meandering essay on the deficiency of other Haskell HTTP clients. It's not good enough. And that's my assessment of Haskell as a whole - not the language individually, which is expressive and powerful and inspired - but the whole ecosystem around Haskell that feels like a set of beta projects and hobby repositories generally developed by interested individuals rather than commercial endeavours. Or look at the paltry state of IDE support. It's 2020 and the best option we have is VSCode with HIE, which rapidly spirals out of control allocating memory, randomly crashes and on Windows just refuses to even start half the time. Without this tooling a lot of the theoretical benefit of the type system is being lost. This is low hanging fruit but there's been no incentive to pick it. And so I've made the difficult decision to leave Haskell behind. If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript. Haskell is a great learning experience but totally unproductive right now.
- pwm 6y ago
  It's a bit of a chicken and egg problem and pretty much what the author of the article is talking about as well. You need people's time and energy to improve the status quo and getting people's attention takes ... people's time and energy. Haskell has always been grassroots and imho has enough hard-core believers that it will never go away but whether it'll ever be mainstream I don't know. I have great admiration for the small group of people who put their own time and energy into making the language and the ecosystem better. Re IDE support - loads happening there atm, ghcide is imho a true game changer and fast becoming an invaluable tool for working with Haskell.
marcosdumay 6y ago
> Haskell and Scala community have been the most hostile communities I have experienced. This is not the first time I have seen this claim, but it's so much in contrast with my experience that I don't know what to think. There seems to be some cliques of Haskell developers on mostly non-communicating communities. I would imagine they self-select but I have actually only encountered any hostility on Stack Overflow, and the Haskell part of it, besides being business as usual for the site, also is a mostly useless knowledge base (to the point that I remove the site from searches to decrease the noise).
- Insanity 6y ago
  I often think of Haskell as one of the friendliest communities. Granted, not on SO, but on IRC.
  - thidr0 6y ago
    I agree —- I find the Haskell IRC very friendly, even to the point of helping people do research and figure things out instead of just dropping answers. And there’s a beginners IRC for all those stupid questions I have
    - lgas 6y ago
      The Haskell channel(s) on the FP Slack (https://fpchat-invite.herokuapp.com/ https://fpchat-invite.herokuapp.com/) are also exceptionally welcoming and I've seen people go above and beyond helping people again and again.
- deleted 6y ago
  [deleted]
throwaway_pdp09 6y ago
> Haskell and Scala community have been the most hostile communities I have experienced How come I never seem to have this problem. I mean one scala dick (who wasn't actually so bad after a while) but that's it.
- hopia 6y ago
  I haven't either. Granted, I've only asked for help on Slack and Reddit, but I've always had many people explain the solution in good detail to me.
whateveracct 6y ago
> And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process. Are you referring to language extensions? This is sooooo off-base if so. I don't see how people can bemoan Haskell's complexity but love a language like Kotlin which has its hodgepodge of function call semantics. Talk about complexity without any sane ground. It's so hacked together. At least with Haskell everything is very simple in isolation and composes for the most part. -- Also re:examples.. I'd say Haskell libraries have better examples than the average Go library for instance. Many have entire modules whose entire existence is for putting examples & tutorials in the haddocks themselves.
- anta40 6y ago
  "I don't see how people can bemoan Haskell's complexity but love a language like Kotlin which has its hodgepodge of function call semantics" One of a few possible explanations: they are mobile app devs who simply want to get things done, instead of hacking the toolchain (including myself). Sure I'd love be able to write Android apps in Haskell. What's the easiest way to do it? With Kotlin, it's already nicely packaged in Android Studio. Very convenient.
  - whateveracct 6y ago
    I figure in the next 5 years I'll hack the toolchain once and for all. Probably for game distribution. It's a fixed cost is all. To each their own. I do appreciate the tooling around Kotlin. Definitely wish we had more time and money available in Haskell to match it. Still doesn't explain enterprise use of Kotlin on the backend lol.
  - ghostwriter 6y ago
    Reflex Platform supports native mobile builds to some extent: * https://github.com/ElvishJerricco/reflex-project-skeleton https://github.com/ElvishJerricco/reflex-project-skeleton * https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.md#building-mobile-apps https://github.com/reflex-frp/reflex-platform/blob/develop/d...
ArchD 6y ago
Did you personally have unfriendly arguments with Haskellers? I personally find them quite helpful and friendly on the freenode #haskell channel. Although there have been heated public disagreements, I haven't seen the people trying to destroy one another. They just have very strong disagreements. That doesn't bother me directly since I'm not in those discussions. The most I can say is that the lack of unity means there is a shortage of "best practice" of how to do certain things and lower community focus in advancing the ecosystem.
- wirrbel 6y ago
  Overall most people are friendly in almost all communities, at least if you avoid community-defining topics. So most interactions with haskellers have been friendly. But I had a number of relevant interactions that were Fairly hostile and I have passively observed interactions on various communication channels that wouldn't have flown in the python community.

lambdasquirrel 6y ago

> Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.

a1369209993 6y ago
I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.
derefr 6y ago
Not a Haskeller, but I'd like to try to change your mind about this point: > We are just trying to build things here. Some languages are built to do engineering first-and-foremost. Languages like Haskell are built to do mathematics in first-and-foremost. This doesn't mean that such languages aren't also well-engineered, or that they aren't also tuned to do engineering in; but the engineering concerns must be subordinated to not breaking the model that mathematicians rely upon to do math in the language. So you can't just e.g. change whether a particular kind of function can emit IO or not; or change what values exist as part of the lattice of a type; or any number of other things visible within the language's abstraction; because those very properties/constraints are also syllogisms which are relied upon in mathematics done in the language. And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem, because those properties that a function presents to the runtime are also used by the compiler to optimize (or memoize, or fuse, or eliminate) code. You can't really declare something as a pure function without the runtime thinking it can do all sorts of things that result in the function being called less. In theory, Haskell could have something like a "volatile" qualifier for functions, sort of like C's volatile qualifier for data, to tell the runtime that while the function has type X, all optimization opportunities that would normally apply to type X are off the table. Then you could have special debug functions of type X. It's just that getting this working would require a lot of re-work throughout the compiler, since the compiler mostly deduces optimization opportunities from the type (and marks something as having more optimization opportunities by proving that it has an extra applicable type), rather than just tracking some separate metadata that can be arbitrarily written to.
- pron 6y ago
  And in theory, Haskell could be exceptionally fast, or exceptionally correct, or exceptionally maintainable while in practice it is none of those things. It is, however, a relatively elegant language that explores interesting ideas and that some people enjoy, and that's great!
  - dddbbb 6y ago
markstos 6y ago
I used to contribute to the Darcs project, which is written in Haskell. It read like a series of math equations, with frequent single letter variable names. It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names. I like the language but this cultural aspect made it harder to get up to speed and contribute.
- gowld 6y ago
  That same issue hasn't slowed Go down, so something else is getting in the way.
- yakshaving_jgt 6y ago
  What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?
  - markstos 6y ago
    I randomly opened a file in the Darcs code base and picked a line: mReadFilePS p = B.concat `fmap` BL.toChunks `fmap` TM.readFile p To understand this, you need to know what "m", "PS", "B", "BL" and "TM" mean. In Node.js, the convention is that classes are named after the modules they import-- they are full words: const config = require('config') In Darcs, we find this: import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as BL import qualified Data.Map as M import qualified Darcs.Util.Tree.Monad as TM I guess you get used to it, but it's a steeper learning curve for contributors to memorize more items to get up to speed.
    - yakshaving_jgt 6y ago
      I don't understand. There is no memorisation necessary. The modules are imported, qualified by an alias. I'll accept the learning curve for Haskell is at least longer (rather than steeper) than in most languages, but to hold this up as an example to me is just bizarre. And I say this is someone who only knew JavaScript and PHP for some years before learning a bunch of other languages including Haskell. Moreover, you've conveniently left out the type signature which I expect would normally accompany this function, which would tell the reader what the `p` variable is.
exdsq 6y ago
I've found the opposite - I work with quite a few 'prominent' figures in the Haskell community and they are very approachable and friendly. The most hostile I've experienced was Stack Overflow as a beginner...
- shivasword 6y ago
  Hostility toward beginners is a poor strategy if growth is the goal.

smallnamespace 6y ago

Regarding the lack of examples, the type system is strong enough that in many cases, if you write the types that you expect up front, there's only one or few possible implementations. A common workflow for Haskellers is to specify type signatures and interactively edit until the compiler is satisfied. Often, the code gives you correct results on the first try. This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself.

Silhouette 6y ago
Regarding the lack of examples, the type system is strong enough that in many cases, if you write the types that you expect up front, there's only one or few possible implementations. This is a common counter-argument. It is a true statement. And, in the nicest possible way, it is also completely missing the point. When you're playing with cute mathematical code and almost everything is written in terms of totally generic types, it's cute that you get free theorems and automatic derivations of some basic functions and all that stuff. However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. This remains true notwithstanding the possibility that some of that cute generic code was used to implement various small parts of the function you actually care about if you dig down far enough. This means the type signatures aren't simply documentation, they also strongly direct your implementation. The problem from a marketing and adoption standpoint is that this isn't visible until you've hopped into a REPL or IDE and tried it yourself. I would argue that the problem from a marketing and adoption standpoint is that it still isn't visible even if you do do those things, unless you're interested in writing heavily mathematical generic code rather than completing the job your boss told you to do within a reasonable timeframe.
- dragonwriter 6y ago
  > However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. But, on the gripping hand, using types unspecific enough that that is the case is often a sign of underusing the type system. E.g., very few domains actually deal with bare numbers as domain values, and when you express concrete types specific enough, there may be more than one possible correct function, Bru very often the one actually correct function will be much more obvious, and the mistakes possible by omitting a step when using less-robust sets of types become impossible because you effectively have statically verified dimensional analysis.

hopia 6y ago

So what kind of bugs do you commonly experience then in Haskell programs? From my limited experience I agree that debugging a bug that passes compilation is more difficult than on other platforms.

StreamBright 6y ago

Same here. We have adopted F# instead of Haskell. We get most of the benefits and none of the downsides. F# is a truly multi platform environment (I know Haskell claims that too but fails in practice). If we want to write impure, imperative code without monads, we can. We can also use every single opensource project out there without learning a new operator DSL and style. There are some annoying things, but the benefits outweigh those. The development velocity is also great. We can implement prototypes in a few hours and put a new service into production in a matter of days. There are few things that you need to set in your projects as opposed to learning a ton of compiler flags. I have never thought that I am going to be on a Microsoft platform once but here we go. It works and it is very convenient.

probst 6y ago
I went from Haskell to F# too. For more or less the same reasons you outline. Better and more consistent tooling. Significantly easier debugging. Not all the benefits of the Haskell type system sure, but enough of them to make classes of errors vanish and programming a joy. A welcoming and friendly community looking to solve problems and build things is also boon (the open source community around Fable is one example).
- StreamBright 6y ago
  >> A welcoming and friendly community O yeah, I totally forgot that. There is a very senior guy on SO who literally helped to fix all our non-trivial problems. I still need to investigate if we could move from Elm to Elmish (or more like SAFE).
klipt 6y ago
F# was inspired more by Ocaml than Haskell I think? Ocaml also takes a more practical approach to allowing side effects etc.
- StreamBright 6y ago
  Yes, and I think this is why it wins. Practical implications matter the most for end users. I like OCaml too. However, F# has way more libraries, and I think it is easier to get buy-in from all sorts of developers, at least this is my experience.

mlthoughts2018 6y ago

Same for me - I used Haskell and Scala as my primary two languages for over 6 years. In retrospect I question whether many of the stated benefits of Haskell are even benefits at all. In terms of reducing development time or cost, reducing defects, improving design, or really improving any business outcomes whatsoever, Haskell showed no success, only failure. How could that be in contrast to “ugly” and “complex” languages like Java and C++, or free for all languages like Python and Node js? The reason is simple: 1. imperative structure is actually clearer and easier to understand, easily amenable to all the upsides of function-oriented programming with far fewer downsides. 2. removing whole categories of bugs through compilation and type system patterns is a hugely overrated waste of time. Lightweight unit tests get you 99% of the way there with far less rigid design commitment 3. safety and correctness are resources just like memory or runtime complexity, not absolutes. Being able to tradeoff safety against other concerns, at a moment’s notice, deep in the guts of a large system, is one of the most critical requirements of business software 4. Premature abstraction costs you way more in pure functional languages than most other imperative or OO situations.

wirrbel 6y ago
I agree on all points which pains me because I like the idea of functional programming and find it pretty. At least for smaller programs.

jbreckmckye 6y ago

I was a Haskell developer in my last gig. I entered that job determined to make a success of it, because I was excited about the language and felt I wanted to "prove" that it had value in a "boring" domain like financial services. But I was stymied at every opportunity by Haskell itself. My biggest complaints are 1) the lack of good libraries, and 2) the apalling state of documentation for the few that exist. Too many Haskell projects read like "I figured out this neat family of types for thinking about X - at last URL parsing is provably safe - now you figure out the rest". Let's take a practical example: HTTP requests. If I'm a budding JavaScript developer, or Kotlin developer, or Python developer, I can read through copious search results and tutorials on Axios / OkHttp / Requests / delete as appropriate. These tutorials not only walk me through the common use cases but also show me their APIs in the context of the new and alien syntax of the language I'm grappling with. They give me enough template code that I can use an incomplete understanding of whatever language it is I'm learning to figure out the rest without recourse to a textbook. What does Haskell have? It has Req (and a bunch of other also rans), and the docs for Req are atrocious, spanning a staggering 1 (one) example and then a meandering essay on the deficiency of other Haskell HTTP clients. It's not good enough. And that's my assessment of Haskell as a whole - not the language individually, which is expressive and powerful and inspired - but the whole ecosystem around Haskell that feels like a set of beta projects and hobby repositories generally developed by interested individuals rather than commercial endeavours. Or look at the paltry state of IDE support. It's 2020 and the best option we have is VSCode with HIE, which rapidly spirals out of control allocating memory, randomly crashes and on Windows just refuses to even start half the time. Without this tooling a lot of the theoretical benefit of the type system is being lost. This is low hanging fruit but there's been no incentive to pick it. And so I've made the difficult decision to leave Haskell behind. If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript. Haskell is a great learning experience but totally unproductive right now.

pwm 6y ago
It's a bit of a chicken and egg problem and pretty much what the author of the article is talking about as well. You need people's time and energy to improve the status quo and getting people's attention takes ... people's time and energy. Haskell has always been grassroots and imho has enough hard-core believers that it will never go away but whether it'll ever be mainstream I don't know. I have great admiration for the small group of people who put their own time and energy into making the language and the ecosystem better. Re IDE support - loads happening there atm, ghcide is imho a true game changer and fast becoming an invaluable tool for working with Haskell.

marcosdumay 6y ago

> Haskell and Scala community have been the most hostile communities I have experienced. This is not the first time I have seen this claim, but it's so much in contrast with my experience that I don't know what to think. There seems to be some cliques of Haskell developers on mostly non-communicating communities. I would imagine they self-select but I have actually only encountered any hostility on Stack Overflow, and the Haskell part of it, besides being business as usual for the site, also is a mostly useless knowledge base (to the point that I remove the site from searches to decrease the noise).

Insanity 6y ago
I often think of Haskell as one of the friendliest communities. Granted, not on SO, but on IRC.
- thidr0 6y ago
  I agree —- I find the Haskell IRC very friendly, even to the point of helping people do research and figure things out instead of just dropping answers. And there’s a beginners IRC for all those stupid questions I have
  - lgas 6y ago
    The Haskell channel(s) on the FP Slack (https://fpchat-invite.herokuapp.com/ https://fpchat-invite.herokuapp.com/) are also exceptionally welcoming and I've seen people go above and beyond helping people again and again.
deleted 6y ago
[deleted]

throwaway_pdp09 6y ago

> Haskell and Scala community have been the most hostile communities I have experienced How come I never seem to have this problem. I mean one scala dick (who wasn't actually so bad after a while) but that's it.

hopia 6y ago
I haven't either. Granted, I've only asked for help on Slack and Reddit, but I've always had many people explain the solution in good detail to me.

whateveracct 6y ago

> And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process. Are you referring to language extensions? This is sooooo off-base if so. I don't see how people can bemoan Haskell's complexity but love a language like Kotlin which has its hodgepodge of function call semantics. Talk about complexity without any sane ground. It's so hacked together. At least with Haskell everything is very simple in isolation and composes for the most part. -- Also re:examples.. I'd say Haskell libraries have better examples than the average Go library for instance. Many have entire modules whose entire existence is for putting examples & tutorials in the haddocks themselves.

anta40 6y ago
"I don't see how people can bemoan Haskell's complexity but love a language like Kotlin which has its hodgepodge of function call semantics" One of a few possible explanations: they are mobile app devs who simply want to get things done, instead of hacking the toolchain (including myself). Sure I'd love be able to write Android apps in Haskell. What's the easiest way to do it? With Kotlin, it's already nicely packaged in Android Studio. Very convenient.
- whateveracct 6y ago
  I figure in the next 5 years I'll hack the toolchain once and for all. Probably for game distribution. It's a fixed cost is all. To each their own. I do appreciate the tooling around Kotlin. Definitely wish we had more time and money available in Haskell to match it. Still doesn't explain enterprise use of Kotlin on the backend lol.
- ghostwriter 6y ago
  Reflex Platform supports native mobile builds to some extent: * https://github.com/ElvishJerricco/reflex-project-skeleton https://github.com/ElvishJerricco/reflex-project-skeleton * https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.md#building-mobile-apps https://github.com/reflex-frp/reflex-platform/blob/develop/d...

ArchD 6y ago

Did you personally have unfriendly arguments with Haskellers? I personally find them quite helpful and friendly on the freenode #haskell channel. Although there have been heated public disagreements, I haven't seen the people trying to destroy one another. They just have very strong disagreements. That doesn't bother me directly since I'm not in those discussions. The most I can say is that the lack of unity means there is a shortage of "best practice" of how to do certain things and lower community focus in advancing the ecosystem.

wirrbel 6y ago
Overall most people are friendly in almost all communities, at least if you avoid community-defining topics. So most interactions with haskellers have been friendly. But I had a number of relevant interactions that were Fairly hostile and I have passively observed interactions on various communication channels that wouldn't have flown in the python community.