4 ms·

>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. The barriers disappeared since functi

>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. The barriers disappeared since functional concepts were absorbed into other languages. Almost all languages have higher order functions. Many languages have a preference for immutable data. Recursion was rightly not adopted as iterators are a better solution - keep the map/filter/fold, leave the TCO. >People still come up with stupid reasons why they don't like Haskell One expects that if Haskell was superior, then it would be impossible for successful Haskell projects to materialize as they've done with Python, Go, Rust, Java, C++. And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?

yakshaving_jgt 8y ago
> And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
- otabdeveloper1 8y ago
  They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.
  - yakshaving_jgt 8y ago
    100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes. Everything you have said is nonsense.
  - Jtsummers 8y ago
    That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business. Why would anyone trust "random programmers" to some of their most critical business efforts?
    - AnimalMuppet 8y ago
      Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)
      - yakshaving_jgt 8y ago
        While that may be true to some extent, it doesn't further the discussion because it makes the point moot. For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. Otherwise the point becomes "technology doesn't matter because programmers are all stupid", which is not a constructive discussion.
        AnimalMuppet 8y ago
        otabdeveloper1 said (four parents to this post) that there aren't many successful Haskell projects because businesses can't (or at least don't) hire good programmers. Jtsummers said to hire good ones, or train them to be good. So in context, you could read my post as saying that run-of-the-mill companies don't know how to hire good Haskell programmers. > For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. No. If it's harder to find good Haskell programmers than it is to find good Python programmers, that absolutely has to be figured in. It's not a technical merit of Python or a technical flaw of Haskell, but it certainly has to be factored into the decision of which to use. Perhaps the summary would be "Technical merit doesn't matter if all the good programmers for that language are unavailable." Then there's the problem that, even though we have a good track record of hiring good C++, Java, and Objective C programmers, I am not sure that we would be competent at selecting good Haskell programmers, even if they were available. So if I'm the CTO of RandomCo, I probably don't use Haskell for that new project, no matter how technically good the language is, because I can't identify, locate, and hire good people for the team. And bad people for the team can turn Haskell into... something less.
- fnord123 8y ago
  > It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone. Ok. I put to you that if a technology's adoption primarily comes down to network effects, then other languages will also suffer from adoption. Since 1994: Java was released in 1995. But this surely won't count because this was funded and shoved down our throats by Sun. Just as C# was funded by Microsoft or Swift and Objective C are funded by Apple Ruby became a big deal in the web arena thanks to Rails. Python became bit in sysadmin tools and moved in data analysis (competing with R and Matlab). It's also fairly big in web projects. Golang became big in sysadmin tools and network applications. It was started by Google but it wasn't really a part of any platform that was being shoved down peoples' throats like Java or .Net. Erlang became was fundamental to Facebook's first version of their chat, Whatsapp's first version of /their/ chat, Google's first version of //their// chat, Discord's current version of ///their/// chat[1]. RabbitMQ is/was a popular message queue implemented in Erlang. But where are the Haskell projects?[2] The data suggests there is another variable here. [1] Discord uses Elixir, but this is built off Erlang's VM so it's Erlang technology. Agree or disagree, I don't think that it detracts from the point. [2] They are here: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
  - 59nadir 8y ago
    As with all attempts at making big lists insiders don't really care about this one is perpetually out of date. Every time someone posts a message on Facebook it goes through an anti-spam system written in Haskell by way of their `Haxl` monad which automatically batches resource requests, "figures out" what it can fetch concurrently (not really, it's a feature of `Applicative` vs. `Monad`). People go on and on about how Haskell is niche, but I haven't made a job search in a long time where there weren't more results for Haskell than Erlang, for example. Among the rarer languages it's clearly one of the more popular ones. Yet, here we are, people talking about it as if it's somehow less used in industry than all of the other FP languages. OCaml is an interesting example. Usually people who haven't used either language outside of a few Sundays here and there will talk about how OCaml is more practical than Haskell and is the more obvious choice for industry... But on just indeed.com as an example it currently has 63 listings with the top ones being for developers in other languages. Haskell has 479 (again it's popular to search for Scala developers by saying they ought to know Haskell).
59nadir 8y ago
> There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is? Project managers do still matter. I've had an incredibly hard time convincing my current project manager that pure FP languages will pay off for us and that's even after showing code that abstracts over what we do in other languages in fewer lines and with more extensibility. I've shown things that are impossible to do without higher-kinded types that solve real issues we've had that have impacted business. I've also shown a lighter version of that relying on phantom types to solve the same problem, in order to show that there are levels to this. The core of the problem lied in ensuring that logged data was anonymized. This is something you can encode in the type system with no runtime overhead so that it's impossible to log something that's not pre-sanitized. It's very hard to convince someone who's experience extends to Java & JavaScript that there are languages that allow you to more precisely and safely encode business logic in ways that make misuse hard if not impossible. It's even harder to convince those people that the overhead of learning something like PureScript will be amortized by the ease of maintenance that you get out of it. The main issue, as far as I see it, is that we continually solve all the issues that arise from our lack of good language choices. We've yet to end up in a situation so bad that we can't solve it within a day, which makes our choices "good enough". The "good enough" that you have right before you is better than the seemingly unknown that someone is promising you and no amount of code examples addressing your issues is going to change that.

yakshaving_jgt 8y ago

> And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.

otabdeveloper1 8y ago
They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.
- yakshaving_jgt 8y ago
  100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes. Everything you have said is nonsense.
- Jtsummers 8y ago
  That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business. Why would anyone trust "random programmers" to some of their most critical business efforts?
  - AnimalMuppet 8y ago
    Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)
    - yakshaving_jgt 8y ago
      While that may be true to some extent, it doesn't further the discussion because it makes the point moot. For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. Otherwise the point becomes "technology doesn't matter because programmers are all stupid", which is not a constructive discussion.
      - AnimalMuppet 8y ago
        otabdeveloper1 said (four parents to this post) that there aren't many successful Haskell projects because businesses can't (or at least don't) hire good programmers. Jtsummers said to hire good ones, or train them to be good. So in context, you could read my post as saying that run-of-the-mill companies don't know how to hire good Haskell programmers. > For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. No. If it's harder to find good Haskell programmers than it is to find good Python programmers, that absolutely has to be figured in. It's not a technical merit of Python or a technical flaw of Haskell, but it certainly has to be factored into the decision of which to use. Perhaps the summary would be "Technical merit doesn't matter if all the good programmers for that language are unavailable." Then there's the problem that, even though we have a good track record of hiring good C++, Java, and Objective C programmers, I am not sure that we would be competent at selecting good Haskell programmers, even if they were available. So if I'm the CTO of RandomCo, I probably don't use Haskell for that new project, no matter how technically good the language is, because I can't identify, locate, and hire good people for the team. And bad people for the team can turn Haskell into... something less.
fnord123 8y ago
> It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone. Ok. I put to you that if a technology's adoption primarily comes down to network effects, then other languages will also suffer from adoption. Since 1994: Java was released in 1995. But this surely won't count because this was funded and shoved down our throats by Sun. Just as C# was funded by Microsoft or Swift and Objective C are funded by Apple Ruby became a big deal in the web arena thanks to Rails. Python became bit in sysadmin tools and moved in data analysis (competing with R and Matlab). It's also fairly big in web projects. Golang became big in sysadmin tools and network applications. It was started by Google but it wasn't really a part of any platform that was being shoved down peoples' throats like Java or .Net. Erlang became was fundamental to Facebook's first version of their chat, Whatsapp's first version of /their/ chat, Google's first version of //their// chat, Discord's current version of ///their/// chat[1]. RabbitMQ is/was a popular message queue implemented in Erlang. But where are the Haskell projects?[2] The data suggests there is another variable here. [1] Discord uses Elixir, but this is built off Erlang's VM so it's Erlang technology. Agree or disagree, I don't think that it detracts from the point. [2] They are here: https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
- 59nadir 8y ago
  As with all attempts at making big lists insiders don't really care about this one is perpetually out of date. Every time someone posts a message on Facebook it goes through an anti-spam system written in Haskell by way of their `Haxl` monad which automatically batches resource requests, "figures out" what it can fetch concurrently (not really, it's a feature of `Applicative` vs. `Monad`). People go on and on about how Haskell is niche, but I haven't made a job search in a long time where there weren't more results for Haskell than Erlang, for example. Among the rarer languages it's clearly one of the more popular ones. Yet, here we are, people talking about it as if it's somehow less used in industry than all of the other FP languages. OCaml is an interesting example. Usually people who haven't used either language outside of a few Sundays here and there will talk about how OCaml is more practical than Haskell and is the more obvious choice for industry... But on just indeed.com as an example it currently has 63 listings with the top ones being for developers in other languages. Haskell has 479 (again it's popular to search for Scala developers by saying they ought to know Haskell).

59nadir 8y ago

> There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is? Project managers do still matter. I've had an incredibly hard time convincing my current project manager that pure FP languages will pay off for us and that's even after showing code that abstracts over what we do in other languages in fewer lines and with more extensibility. I've shown things that are impossible to do without higher-kinded types that solve real issues we've had that have impacted business. I've also shown a lighter version of that relying on phantom types to solve the same problem, in order to show that there are levels to this. The core of the problem lied in ensuring that logged data was anonymized. This is something you can encode in the type system with no runtime overhead so that it's impossible to log something that's not pre-sanitized. It's very hard to convince someone who's experience extends to Java & JavaScript that there are languages that allow you to more precisely and safely encode business logic in ways that make misuse hard if not impossible. It's even harder to convince those people that the overhead of learning something like PureScript will be amortized by the ease of maintenance that you get out of it. The main issue, as far as I see it, is that we continually solve all the issues that arise from our lack of good language choices. We've yet to end up in a situation so bad that we can't solve it within a day, which makes our choices "good enough". The "good enough" that you have right before you is better than the seemingly unknown that someone is promising you and no amount of code examples addressing your issues is going to change that.