4 ms·

Usually people who talk like this haven’t dealt with functional programming in the real world. I fell in love with the beauty of functional programming in grad

by mlthoughts2018 7y ago

Usually people who talk like this haven’t dealt with functional programming in the real world. I fell in love with the beauty of functional programming in grad school. After using Haskell in a real business setting for many years, no thanks. The code and headaches and weird bugs are just as bad as with any other language or paradigm. The type checking doesn’t actually help you to create functionally correct systems at all (let alone the false claims that it makes this process faster). Putting designs into the type system doesn’t matter. It’s little more than a useful mind-expanding way to think about code, but ultimately just as applicable to other paradigms. Mutating state is very often the right tool for the job. Plenty of experienced functional programmers write immutable, pattern-focused functional programming implementations that are full of bugs, confusing misdirection, unsafe handling of data, etc. Library support is still insanely poor compared with C/C++, Python and Java. You have to insanely careful not to allow architectural astronauts to build out inscrutable systems that satisfy their weird personal opinions about aesthetics or interface design. Hiring more engineers is super hard. Building in safety for when senior engineers choose to leave is even harder. Integrations with emerging technologies like new database systems or new statistical packages always lags way behind other languages and usually exists in some half-finished form that depends on labor of love from some isolated hobbyist. In terms of basic business decision making, I cannot recommend enough to avoid functional programming.

jimbokun 7y ago
> Integrations with emerging technologies like new database systems or new statistical packages always lags way behind other languages and usually exists in some half-finished form that depends on labor of love from some isolated hobbyist. This really sets Clojure apart from Haskell, in that you can use any Java library with almost zero friction.
- mlthoughts2018 7y ago
  I don’t have experience in Clojure but I do have experience in Scala where this claim is also made often. In Scala anyway, it’s totally false. Firstly there’s just a huge impedence mismatch between code relying on Scala features and code serving as a Java wrapper into Scala. But even just the basic usage of the libraries doesn’t always work. I very nearly quit a job once just from the incredible frustration of trying to use JFreeChart in Scala.
  - jimbokun 7y ago
    For a while, a few years ago, I wrote a lot of scripts and personal tooling in Clojure, calling Java APIs. I don't remember really having any difficulties calling Java code from Clojure.
  - blandflakes 7y ago
    It's a very different world in Clojure. Data structures mutually satisfy the relevant interfaces, and there's no real pain about how a java.util.Map isn't immutable and so on.
edw 7y ago
I don't agree with your conclusions, but that didn't stop me from upvoting your comment. You touch on all sorts of important issues management should consider while deciding whether to adopt an oddball programming language or technology as the basis of its business. I write this as a CTO that chose Clojure as the basis for our now-acquired and fully-metabolized-by-the-buyer startup. You better make sure the person who is advocating for the oddball technology… * Is going to stick around; even cofounders sometimes bail or get caught. * Understands the opportunity costs i.e. what is being given up by not using boring tech. * Has used the tech on the ground and not just in a comp sci lab or to implement a to-do app. * Will be able to grow i.e. recruit additional members to the team as the needs of the business grow. * Really is a 10X programmer -- assuming they exist. * Can sell the decision (in a way that doesn't consume undue positive karma) to VCs, customers, acquirers, etc. In my situation, Clojure worked for us because I'd already spent years writing Clojure (and Scheme and Lisp) code and I understood the problem domain (I was the head of product at the time) and I had made a personal commitment to the CEO to stick around for at least two years and I managed to not get arrested or do anything awkwardly disgraceful. We also got lucky in that Clojure had a bit of a moment as a smart person's programming language in the mid two thousand teens. If I weren't hands-on, I probably wouldn't have advocated for Clojure and instead would have opted for something mainstream for backend infrastructure at the time e.g. Java, Node.js, Python.
throwaway286 7y ago
Do you have any thoughts on Elixir? I've been playing around with it and Haskell at the same time. Compared to Haskell, Elixir's dynamic type system and impurity make it a lot more practical to get stuff done, in my experience.
- verttii 7y ago
  I'm just like you. I use Elixir for anything serious and Haskell for personal or small scale projects. The way I see it is that Haskell abstracts away the runtime considerations. You spend the majority of your time modeling your business domain in Haskell. Or rather, retrofitting your business model into Haskell's type system. In Elixir, in contrast, you spend the majority of your time building systems, in other words on runtime problems. All the tooling and even the whole OTP revolves around this. For anything that runs on the web, this is a major benefit compared to Haskell.
BasDirks 7y ago
> The type checking doesn’t actually help you to create functionally correct systems at all (let alone the false claims that it makes this process faster). This is a red flag to me. Of course the tool doesn't guarantee the result, but your story smells of incompetence. I've introduced FP and a focus on types-as-a-tool at the places I've worked and hired accordingly. Quality and speed of development have gone up after minimal time investment. A battle of n=1 I guess?
- mlthoughts2018 7y ago
  Not really. People make all kinds of crazy claims about the benefits of static type checking or compiler enforcements. These are perfectly fine tools, but you can achieve the exact same thing with a low effort set of unit tests most of the time. The teams I’ve worked on with functional programming always had super senior engineers, people who had previously spent serious time on core GHC development and people who had worked as compiler engineers at e.g. Lightbend. They displayed all the same sources of slowness, defects, deadline and/or feature creep, bad designs leading to required refactors or rework, etc., as any teams I’ve been a part of that do everything in Python. Static type enforcement is just a tool like anything else. It locates a certain class of code problems at compile or type checking time, that’s all. In most large projects, speeding up the detection of this class of errors is just not very important, and can be extremely well approximated with low effort test cases and other techniques.
verttii 7y ago
This kinds of harsh yet legitimate criticism puts me off from spending more time on the notoriously steep Haskell learning curve.
- tome 7y ago
  I wouldn't let it put you off. mlthoughts2018 is pretty much the only commenter on HN who has seriously used Haskell yet also complains about it.
  - verttii 7y ago
    But on the other hand, it's been hard to put my finger on the tangible benefits of all that time spent on Haskell. I'm worried that I end up going deep into that rabbit hole without really benefiting from it.
    - tome 7y ago
      I think that's fine, as long as it's your own decision from your own experience. On the other hand if you're struggling with anything in particular then we tend to be friendly and helpful over at https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/. The monthly Hask Anything threads might be useful for you.
      - verttii 7y ago
        I've posted questions there before but unfortunately got no replies. However, some friendly folks at Slack helped me a lot.

jimbokun 7y ago

> Integrations with emerging technologies like new database systems or new statistical packages always lags way behind other languages and usually exists in some half-finished form that depends on labor of love from some isolated hobbyist. This really sets Clojure apart from Haskell, in that you can use any Java library with almost zero friction.

mlthoughts2018 7y ago
I don’t have experience in Clojure but I do have experience in Scala where this claim is also made often. In Scala anyway, it’s totally false. Firstly there’s just a huge impedence mismatch between code relying on Scala features and code serving as a Java wrapper into Scala. But even just the basic usage of the libraries doesn’t always work. I very nearly quit a job once just from the incredible frustration of trying to use JFreeChart in Scala.
- jimbokun 7y ago
  For a while, a few years ago, I wrote a lot of scripts and personal tooling in Clojure, calling Java APIs. I don't remember really having any difficulties calling Java code from Clojure.
- blandflakes 7y ago
  It's a very different world in Clojure. Data structures mutually satisfy the relevant interfaces, and there's no real pain about how a java.util.Map isn't immutable and so on.

edw 7y ago

I don't agree with your conclusions, but that didn't stop me from upvoting your comment. You touch on all sorts of important issues management should consider while deciding whether to adopt an oddball programming language or technology as the basis of its business. I write this as a CTO that chose Clojure as the basis for our now-acquired and fully-metabolized-by-the-buyer startup. You better make sure the person who is advocating for the oddball technology… * Is going to stick around; even cofounders sometimes bail or get caught. * Understands the opportunity costs i.e. what is being given up by not using boring tech. * Has used the tech on the ground and not just in a comp sci lab or to implement a to-do app. * Will be able to grow i.e. recruit additional members to the team as the needs of the business grow. * Really is a 10X programmer -- assuming they exist. * Can sell the decision (in a way that doesn't consume undue positive karma) to VCs, customers, acquirers, etc. In my situation, Clojure worked for us because I'd already spent years writing Clojure (and Scheme and Lisp) code and I understood the problem domain (I was the head of product at the time) and I had made a personal commitment to the CEO to stick around for at least two years and I managed to not get arrested or do anything awkwardly disgraceful. We also got lucky in that Clojure had a bit of a moment as a smart person's programming language in the mid two thousand teens. If I weren't hands-on, I probably wouldn't have advocated for Clojure and instead would have opted for something mainstream for backend infrastructure at the time e.g. Java, Node.js, Python.

throwaway286 7y ago

Do you have any thoughts on Elixir? I've been playing around with it and Haskell at the same time. Compared to Haskell, Elixir's dynamic type system and impurity make it a lot more practical to get stuff done, in my experience.

verttii 7y ago
I'm just like you. I use Elixir for anything serious and Haskell for personal or small scale projects. The way I see it is that Haskell abstracts away the runtime considerations. You spend the majority of your time modeling your business domain in Haskell. Or rather, retrofitting your business model into Haskell's type system. In Elixir, in contrast, you spend the majority of your time building systems, in other words on runtime problems. All the tooling and even the whole OTP revolves around this. For anything that runs on the web, this is a major benefit compared to Haskell.

BasDirks 7y ago

> The type checking doesn’t actually help you to create functionally correct systems at all (let alone the false claims that it makes this process faster). This is a red flag to me. Of course the tool doesn't guarantee the result, but your story smells of incompetence. I've introduced FP and a focus on types-as-a-tool at the places I've worked and hired accordingly. Quality and speed of development have gone up after minimal time investment. A battle of n=1 I guess?

mlthoughts2018 7y ago
Not really. People make all kinds of crazy claims about the benefits of static type checking or compiler enforcements. These are perfectly fine tools, but you can achieve the exact same thing with a low effort set of unit tests most of the time. The teams I’ve worked on with functional programming always had super senior engineers, people who had previously spent serious time on core GHC development and people who had worked as compiler engineers at e.g. Lightbend. They displayed all the same sources of slowness, defects, deadline and/or feature creep, bad designs leading to required refactors or rework, etc., as any teams I’ve been a part of that do everything in Python. Static type enforcement is just a tool like anything else. It locates a certain class of code problems at compile or type checking time, that’s all. In most large projects, speeding up the detection of this class of errors is just not very important, and can be extremely well approximated with low effort test cases and other techniques.

verttii 7y ago

This kinds of harsh yet legitimate criticism puts me off from spending more time on the notoriously steep Haskell learning curve.

tome 7y ago
I wouldn't let it put you off. mlthoughts2018 is pretty much the only commenter on HN who has seriously used Haskell yet also complains about it.
- verttii 7y ago
  But on the other hand, it's been hard to put my finger on the tangible benefits of all that time spent on Haskell. I'm worried that I end up going deep into that rabbit hole without really benefiting from it.
  - tome 7y ago
    I think that's fine, as long as it's your own decision from your own experience. On the other hand if you're struggling with anything in particular then we tend to be friendly and helpful over at https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/. The monthly Hask Anything threads might be useful for you.
    - verttii 7y ago
      I've posted questions there before but unfortunately got no replies. However, some friendly folks at Slack helped me a lot.