5 ms·

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And i

by gip 7y ago

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the other is rewriting the codebase in Rust.

verttii 7y ago
> it lacks a lot of features to make it useable at scale. Can you elaborate on this?
danharaj 7y ago
Hey you. I'm pretty sure I know who you are :) I hope everything's going well! I definitely agree that there are many examples of ineffective Haskell culture. As a Haskell contractor I get to see how a lot of different shops do things. One thing I can't really tease apart is that most startups have a lot of engineering culture problems, and picking Haskell doesn't inoculate you from that effect. The main cultural issue I see specific to Haskell shops is that frequently rabbit holes aren't discouraged. By that, I mean there is too much of a tinkerer mentality where engineers are allowed to or even encouraged to experiment with untested ideas instead of known effective solutions. That is a habit I had to deprogram myself from too. It's very fun! In your spare time. I hope we get to work together again! But I'm usually only called in if there's trouble, so maybe I shouldn't :^)
- dukerutledge 7y ago
  This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that can solve all your problems (maybe with a bit more code than enabling 20 extensions will afford you).
  - tempguy9999 7y ago
    I had a similar experience with a different language at a startup where one programmer particularly would produce the most horrid code, use new features and libraries where they weren't needed, generally overcomplicate everything. He was smart as hell and made that smartness a liability for everyone else. The bottom line in a business is the bottom line; making money. He didn't understand that at all. No level of abstraction was too high, even trivial stuff. Dumb code that did the job well... dream on.
ljm 7y ago
I’ve met some pretty damn solid engineers who started on Haskell and, even at a junior level in other languages, produce an elegant solution far more easily than a senior engineer in that language. You probably wouldn’t put the code in production verbatim but you can very easily see what’s going on and it isn’t haunted by spectre of early abstraction, which IMO is the biggest flaw of OOP at scale. People think you want to see clean architecture in the form of lots of indirection and state and then you don’t see any real programming chops, just organisation or filing. Not at all related to Haskell specifically, but damn, it does cut through the boilerplate. Although I can’t comment on any sort of Haskell at scale and I imagine they have the same issues when it comes to excessive point-free/applicative style. I mean, from my naive perspective it’s easy to make classes out of everything, and to hold state and put side-effects everywhere, but you don’t want to deal with the trouble of a monad until you need it. So you have an automatic inclination towards cleaner code when you start functional and move on.
- marcosdumay 7y ago
  Haskell gives one plenty of rope to hang himself on complexity. So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable. You'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll never caught me using this thing that I just invented!"
  - mbrodersen 7y ago
    > Haskell gives one plenty of rope to hang himself on complexity. Interesting. And C++/Java/Javascript doesn't? > So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable. Wow that sounds like there would be lots of examples you can mention. Care to mention any example we can verify? > ou'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll never caught me using this thing that I just invented!" I have never seen such articles. Please show us a few links?
maximente 7y ago
in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. many engineers (and businesses!), culturally, come from the opposite angle (legions of generally pluggable engineers on java/python/golang plowing through tickets/features). that's fine, but it isn't super amenable to the Haskell world, because IME non-imperative setups require different mode of thinking about design, so harder to drop in and crush a ticket. i wish i could explain this more, but i'm struggling to articulate with examples. i think the thorough types really help you get up to speed on data structures, but unless you are in a functional mindset pretty much exclusively, your (my?) brain spends a lot of time un-imperative-ing itself. also, laziness can be a factor, so need some expertise there. it also helps to have conventions e.g. old school java (are we point free, or not? etc. etc.) all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that.
- dukerutledge 7y ago
  > all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that. Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc. All these disciplines seem to boil down to the same systemic result, push effects to the edges of you program so you can more easily test, evolve and maintain. Functional programming (of the typed variety) tends to allow me to write garbage code, that is testable and can be easily evolved and maintained because the paradigm encourages me to be a good actor. I've refactored production code in imperative languages and typed functional languages and only one of them allowed me to make HUGE sweeping changes with ease and high confidence.
timbuckley 7y ago
> It's a beautiful language but it lacks a lot of features to make it useable at scale. Can you expand on this? What features is it missing?
whateveracct 7y ago
My experience is upper management will scapegoat Haskell the moment they get the chance. Outside-hired leaders who doubt it from the start. It's a weird unpopular language - an easy target. If you just get over it & use Haskell, things will be fine. You'll get huge gains thanks to a lot of Haskell features & libraries, and you might have to write some more fundamental libraries yourself. Haskell makes that pleasant anyways. Worst-case, using Haskell could end up being a wash vs other languages. Rewrites aren't always indicative of failures of language or the engineers writing it. They're also a useful mechanism for solidifying control for a VPE-type at a nascent but quickly-growing startup. Especially if said VPE-type wants to push out personnel that were there before them.
- kccqzy 7y ago
  I totally agree. When a project using Java fails, people would never think to blame the choice of Java as a contributing factor. When a project using Haskell fails, people will consider Haskell to be contributing to its failure even if the root cause lies elsewhere (bad management, bad culture, etc).
  - smitty1e 7y ago
    Maybe not Java proper, but I've heard copious abuse heaped upon Hibernate. Now, we shouldn't blame the tool, but the performance was bad, and the induced race conditions were a dagger to the heart for the project.
mbrodersen 7y ago
> it lacks a lot of features to make it useable at scale Facebook (and other companies) run Haskell in production, at scale. So I wonder what those "lots of missing features" you mention are? With "lots of them" I am sure you can mention at least 5+?
runeks 7y ago
> […] it lacks a lot of features to make it useable at scale. Can you give an example or two?

by gip 7y ago

verttii 7y ago

> it lacks a lot of features to make it useable at scale. Can you elaborate on this?

danharaj 7y ago

Hey you. I'm pretty sure I know who you are :) I hope everything's going well! I definitely agree that there are many examples of ineffective Haskell culture. As a Haskell contractor I get to see how a lot of different shops do things. One thing I can't really tease apart is that most startups have a lot of engineering culture problems, and picking Haskell doesn't inoculate you from that effect. The main cultural issue I see specific to Haskell shops is that frequently rabbit holes aren't discouraged. By that, I mean there is too much of a tinkerer mentality where engineers are allowed to or even encouraged to experiment with untested ideas instead of known effective solutions. That is a habit I had to deprogram myself from too. It's very fun! In your spare time. I hope we get to work together again! But I'm usually only called in if there's trouble, so maybe I shouldn't :^)

dukerutledge 7y ago
This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that can solve all your problems (maybe with a bit more code than enabling 20 extensions will afford you).
- tempguy9999 7y ago
  I had a similar experience with a different language at a startup where one programmer particularly would produce the most horrid code, use new features and libraries where they weren't needed, generally overcomplicate everything. He was smart as hell and made that smartness a liability for everyone else. The bottom line in a business is the bottom line; making money. He didn't understand that at all. No level of abstraction was too high, even trivial stuff. Dumb code that did the job well... dream on.

ljm 7y ago

I’ve met some pretty damn solid engineers who started on Haskell and, even at a junior level in other languages, produce an elegant solution far more easily than a senior engineer in that language. You probably wouldn’t put the code in production verbatim but you can very easily see what’s going on and it isn’t haunted by spectre of early abstraction, which IMO is the biggest flaw of OOP at scale. People think you want to see clean architecture in the form of lots of indirection and state and then you don’t see any real programming chops, just organisation or filing. Not at all related to Haskell specifically, but damn, it does cut through the boilerplate. Although I can’t comment on any sort of Haskell at scale and I imagine they have the same issues when it comes to excessive point-free/applicative style. I mean, from my naive perspective it’s easy to make classes out of everything, and to hold state and put side-effects everywhere, but you don’t want to deal with the trouble of a monad until you need it. So you have an automatic inclination towards cleaner code when you start functional and move on.

marcosdumay 7y ago
Haskell gives one plenty of rope to hang himself on complexity. So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable. You'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll never caught me using this thing that I just invented!"
- mbrodersen 7y ago
  > Haskell gives one plenty of rope to hang himself on complexity. Interesting. And C++/Java/Javascript doesn't? > So much that developers develop an aversion to it as deep as fear. It's unavoidable, the ones that didn't develop it are still buried at the working of their first Rube Goldberg machine and unavailable. Wow that sounds like there would be lots of examples you can mention. Care to mention any example we can verify? > ou'll see plenty of blogs about a Haskell feature that end with "See? It's organized and safe. It works. Is it worth the complexity? No way! You'll never caught me using this thing that I just invented!" I have never seen such articles. Please show us a few links?

maximente 7y ago

in my (limited) experience, Haskell projects (and to a slightly lesser extent, functional programming projects) work best when thoroughly planned out in thorough whiteboard/spec sessions and are then implemented by a couple of gurus responsible for the code, who work almost exclusively in functional languages in their day to day. there seems to be a need for way more thought-per-line-of-code in Haskell/FP projects. many engineers (and businesses!), culturally, come from the opposite angle (legions of generally pluggable engineers on java/python/golang plowing through tickets/features). that's fine, but it isn't super amenable to the Haskell world, because IME non-imperative setups require different mode of thinking about design, so harder to drop in and crush a ticket. i wish i could explain this more, but i'm struggling to articulate with examples. i think the thorough types really help you get up to speed on data structures, but unless you are in a functional mindset pretty much exclusively, your (my?) brain spends a lot of time un-imperative-ing itself. also, laziness can be a factor, so need some expertise there. it also helps to have conventions e.g. old school java (are we point free, or not? etc. etc.) all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that.

dukerutledge 7y ago
> all in all i think it requires a lot of discipline that can easily break down, whereas some of the popular imperative languages you can still sort of plug along (=> punt the technical debt) despite that. Interestingly I have the exact opposite perspective. Writing imperative or OOP code requires me to be excessively disciplined. It is extremely easy to build un-maintainable spaghetti. There is a whole cottage industry of methods for your discipline of choice: Clean, SOLID, TDD, etc. All these disciplines seem to boil down to the same systemic result, push effects to the edges of you program so you can more easily test, evolve and maintain. Functional programming (of the typed variety) tends to allow me to write garbage code, that is testable and can be easily evolved and maintained because the paradigm encourages me to be a good actor. I've refactored production code in imperative languages and typed functional languages and only one of them allowed me to make HUGE sweeping changes with ease and high confidence.

timbuckley 7y ago

> It's a beautiful language but it lacks a lot of features to make it useable at scale. Can you expand on this? What features is it missing?

whateveracct 7y ago

My experience is upper management will scapegoat Haskell the moment they get the chance. Outside-hired leaders who doubt it from the start. It's a weird unpopular language - an easy target. If you just get over it & use Haskell, things will be fine. You'll get huge gains thanks to a lot of Haskell features & libraries, and you might have to write some more fundamental libraries yourself. Haskell makes that pleasant anyways. Worst-case, using Haskell could end up being a wash vs other languages. Rewrites aren't always indicative of failures of language or the engineers writing it. They're also a useful mechanism for solidifying control for a VPE-type at a nascent but quickly-growing startup. Especially if said VPE-type wants to push out personnel that were there before them.

kccqzy 7y ago
I totally agree. When a project using Java fails, people would never think to blame the choice of Java as a contributing factor. When a project using Haskell fails, people will consider Haskell to be contributing to its failure even if the root cause lies elsewhere (bad management, bad culture, etc).
- smitty1e 7y ago
  Maybe not Java proper, but I've heard copious abuse heaped upon Hibernate. Now, we shouldn't blame the tool, but the performance was bad, and the induced race conditions were a dagger to the heart for the project.

mbrodersen 7y ago

> it lacks a lot of features to make it useable at scale Facebook (and other companies) run Haskell in production, at scale. So I wonder what those "lots of missing features" you mention are? With "lots of them" I am sure you can mention at least 5+?

runeks 7y ago

> […] it lacks a lot of features to make it useable at scale. Can you give an example or two?