5 ms·

That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anythi

That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success. But the main reason, at least in my 20+ year career in my industry, is that it simply doesn't have a track record of success. Haskell isn't remotely new. It was mainstream in academia when I was at university and since then I've seen multiple attempts at adopting it in a large scale commercial setting. I've seen a couple of successes, on small, well defined projects that were relatively "academic" in nature (i.e. the challenges were in the comp-sci type aspects rather than the engineering, and the interactions with other systems were minimal). I've seen more failures, projects with lofty goals that went nowhere. F# has been more successful, and I've seen some significant infrastructure built with it, but it's certainly not proven itself superior to the alternatives (in an industry where successful solutions always get mimicked). Basically, it's 2022. People have tried it and it hasn't worked out.

captaincaveman 5y ago
I have similar opinions on Scala, lots of theory that it makes things better, but the only measurable difference is that its a nightmare to hire for, more expensive and we often have to invest time training people ... who then leave to become contractors. I'm not anti functional or Scala, but I'm yet to see any reports etc that actually indicate there is a pay off.
- grumpyprole 5y ago
  I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java. The underlying issue is that it's a complex language with many experimental and interacting features, which can and do cause a lot of distraction. This is not the fault of functional programming. Have a go at OCaml or F#, which are nice practical sweet spots.
  - hocuspocus 5y ago
    The JVM has had specialized bytecode for SAM types for a long time now, you cannot really get more "first-class" than that. And really it's just an implementation detail than doesn't make the language more or less functional. Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
    - grumpyprole 5y ago
      > it's just an implementation detail than doesn't make the language more or less functional. It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages. > Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants. Each has advanced features not offered by the other. > The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two. It was not designed as a functional programming language first and foremost, that is my point.
      - captaincaveman 5y ago
        I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery. I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route. I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!
        hocuspocus 5y ago
        > I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery. Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?
- 62951413 5y ago
  There are two flavors of Scala and only one of them is about cats/scalaz. I feel intellectually inferior to people who use the latter in production. But I don't think anymore it's a reasonable aspiration to become one of them. And maven builds Scala projects equally well (with half a screen of XML) and without any SBT complexity. I have not seen Bay Area companies where previous Scala experience counts for more than inviting me to an interview. In my current team I know multiple developers who'd like to have more Scala and Java developers who don't know Scala or even Kotlin.
Quekid5 5y ago
Haskell's slogan was "avoid (success at all cost)", so it's hardly surprising that it's been considered niche since its inception. It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct. Is this objective data? No, certainly not, but it's probably better than pure speculation. I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.
- andi999 5y ago
  I learned that supposedly the Haskell motto "avoid success at all cost" wasnt suppose to mean what people think: https://news.ycombinator.com/item?id=12056169 https://news.ycombinator.com/item?id=12056169 https://discourse.haskell.org/t/new-blog-post-haskell-doomed-to-succeed/1662 https://discourse.haskell.org/t/new-blog-post-haskell-doomed... I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link): "An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…" I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
  - pyrale 5y ago
    > I mean, would you want to rest your business on such an attitude? From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
  - 5y ago
q-big 5y ago
> (in an industry where successful solutions always get mimicked). This is in my opinion not the case. Just to give one example: WhatsApp managed to get to half a billion users with about 60 employees by using Erlang for their infrastructure. Nevertheless, Erlang is far from being a mainstream language (even though it is used in industry). In my opinion, in what kind of infrastructure is used/mimicked, a lot of hype is involved.
- omnicognate 5y ago
  That's not the industry I'm talking about. I work in finance.
grumpyprole 5y ago
> That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success. This is not true in my experience; and I have been professionally writing Haskell for over a decade. It is well understood that Haskell is excellent for reasoning about program correctness, but rather poor for reasoning about program performance/efficiency, especially memory usage. What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?). There are many domains for which correctness and productivity are important, but performance/efficiency less so. Haskell is still much more performant than many dynamic languages are. OCaml is a nice middle ground, lots of functional goodness and type safety with a much more predictable runtime.
- pcthrowaway 5y ago
  > What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?) Haskell actually is used for smart contracts on Cardano (which is also written in Haskell): https://github.com/input-output-hk https://github.com/input-output-hk They haven't been very "successful" yet in the sense of mass adoption (even as far as smart contracts go, EVM-based dapps have multiples more users), but I think this is because of design choices in how the blockchain works moreso than using Haskell for implementation, which limit the usability right now.
  - lazyeye 5y ago
    According to Messari Cardano oscillates between 2nd/3rd most active crypto https://messari.io/screener/most-active-chains-DB01F96B https://messari.io/screener/most-active-chains-DB01F96B Given the head start for Ethereum I would call this very successful in terms of adoption.
    - pcthrowaway 5y ago
      Ethereum and EVM compatible chains are at least 4 years ahead in terms of smart contract activity. Cardano just enabled smart contracts in September of last year, and there's been very little success in terms of usability so far; network scaling upgrades are slated to roll out over the next few years, and the dapps that have deployed don't really work without them. For context, Sundaeswap, a long-awaited DEX just deployed roughly 1 week ago, but people trying to make swaps may have to wait days for their swap to execute, which isn't very ergonomic. The increased activity from people trying to make transactions with Sundaeswap has resulted in sluggishness all-around on the chain as well, because Cardano doesn't have the concept of gas bidding for priority
worldsayshi 5y ago
Haskell has been a huge success in how it has inspired the industry. I believe there is more where that came from. I think Haskell Generics could be really powerful if it was made way more usable and intuitive.
pyrale 5y ago
> Basically, it's 2022. People have tried it and it hasn't worked out. It worked well enough for us when we tried it. I guess the issue is that people and companies really have bad expectations on what "works out" means, and how different languages may need different kinds of environment/investment. If you expect to run a haskell shop the same way you run a java shop, you'll run into trouble as soon as your original team leaves. Likewise, if you run your java shop as you would run a haskell shop, expect trouble.
jodrellblank 5y ago
> "F# has been more successful" F# was built to be successful rather than pure. The Early History of F# writeup[1] talks about Don Syme wanting to get strongly typed functional programming "delivered in such a way that it could be adopted by large numbers of programmers", and SML.NET which was being developed at the time was not looking like it would do that. He then worked with someone to port Haskell to .NET and got it running, but with input from Simon Peyton-Jones decided on a different direction. Then went towards OCaml and whether it could run on either JVM or .NET and had this exchange: > "OCaml already shares a platform with C (at least with the native−code compiler), so all the C libraries are already available... Yet it can still be a lot of effort to link with a C library.[...] There's hard work to be done to realise this vision, but in principle a clean interop story sure beats the endless rehashing of other people's code in language X as a library in language Y. Myself and others involved in the Project 7 are working on one approach to achieve this interop, i.e. compiling languages directly to .NET MS−IL, in the style of MLj, often adding extensions to the language in order to improve the interop. We are also working on improving the .NET infrastructure, proposing support for features such as parametric polymorphism in MS−IL..." That is, Don Syme was not focused on the most pure ideological code first, he wanted something a large number of programmers could use, and adapting the language and tooling for that goal. F# became a thing supported by Microsoft, by Visual Studio, interops with C# libraries, and C# being able to use libraries written in F#, with very low friction as they share the same runtime, garbage collector, basic type library, exception system, etc. Quoting from the PDF again: > "As an aside, I think it would be an interesting question to say "OK, let's take it for granted that the end purpose of our language is to produce components whose interface is expressed in terms of the Java or .NET type systems, but which retains as many of the features and conceptual simplicity of OCaml and ML as possible." I'm not sure exactly what you'd end up with, but whatever it was it could be the language to take over from C\# and/or Java (if that's what you're interested in...) But without really taking Java/.NET component building seriously right from the start I feel you're always just going to end up with a bit of a hack − an interesting, usable hack perhaps, but not a really good language" F# is a bit awkward, not perfectly pure, has to cope with .NET nulls and C# being the big force for the direction of.NET and so on. 20 years later, well who knows but in the StackOverflow survey of 2018 F# is 9th "most loved language" and OCaml is 25th. [1] https://fsharp.org/history/hopl-final/hopl-fsharp.pdf https://fsharp.org/history/hopl-final/hopl-fsharp.pdf (chapter 6, the decision to create F#, particularly) [2] https://insights.stackoverflow.com/survey/2018/#technology https://insights.stackoverflow.com/survey/2018/#technology
deltaonefour 5y ago
I don't think this is a good philosophy to follow. Javascript for example was a terrible language. It's better now because they modified it and most people use typescript... but it was shit starting out and it's initially popularity had nothing to do with how well it worked. I will say that haskell does solve many of the problems we face in software engineering today including coding ourselves into a corner. The problem is the paradigm is extremely hard and that's what hampers its success.

captaincaveman 5y ago

I have similar opinions on Scala, lots of theory that it makes things better, but the only measurable difference is that its a nightmare to hire for, more expensive and we often have to invest time training people ... who then leave to become contractors. I'm not anti functional or Scala, but I'm yet to see any reports etc that actually indicate there is a pay off.

grumpyprole 5y ago
I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java. The underlying issue is that it's a complex language with many experimental and interacting features, which can and do cause a lot of distraction. This is not the fault of functional programming. Have a go at OCaml or F#, which are nice practical sweet spots.
- hocuspocus 5y ago
  The JVM has had specialized bytecode for SAM types for a long time now, you cannot really get more "first-class" than that. And really it's just an implementation detail than doesn't make the language more or less functional. Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
  - grumpyprole 5y ago
    > it's just an implementation detail than doesn't make the language more or less functional. It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages. > Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants. Each has advanced features not offered by the other. > The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two. It was not designed as a functional programming language first and foremost, that is my point.
    - captaincaveman 5y ago
      I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery. I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route. I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!
      - hocuspocus 5y ago
        > I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery. Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?
62951413 5y ago
There are two flavors of Scala and only one of them is about cats/scalaz. I feel intellectually inferior to people who use the latter in production. But I don't think anymore it's a reasonable aspiration to become one of them. And maven builds Scala projects equally well (with half a screen of XML) and without any SBT complexity. I have not seen Bay Area companies where previous Scala experience counts for more than inviting me to an interview. In my current team I know multiple developers who'd like to have more Scala and Java developers who don't know Scala or even Kotlin.

Quekid5 5y ago

Haskell's slogan was "avoid (success at all cost)", so it's hardly surprising that it's been considered niche since its inception. It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct. Is this objective data? No, certainly not, but it's probably better than pure speculation. I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.

andi999 5y ago
I learned that supposedly the Haskell motto "avoid success at all cost" wasnt suppose to mean what people think: https://news.ycombinator.com/item?id=12056169 https://news.ycombinator.com/item?id=12056169 https://discourse.haskell.org/t/new-blog-post-haskell-doomed-to-succeed/1662 https://discourse.haskell.org/t/new-blog-post-haskell-doomed... I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link): "An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…" I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
- pyrale 5y ago
  > I mean, would you want to rest your business on such an attitude? From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
- 5y ago

q-big 5y ago

> (in an industry where successful solutions always get mimicked). This is in my opinion not the case. Just to give one example: WhatsApp managed to get to half a billion users with about 60 employees by using Erlang for their infrastructure. Nevertheless, Erlang is far from being a mainstream language (even though it is used in industry). In my opinion, in what kind of infrastructure is used/mimicked, a lot of hype is involved.

omnicognate 5y ago
That's not the industry I'm talking about. I work in finance.

grumpyprole 5y ago

> That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success. This is not true in my experience; and I have been professionally writing Haskell for over a decade. It is well understood that Haskell is excellent for reasoning about program correctness, but rather poor for reasoning about program performance/efficiency, especially memory usage. What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?). There are many domains for which correctness and productivity are important, but performance/efficiency less so. Haskell is still much more performant than many dynamic languages are. OCaml is a nice middle ground, lots of functional goodness and type safety with a much more predictable runtime.

pcthrowaway 5y ago
> What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?) Haskell actually is used for smart contracts on Cardano (which is also written in Haskell): https://github.com/input-output-hk https://github.com/input-output-hk They haven't been very "successful" yet in the sense of mass adoption (even as far as smart contracts go, EVM-based dapps have multiples more users), but I think this is because of design choices in how the blockchain works moreso than using Haskell for implementation, which limit the usability right now.
- lazyeye 5y ago
  According to Messari Cardano oscillates between 2nd/3rd most active crypto https://messari.io/screener/most-active-chains-DB01F96B https://messari.io/screener/most-active-chains-DB01F96B Given the head start for Ethereum I would call this very successful in terms of adoption.
  - pcthrowaway 5y ago
    Ethereum and EVM compatible chains are at least 4 years ahead in terms of smart contract activity. Cardano just enabled smart contracts in September of last year, and there's been very little success in terms of usability so far; network scaling upgrades are slated to roll out over the next few years, and the dapps that have deployed don't really work without them. For context, Sundaeswap, a long-awaited DEX just deployed roughly 1 week ago, but people trying to make swaps may have to wait days for their swap to execute, which isn't very ergonomic. The increased activity from people trying to make transactions with Sundaeswap has resulted in sluggishness all-around on the chain as well, because Cardano doesn't have the concept of gas bidding for priority

worldsayshi 5y ago

Haskell has been a huge success in how it has inspired the industry. I believe there is more where that came from. I think Haskell Generics could be really powerful if it was made way more usable and intuitive.

pyrale 5y ago

> Basically, it's 2022. People have tried it and it hasn't worked out. It worked well enough for us when we tried it. I guess the issue is that people and companies really have bad expectations on what "works out" means, and how different languages may need different kinds of environment/investment. If you expect to run a haskell shop the same way you run a java shop, you'll run into trouble as soon as your original team leaves. Likewise, if you run your java shop as you would run a haskell shop, expect trouble.

jodrellblank 5y ago

> "F# has been more successful" F# was built to be successful rather than pure. The Early History of F# writeup[1] talks about Don Syme wanting to get strongly typed functional programming "delivered in such a way that it could be adopted by large numbers of programmers", and SML.NET which was being developed at the time was not looking like it would do that. He then worked with someone to port Haskell to .NET and got it running, but with input from Simon Peyton-Jones decided on a different direction. Then went towards OCaml and whether it could run on either JVM or .NET and had this exchange: > "OCaml already shares a platform with C (at least with the native−code compiler), so all the C libraries are already available... Yet it can still be a lot of effort to link with a C library.[...] There's hard work to be done to realise this vision, but in principle a clean interop story sure beats the endless rehashing of other people's code in language X as a library in language Y. Myself and others involved in the Project 7 are working on one approach to achieve this interop, i.e. compiling languages directly to .NET MS−IL, in the style of MLj, often adding extensions to the language in order to improve the interop. We are also working on improving the .NET infrastructure, proposing support for features such as parametric polymorphism in MS−IL..." That is, Don Syme was not focused on the most pure ideological code first, he wanted something a large number of programmers could use, and adapting the language and tooling for that goal. F# became a thing supported by Microsoft, by Visual Studio, interops with C# libraries, and C# being able to use libraries written in F#, with very low friction as they share the same runtime, garbage collector, basic type library, exception system, etc. Quoting from the PDF again: > "As an aside, I think it would be an interesting question to say "OK, let's take it for granted that the end purpose of our language is to produce components whose interface is expressed in terms of the Java or .NET type systems, but which retains as many of the features and conceptual simplicity of OCaml and ML as possible." I'm not sure exactly what you'd end up with, but whatever it was it could be the language to take over from C\# and/or Java (if that's what you're interested in...) But without really taking Java/.NET component building seriously right from the start I feel you're always just going to end up with a bit of a hack − an interesting, usable hack perhaps, but not a really good language" F# is a bit awkward, not perfectly pure, has to cope with .NET nulls and C# being the big force for the direction of.NET and so on. 20 years later, well who knows but in the StackOverflow survey of 2018 F# is 9th "most loved language" and OCaml is 25th. [1] https://fsharp.org/history/hopl-final/hopl-fsharp.pdf https://fsharp.org/history/hopl-final/hopl-fsharp.pdf (chapter 6, the decision to create F#, particularly) [2] https://insights.stackoverflow.com/survey/2018/#technology https://insights.stackoverflow.com/survey/2018/#technology

deltaonefour 5y ago

I don't think this is a good philosophy to follow. Javascript for example was a terrible language. It's better now because they modified it and most people use typescript... but it was shit starting out and it's initially popularity had nothing to do with how well it worked. I will say that haskell does solve many of the problems we face in software engineering today including coding ourselves into a corner. The problem is the paradigm is extremely hard and that's what hampers its success.