4 ms·

>Haskell people skew smarter than most other languages. But are they more productive, get shit that we care about done, or do they go down monadic rabbit holes

>Haskell people skew smarter than most other languages. But are they more productive, get shit that we care about done, or do they go down monadic rabbit holes? By all means Haskell away in your pet projects, but having a company invest into a team to deliver things customers want, I'd like to see some evidence this makes sense outside specific niche areas (Cardarno possibly being a good example where it makes sense).

benreesman 5y ago
There is a lot of “I wish this was Agfa so I could really flex” jerk-off stuff in Haskell. But I’ve seen way more useful software fall down the show off well in C++ than in Haskell. I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.”
- captaincaveman 5y ago
  That quote is something I had in mind when I wrote that message :) And your spot on with the C++ reference, but there its more the case the language was adopted in industry then it expanded into intellectual twiddling, Haskell has that as its starting point. Don't get me wrong I like programming in Haskell, C++ and others, I enjoy going beyond what I need to get the job done and amusing myself in doing things 'clever' ways. But no longer being paid to write the code and having different concerns to manage, its hard to qualify Haskell as a good choice.
  - captaincaveman 5y ago
    Having said all that, I probably would be biased towards someone that has Haskell on their CV (doesn't need to be commercial) as it would indicate intellectual curiosity (and probably some capability) in their profession!
- eru 5y ago
  > I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.” I never agreed with the conclusion. Clearly the observation implies that you should use all your brain power to write your code in such a way that it is easy to read, understand and debug. That often means using eg the right abstraction for the job. Not the dumbest one.
  - sulam 5y ago
    My bonafides for the comment I’m about to make: 5 years of professional Scala development at a serious Scala house. I have never done Haskell, but many of my co-workers have, and I had at least one interviewee do all his coding in it (he got hired, not because Haskell). The problem really nice abstractions have is that they encode too much into too little code. They are very concise, and people who aren’t as knowledgeable (avoiding the word “smart” here as I think it’s wrong) will treat it as “magic”. Magic in code is a really bad idea when you need to debug it. The ML type system can create these magic moments that make someone who actually wants to understand how the hell that works have to go down a multi-hour rabbit hole just to figure it out. The best example of this that I’ve directly worked with is Finagle. If you look at the code for it, you’re very often left scratching your head trying to understand how it manages to get so much done with so little code. Having been there while it was developed, I will say it didn’t start off that “pretty”, it got there over 3 fairly major revisions to the underlying type abstractions. The result is beautiful, but opaque to most of the mere mortals that use it. I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.
    - jrumbut 5y ago
      I tend to believe in the value of those magic moments and think we should raise expectations in terms of training and practice to appreciate and understand them (I've never used Finagle so I don't know the specifics of it, maybe it is beyond any reasonable standard of comprehensibility). The problem is when the magic isn't happening. How do you convince yourself or someone you work with to take off the wizard hat, come down out of the clouds and implement the naive/verbose/ugly solution because the elegant stroke of genius hasn't come and the feature is taking forever? This is where Go and PHP shine, less temptation to guild the lily.
Tainnor 5y ago
> But are they more productive, get shit that we care about done [...] I think there's a balance to be struck between "getting shit done" and "write something that will be maintainable in the future". It might be true that (some?) Haskellers overdo it, but I've definitely seen enough of the "let's just get shit done" people who create messes that are completely unmaintainable and full of bugs after just a year or two. And IMHO, the software industry is in a really sorry state, considering how bug-riddled most software is, how most software projects fail or are considerably above budget, etc. [1] I've seen quite a number of failed projects in the companies I've been so far, a number of them involving quite a lot of resources. I've seen companies trying to rewrite hopeless messes and failing at it, grinding everything to a halt, because the code base is full of implicit assumptions that nobody bothered to properly specify anywhere. I've read about Shopify spending a whole year to upgrade to a newer version of Ruby on Rails.[2] Probably the industry doesn't yet know how best to find this balance but I don't think that the Haskellers are solely to blame for this. [1]: https://danluu.com/everything-is-broken/ https://danluu.com/everything-is-broken/ [2]: https://shopify.engineering/upgrading-shopify-to-rails-5-0 https://shopify.engineering/upgrading-shopify-to-rails-5-0

benreesman 5y ago

There is a lot of “I wish this was Agfa so I could really flex” jerk-off stuff in Haskell. But I’ve seen way more useful software fall down the show off well in C++ than in Haskell. I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.”

captaincaveman 5y ago
That quote is something I had in mind when I wrote that message :) And your spot on with the C++ reference, but there its more the case the language was adopted in industry then it expanded into intellectual twiddling, Haskell has that as its starting point. Don't get me wrong I like programming in Haskell, C++ and others, I enjoy going beyond what I need to get the job done and amusing myself in doing things 'clever' ways. But no longer being paid to write the code and having different concerns to manage, its hard to qualify Haskell as a good choice.
- captaincaveman 5y ago
  Having said all that, I probably would be biased towards someone that has Haskell on their CV (doesn't need to be commercial) as it would indicate intellectual curiosity (and probably some capability) in their profession!
eru 5y ago
> I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.” I never agreed with the conclusion. Clearly the observation implies that you should use all your brain power to write your code in such a way that it is easy to read, understand and debug. That often means using eg the right abstraction for the job. Not the dumbest one.
- sulam 5y ago
  My bonafides for the comment I’m about to make: 5 years of professional Scala development at a serious Scala house. I have never done Haskell, but many of my co-workers have, and I had at least one interviewee do all his coding in it (he got hired, not because Haskell). The problem really nice abstractions have is that they encode too much into too little code. They are very concise, and people who aren’t as knowledgeable (avoiding the word “smart” here as I think it’s wrong) will treat it as “magic”. Magic in code is a really bad idea when you need to debug it. The ML type system can create these magic moments that make someone who actually wants to understand how the hell that works have to go down a multi-hour rabbit hole just to figure it out. The best example of this that I’ve directly worked with is Finagle. If you look at the code for it, you’re very often left scratching your head trying to understand how it manages to get so much done with so little code. Having been there while it was developed, I will say it didn’t start off that “pretty”, it got there over 3 fairly major revisions to the underlying type abstractions. The result is beautiful, but opaque to most of the mere mortals that use it. I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.
  - jrumbut 5y ago
    I tend to believe in the value of those magic moments and think we should raise expectations in terms of training and practice to appreciate and understand them (I've never used Finagle so I don't know the specifics of it, maybe it is beyond any reasonable standard of comprehensibility). The problem is when the magic isn't happening. How do you convince yourself or someone you work with to take off the wizard hat, come down out of the clouds and implement the naive/verbose/ugly solution because the elegant stroke of genius hasn't come and the feature is taking forever? This is where Go and PHP shine, less temptation to guild the lily.

Tainnor 5y ago

> But are they more productive, get shit that we care about done [...] I think there's a balance to be struck between "getting shit done" and "write something that will be maintainable in the future". It might be true that (some?) Haskellers overdo it, but I've definitely seen enough of the "let's just get shit done" people who create messes that are completely unmaintainable and full of bugs after just a year or two. And IMHO, the software industry is in a really sorry state, considering how bug-riddled most software is, how most software projects fail or are considerably above budget, etc. [1] I've seen quite a number of failed projects in the companies I've been so far, a number of them involving quite a lot of resources. I've seen companies trying to rewrite hopeless messes and failing at it, grinding everything to a halt, because the code base is full of implicit assumptions that nobody bothered to properly specify anywhere. I've read about Shopify spending a whole year to upgrade to a newer version of Ruby on Rails.[2] Probably the industry doesn't yet know how best to find this balance but I don't think that the Haskellers are solely to blame for this. [1]: https://danluu.com/everything-is-broken/ https://danluu.com/everything-is-broken/ [2]: https://shopify.engineering/upgrading-shopify-to-rails-5-0 https://shopify.engineering/upgrading-shopify-to-rails-5-0