5 ms·

It is worth learning, but the chances of using it for more than toy scripts are slim. Unless your workplace has already bought into it, you'll find it a hard s

It is worth learning, but the chances of using it for more than toy scripts are slim. Unless your workplace has already bought into it, you'll find it a hard sell. There are several other functional languages out there with more vibrant communities that have useful libraries. One selling point, the terseness/simplicity of code, can be a specious one. Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness in a general sense often require more cryptic constructs as scaffolding. One developer friend made a comment that summarizes functional languages well in practice: "They're very useful, but try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project."

nightski 9y ago
It's not like you avoid the problem by going to languages with less foundation in math. You just tend to end up with leaky abstractions (which break the laws found in this math disdained so much) and hard to maintain code (technical debt). It might be worth the trade off some times but we do waste a lot of time on this. Probably more than it would take to learn these concepts.
- kangdolit 9y ago
  I've seen just as many FP projects strain under technical debt as I have OO projects. Technical debt is a product of the developers, not the language. And FP developers are just as imperfect as OO developers.
  - nightski 9y ago
    We have not invented a language that is immune to technical debt or leaky abstractions. Haskell's type system is not rich enough to let us impose all the constraints implied by the mathematics. However it is a significant improvement on allowing one to express the constraints in the type system preventing large classes of bugs and towards providing proper abstractions. Let's not throw the baby out with the bathwater. No one is claiming FP developers are "better" than OO developers. In fact why would anyone ever classify themselves as one or the other? Instead we should use the best tools for the job.
  - runT1ME 9y ago
    I find this claim dubious. I have been in the industry a long time and I have found the opposite.
    - ddito 9y ago
      Could you elaborate?
      - runT1ME 9y ago
        I've worked on teams of various sizes and skills writing OO applications and trying to use inheritance and OO to get code reuse is always a nightmare. I currently work on large project with hundreds of Scala engineers of various abilities, and structuring our code in functional ways has bought us a ton of reuse and prevented a lot of technical debt. We primarily write libraries, and our 'applications' are more or less throw away code because of how small they end up being (because they can leverage many of our libraries). Testing is easier in functional land (for various reasons), which means regressions are much harder to introduce, which means refactoring can happen faster, which means less technical debt.
  - dkarl 9y ago
    There is a kind of technical "debt" imposed when you can't express the simplest solution in a straightforward way in the language you're using. I put "debt" in quotes because in a strict sense it isn't really debt, because you can't escape the payments by paying off the principle. It's more like a tax that drains away a portion of your effort every time you touch the code.
PopsiclePete 9y ago
I haven't written a single non-toy Haskell line, but I really believe it's somehow made me a better programmer overall. Few languages can do that.
dmix 9y ago
Well, the more people learn it the more this answer is less true. So there's also that. I would have loved to used Clojure throughout the last 5-6 yrs but never found a company using it in Toronto. I'm sure everyone used the same rationale. The popularity of a language really does have a self-reinforcing aspect to it. Although there's no guarantee it will always be that way if people really do find the development experience to be superior. Smart devs can learn new languages pretty quickly. I wish Haskell was easier to start using like Go was.
tathougies 9y ago
> They're very useful, but try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project. Have you ever learned a 'design pattern' in Java, Python, C++, etc? What's the difference between learning this and learning about monoids (for example). Monoids are super easy and actually compose, unlike the majority of design patterns. In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. I feel if people start with mainly FP, then OOP is what seems odd and necessitating learning odd, abstract concepts, except there's the added bonus that all the abstractions are leaky. Ultimately though, you don't even need to learn any algebra or category theory. It was multiple years after I had already learned and started using Haskell that I even began to become interested in these topics. My interest was mainly piqued by a desire to not duplicate code -- it certainly isn't required to learn algebra to understand Haskell, in the same way it's not required to understand machine assembly to program in C++, or GPU transistor layout to understand OpenGL. > a general sense often require more cryptic constructs as scaffolding. My professional experience is mainly as a Haskell dev. What is 'scaffolding'. I don't think I've ever used such a thing.
- kangdolit 9y ago
  "All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky > In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. You supported my argument. In addition to this, there are many code academies that pump out graduates with almost no mathematical foundation work. Until that changes, functional languages will always take the back seat.
  - lmm 9y ago
    > "All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky If you learn Haskell you will see this is total bollocks.
    - 9y ago
dom0 9y ago
> Unless your workplace has already bought into it, you'll find it a hard sell. I know a company that tried to hire a Haskell guy to support some existing Haskell software for more than a year with literally two applications. Just finding professional devs for it seems to be hard.
- haskellandchill 9y ago
  Well they did a bad job. The market is flooded with decent Haskell devs right now.
- nbouscal 9y ago
  My company just hired a Haskell developer; it took less than a month and we had plenty of highly qualified applicants. It actually made us reconsider how many engineers we were planning to hire, because it was easier than we expected. By comparison, we also have Ruby code, and finding equally talented Ruby developers has been much more difficult.
runT1ME 9y ago
>Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness I think if you assume 'terseness' is the goal of constructs such as map/flatMap you're missing the forest for the trees. Yes terseness can be a good thing, it sacrifices familiarity for the ability to understand more going on in a quicker amount of time. This can definitely reduce cognitive overheard for someone familiar with the constructs being used. This however, is a secondary (but pleasant) side effect of the main goal which is (non leaky) abstraction. By using familiar abstractions it allows readers to reason about code in a powerful way, allowing for more reuse and composition.
cies 9y ago
> the chances of using it for more than toy scripts are slim If you are proficient in Haskell and willing to relocate, I believe there are some amazing opportunities for you. You'll work with really smart people and be innovating. I see investment banks, startups and defense contractors using this language. Interesting mix. > you'll find it a hard sell So was Ruby at some point. But oh boy how much quicker was I writing those web apps in 2005 because of it! > try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project Good quote. But it does not "summarizes functional languages well" in my opinion. It shows that you should keep the clever stuff in libraries, such that colleagues do not have to trip over it.
- kangdolit 9y ago
  Ruby was a hard sell, but not Rails, which is how Ruby slipped into the fold.
WillPostForFood 9y ago
Haskell does have some corporate adoption. Facebook uses it, and one of their Clojure based projects just switched over to Haskell. https://wit.ai/blog/2017/05/01/new-duckling https://wit.ai/blog/2017/05/01/new-duckling
kowdermeister 9y ago
> ...know abstract algebra and category theory How true is this? I never seen a FP tutorial that started with this or even mentioned it. Or is this simply an assumption that it should be known before even trying to take Haskell seriously?
ajsdlfkjklasdj 9y ago
This is the common generic response to Haskell evangelism. It's so boring and yet yields so many responses because of its provocativeness.
- kangdolit 9y ago
  I agree. It's because Haskell evangelism is often the tech equivalent of gluten-free or vegetarianism - It's great because it's something not mainstream! It'll solve problems you never knew you had! However, on the bright side, at least we're not discussing LISP.

nightski 9y ago

It's not like you avoid the problem by going to languages with less foundation in math. You just tend to end up with leaky abstractions (which break the laws found in this math disdained so much) and hard to maintain code (technical debt). It might be worth the trade off some times but we do waste a lot of time on this. Probably more than it would take to learn these concepts.

kangdolit 9y ago
I've seen just as many FP projects strain under technical debt as I have OO projects. Technical debt is a product of the developers, not the language. And FP developers are just as imperfect as OO developers.
- nightski 9y ago
  We have not invented a language that is immune to technical debt or leaky abstractions. Haskell's type system is not rich enough to let us impose all the constraints implied by the mathematics. However it is a significant improvement on allowing one to express the constraints in the type system preventing large classes of bugs and towards providing proper abstractions. Let's not throw the baby out with the bathwater. No one is claiming FP developers are "better" than OO developers. In fact why would anyone ever classify themselves as one or the other? Instead we should use the best tools for the job.
- runT1ME 9y ago
  I find this claim dubious. I have been in the industry a long time and I have found the opposite.
  - ddito 9y ago
    Could you elaborate?
    - runT1ME 9y ago
      I've worked on teams of various sizes and skills writing OO applications and trying to use inheritance and OO to get code reuse is always a nightmare. I currently work on large project with hundreds of Scala engineers of various abilities, and structuring our code in functional ways has bought us a ton of reuse and prevented a lot of technical debt. We primarily write libraries, and our 'applications' are more or less throw away code because of how small they end up being (because they can leverage many of our libraries). Testing is easier in functional land (for various reasons), which means regressions are much harder to introduce, which means refactoring can happen faster, which means less technical debt.
- dkarl 9y ago
  There is a kind of technical "debt" imposed when you can't express the simplest solution in a straightforward way in the language you're using. I put "debt" in quotes because in a strict sense it isn't really debt, because you can't escape the payments by paying off the principle. It's more like a tax that drains away a portion of your effort every time you touch the code.

PopsiclePete 9y ago

I haven't written a single non-toy Haskell line, but I really believe it's somehow made me a better programmer overall. Few languages can do that.

dmix 9y ago

Well, the more people learn it the more this answer is less true. So there's also that. I would have loved to used Clojure throughout the last 5-6 yrs but never found a company using it in Toronto. I'm sure everyone used the same rationale. The popularity of a language really does have a self-reinforcing aspect to it. Although there's no guarantee it will always be that way if people really do find the development experience to be superior. Smart devs can learn new languages pretty quickly. I wish Haskell was easier to start using like Go was.

tathougies 9y ago

> They're very useful, but try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project. Have you ever learned a 'design pattern' in Java, Python, C++, etc? What's the difference between learning this and learning about monoids (for example). Monoids are super easy and actually compose, unlike the majority of design patterns. In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. I feel if people start with mainly FP, then OOP is what seems odd and necessitating learning odd, abstract concepts, except there's the added bonus that all the abstractions are leaky. Ultimately though, you don't even need to learn any algebra or category theory. It was multiple years after I had already learned and started using Haskell that I even began to become interested in these topics. My interest was mainly piqued by a desire to not duplicate code -- it certainly isn't required to learn algebra to understand Haskell, in the same way it's not required to understand machine assembly to program in C++, or GPU transistor layout to understand OpenGL. > a general sense often require more cryptic constructs as scaffolding. My professional experience is mainly as a Haskell dev. What is 'scaffolding'. I don't think I've ever used such a thing.

kangdolit 9y ago
"All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky > In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. You supported my argument. In addition to this, there are many code academies that pump out graduates with almost no mathematical foundation work. Until that changes, functional languages will always take the back seat.
- lmm 9y ago
  > "All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky If you learn Haskell you will see this is total bollocks.
  - 9y ago

dom0 9y ago

> Unless your workplace has already bought into it, you'll find it a hard sell. I know a company that tried to hire a Haskell guy to support some existing Haskell software for more than a year with literally two applications. Just finding professional devs for it seems to be hard.

haskellandchill 9y ago
Well they did a bad job. The market is flooded with decent Haskell devs right now.
nbouscal 9y ago
My company just hired a Haskell developer; it took less than a month and we had plenty of highly qualified applicants. It actually made us reconsider how many engineers we were planning to hire, because it was easier than we expected. By comparison, we also have Ruby code, and finding equally talented Ruby developers has been much more difficult.

runT1ME 9y ago

>Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness I think if you assume 'terseness' is the goal of constructs such as map/flatMap you're missing the forest for the trees. Yes terseness can be a good thing, it sacrifices familiarity for the ability to understand more going on in a quicker amount of time. This can definitely reduce cognitive overheard for someone familiar with the constructs being used. This however, is a secondary (but pleasant) side effect of the main goal which is (non leaky) abstraction. By using familiar abstractions it allows readers to reason about code in a powerful way, allowing for more reuse and composition.

cies 9y ago

> the chances of using it for more than toy scripts are slim If you are proficient in Haskell and willing to relocate, I believe there are some amazing opportunities for you. You'll work with really smart people and be innovating. I see investment banks, startups and defense contractors using this language. Interesting mix. > you'll find it a hard sell So was Ruby at some point. But oh boy how much quicker was I writing those web apps in 2005 because of it! > try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project Good quote. But it does not "summarizes functional languages well" in my opinion. It shows that you should keep the clever stuff in libraries, such that colleagues do not have to trip over it.

kangdolit 9y ago
Ruby was a hard sell, but not Rails, which is how Ruby slipped into the fold.

WillPostForFood 9y ago

Haskell does have some corporate adoption. Facebook uses it, and one of their Clojure based projects just switched over to Haskell. https://wit.ai/blog/2017/05/01/new-duckling https://wit.ai/blog/2017/05/01/new-duckling

kowdermeister 9y ago

> ...know abstract algebra and category theory How true is this? I never seen a FP tutorial that started with this or even mentioned it. Or is this simply an assumption that it should be known before even trying to take Haskell seriously?

ajsdlfkjklasdj 9y ago

This is the common generic response to Haskell evangelism. It's so boring and yet yields so many responses because of its provocativeness.

kangdolit 9y ago
I agree. It's because Haskell evangelism is often the tech equivalent of gluten-free or vegetarianism - It's great because it's something not mainstream! It'll solve problems you never knew you had! However, on the bright side, at least we're not discussing LISP.