6 ms·

This is my experience with haskell: I work for a small data science consulting company whose major components of a machine learning pipeline were written in ha

by dcl 7y ago

This is my experience with haskell: I work for a small data science consulting company whose major components of a machine learning pipeline were written in haskell. The company got bought by a large corporate and shortly after, all the haskell developers left, leaving a handful of people (including myself) who didn't know how to use or maintain the major components of a multi million dollar acquisition. It is in the process of being scrapped and replaced with a more typical software stack. Hilarious times.

baot 7y ago
They can't afford a few thousand for training, so spend more thousands rewriting? The original Haskell devs had to learn, too.
- dcl 7y ago
  The new ownership probably had no idea what they actually bought. I think to be fair, whilst it may have been cheaper to hire new devs than rewrite everything, it would have taken a while to learn and become proficient enough to use and properly maintain the existing codebase properly.
- empath75 7y ago
  You can’t just train any software developer to code in Haskell. It’s not an easy language to learn and a lot of programmers don’t want to learn it. And even if they managed to train up the current staff, they will either have to continuously hire Haskell programmers or continuously hire people who don’t know Haskell and hope they’re able to learn it.
  - seddona 7y ago
    I think this is an important point actually. Programming languages (at least in the context being discussed) are just a means to model a problem domain. Some people find it easier to model domains in strongly typed functional languages but at a much larger percentage do not. Let's for argument's sake say it's 1% of all programmers. That is still a huge number of people though.
    - galaxyLogic 7y ago
      It could be argued that coming up with the original model was easier done in Haskell by the expert Haskell developers. Translating it to another language is more or less mechanical task. Then the maintenance and further development can happen in a more commonly known language. In other words languages like Haskell, Lisp etc. are precisely good for modeling the problem and its solution, so it can make sense to use them for that even if later development is best done translated into a simpler-to-use language.
  - the_af 7y ago
    > [Haskell is] not an easy language to learn To be fair, purportedly "easy" languages such as Java aren't actually easy. True, a lot of people can write (or copy paste from online articles) crappy Java code full of bugs and performance issues and nobody will notice since this low quality seems to be some kind of industry standard. But there aren't that many good Java developers either. A similar argument used to be made about PHP: anyone can use it. To write poor software, that is. As for Haskell: it's different enough to Java-like and C-like languages that it's difficult to wrap your mind about it if you come from those languages. But if you start fresh, it's not that hard. Some years ago someone here on HN posted pretty good results when teaching Haskell to kids. Young kids pick it up surprisingly fast. It's not inherently difficult, and in fact some of its concepts may be easier to grasp than traditional imperative languages. (And no, you don't need to understand category theory at all in order to program with Haskell).
    - Silhouette 7y ago
      As for Haskell ... if you start fresh, it's not that hard. I'm going to respectfully disagree with that. I do understand the point you're making. In fact, my own experience of having taught beginners without preconceptions to program is consistent with that point. However, the "scale" of a language (including all the strange edge cases) is very relevant for production use and particularly maintenance. Even if you stick to a core of widely understood language features and libraries yourself, you might still have to maintain code written by someone else that uses more obscure features or complicated interactions between features. For Haskell, that "scale" is usually determined in practice by GHC plus whatever language extensions anyone has turned on plus whatever libraries they've found from Hackage or elsewhere. Those language extensions are numerous, and they can not only add new language features but also change existing code to behave in different and potentially unexpected ways. As a platform for research and development of programming language concepts, that is a benefit. As a practical programming language for production use, it is a huge liability.
      - UserIsUnused 7y ago
        The complexity lies in the ecosystem (GHC, extensions) rather than the language itself. But yeah, I agree, comparing the haskell you learn at your first programming course, and the production haskell, it's like 2 different worlds
  - lostcolony 7y ago
    "It’s not an easy language to learn" - pure opinion. "and a lot of programmers don’t want to learn it" - also opinion, but I'd be very curious to also know how the quality of those who do want to learn it compare to those who don't.
- BeetleB 7y ago
  No - they don't want to keep paying thousands for training every time someone leaves. And it's a lot of thousands - don't merely count the cost of training. Count the salary they are being paid while they learn.
  - nilkn 7y ago
    There's always a ramp-up period for new employees. While it's hard to learn Haskell completely on your own, it's not that hard to learn Haskell if you join a team of experienced Haskell developers. Once they build up a competent team, absorbing new team members really wouldn't be that hard. The only problem here is really that the entire team left -- that would've been a pretty big problem for any complex software system regardless of the language it was written in.
    - gregorygoc 7y ago
      Agreed 100%. There’s so much domain knowledge in a lot of systems that run in production for a couple of years that the disappearance of the entire team means basically a full rewrite.
moomin 7y ago
The classic argument against every language that isn’t Java.
- gpderetta 7y ago
  True. Then again, standardization of tools is a good thing.
  - joelfolksy 7y ago
    Not if it brings progress to a standstill.
    - nomel 7y ago
      Progress to a standstill? Making code that solves problems, so that money can be made, is the goal of any software house that wants to ever have a positive cash flow. If it were easier or cheaper to hire for and write code in Haskell, which would make this goal easier to achieve, then it would already be used, and this the case in some domains. Beyond those specific domains, not many companies have the spare resources to donate to progressing the ideas/ideals of software development, unless there's a real, monetary, ROI. For many houses, there is none, at the moment. It's always cheaper/easier to optimize in the environment one is currently in.
atopuzov 7y ago
Speaks more about the quality of the management/leadership then haskell itself.
- dcl 7y ago
  No doubt. Just wanted to share my experience, and the potential risks of starting a large project (or acquiring one) in a language most 'coders' aren't familiar with :o
  - the_af 7y ago
    There are potential risks, but didn't Paul Graham argue (about Lisp) that some of these less familiar languages can be your "special weapon"?
  - dunefox 7y ago
    I wouldn't want to have most 'coders' on a project like this anyway...
  - TheCoelacanth 7y ago
    It's a deathblow to a large project to simultaneously lose all developers regardless of what language its written in.
- wolco 7y ago
  It speaks to what may happen when the orginal haskell developers leave. Highly likely it will be rewritten.
  - excursionist 7y ago
    I mean, when your whole core development team leaves, you have bigger problems than programming language choice.
    - nybble41 7y ago
      Exactly. The value is in the mental model the development team has accrued through working on the code, not the code itself.[1][2] If you lose the code but retain the development team then the code can be rewritten. Lose the team but keep the code, as in this case, and you're left with a bunch of software that no one really understands how to maintain, much less improve on, without working at cross-purposes to the original design. For a new team to develop the same degree of experience and familiarity with the codebase as the original team is only marginally less work than reimplementing it from scratch. At that point the language it's written is the least of your issues. [1] http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf [2] https://news.ycombinator.com/item?id=10833278 https://news.ycombinator.com/item?id=10833278
Silhouette 7y ago
While this is certainly a legitimate concern, we should also consider how much of that multi-million dollar value derived from the use of Haskell up to that point. Put another way, had a "more typical software stack" been used originally, would the acquired business still have achieved the same things and been as attractive for acquisition?
crimsonalucard 7y ago
I bet you the new stack will have more bugs and be significantly more complex and harder to maintain. But you will find tons and tons of developers willing to continuously add technical debt to it.
rowanG077 7y ago
Why not just learn Haskell? It would be decidedly faster then re-implementing everything...
nicoburns 7y ago
Why don't they hire Haskell developers to replace the ones who are leaving? If your company's Java developers were leaving, they'd be ridiculed for deciding to rewrite the codebase. Is it really that hard to hire Haskell developers?
c3534l 7y ago
I've seen this happen with Perl and Ruby (both replaced with Python). Being able to replace workers is not an insignificant business risk. A small company outside of a major tech hub just can't support the development of software in nonstandard languages. I love Haskell, but I couldn't tell my boss that we should invest time in learning yet another technology to train people in just because its my favorite language.
mic47 7y ago
Just curious, what was the reason that Haskell developer left? I know 1 company where this happened, but there Haskell developers left because management decided to move to python (without them even knowing its under consideration).
deleted 7y ago
[deleted]

by dcl 7y ago

baot 7y ago

They can't afford a few thousand for training, so spend more thousands rewriting? The original Haskell devs had to learn, too.

dcl 7y ago
The new ownership probably had no idea what they actually bought. I think to be fair, whilst it may have been cheaper to hire new devs than rewrite everything, it would have taken a while to learn and become proficient enough to use and properly maintain the existing codebase properly.
empath75 7y ago
You can’t just train any software developer to code in Haskell. It’s not an easy language to learn and a lot of programmers don’t want to learn it. And even if they managed to train up the current staff, they will either have to continuously hire Haskell programmers or continuously hire people who don’t know Haskell and hope they’re able to learn it.
- seddona 7y ago
  I think this is an important point actually. Programming languages (at least in the context being discussed) are just a means to model a problem domain. Some people find it easier to model domains in strongly typed functional languages but at a much larger percentage do not. Let's for argument's sake say it's 1% of all programmers. That is still a huge number of people though.
  - galaxyLogic 7y ago
    It could be argued that coming up with the original model was easier done in Haskell by the expert Haskell developers. Translating it to another language is more or less mechanical task. Then the maintenance and further development can happen in a more commonly known language. In other words languages like Haskell, Lisp etc. are precisely good for modeling the problem and its solution, so it can make sense to use them for that even if later development is best done translated into a simpler-to-use language.
- the_af 7y ago
  > [Haskell is] not an easy language to learn To be fair, purportedly "easy" languages such as Java aren't actually easy. True, a lot of people can write (or copy paste from online articles) crappy Java code full of bugs and performance issues and nobody will notice since this low quality seems to be some kind of industry standard. But there aren't that many good Java developers either. A similar argument used to be made about PHP: anyone can use it. To write poor software, that is. As for Haskell: it's different enough to Java-like and C-like languages that it's difficult to wrap your mind about it if you come from those languages. But if you start fresh, it's not that hard. Some years ago someone here on HN posted pretty good results when teaching Haskell to kids. Young kids pick it up surprisingly fast. It's not inherently difficult, and in fact some of its concepts may be easier to grasp than traditional imperative languages. (And no, you don't need to understand category theory at all in order to program with Haskell).
  - Silhouette 7y ago
    As for Haskell ... if you start fresh, it's not that hard. I'm going to respectfully disagree with that. I do understand the point you're making. In fact, my own experience of having taught beginners without preconceptions to program is consistent with that point. However, the "scale" of a language (including all the strange edge cases) is very relevant for production use and particularly maintenance. Even if you stick to a core of widely understood language features and libraries yourself, you might still have to maintain code written by someone else that uses more obscure features or complicated interactions between features. For Haskell, that "scale" is usually determined in practice by GHC plus whatever language extensions anyone has turned on plus whatever libraries they've found from Hackage or elsewhere. Those language extensions are numerous, and they can not only add new language features but also change existing code to behave in different and potentially unexpected ways. As a platform for research and development of programming language concepts, that is a benefit. As a practical programming language for production use, it is a huge liability.
    - UserIsUnused 7y ago
      The complexity lies in the ecosystem (GHC, extensions) rather than the language itself. But yeah, I agree, comparing the haskell you learn at your first programming course, and the production haskell, it's like 2 different worlds
- lostcolony 7y ago
  "It’s not an easy language to learn" - pure opinion. "and a lot of programmers don’t want to learn it" - also opinion, but I'd be very curious to also know how the quality of those who do want to learn it compare to those who don't.
BeetleB 7y ago
No - they don't want to keep paying thousands for training every time someone leaves. And it's a lot of thousands - don't merely count the cost of training. Count the salary they are being paid while they learn.
- nilkn 7y ago
  There's always a ramp-up period for new employees. While it's hard to learn Haskell completely on your own, it's not that hard to learn Haskell if you join a team of experienced Haskell developers. Once they build up a competent team, absorbing new team members really wouldn't be that hard. The only problem here is really that the entire team left -- that would've been a pretty big problem for any complex software system regardless of the language it was written in.
  - gregorygoc 7y ago
    Agreed 100%. There’s so much domain knowledge in a lot of systems that run in production for a couple of years that the disappearance of the entire team means basically a full rewrite.

moomin 7y ago

The classic argument against every language that isn’t Java.

gpderetta 7y ago
True. Then again, standardization of tools is a good thing.
- joelfolksy 7y ago
  Not if it brings progress to a standstill.
  - nomel 7y ago
    Progress to a standstill? Making code that solves problems, so that money can be made, is the goal of any software house that wants to ever have a positive cash flow. If it were easier or cheaper to hire for and write code in Haskell, which would make this goal easier to achieve, then it would already be used, and this the case in some domains. Beyond those specific domains, not many companies have the spare resources to donate to progressing the ideas/ideals of software development, unless there's a real, monetary, ROI. For many houses, there is none, at the moment. It's always cheaper/easier to optimize in the environment one is currently in.

atopuzov 7y ago

Speaks more about the quality of the management/leadership then haskell itself.

dcl 7y ago
No doubt. Just wanted to share my experience, and the potential risks of starting a large project (or acquiring one) in a language most 'coders' aren't familiar with :o
- the_af 7y ago
  There are potential risks, but didn't Paul Graham argue (about Lisp) that some of these less familiar languages can be your "special weapon"?
- dunefox 7y ago
  I wouldn't want to have most 'coders' on a project like this anyway...
- TheCoelacanth 7y ago
  It's a deathblow to a large project to simultaneously lose all developers regardless of what language its written in.
wolco 7y ago
It speaks to what may happen when the orginal haskell developers leave. Highly likely it will be rewritten.
- excursionist 7y ago
  I mean, when your whole core development team leaves, you have bigger problems than programming language choice.
  - nybble41 7y ago
    Exactly. The value is in the mental model the development team has accrued through working on the code, not the code itself.[1][2] If you lose the code but retain the development team then the code can be rewritten. Lose the team but keep the code, as in this case, and you're left with a bunch of software that no one really understands how to maintain, much less improve on, without working at cross-purposes to the original design. For a new team to develop the same degree of experience and familiarity with the codebase as the original team is only marginally less work than reimplementing it from scratch. At that point the language it's written is the least of your issues. [1] http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf [2] https://news.ycombinator.com/item?id=10833278 https://news.ycombinator.com/item?id=10833278

Silhouette 7y ago

While this is certainly a legitimate concern, we should also consider how much of that multi-million dollar value derived from the use of Haskell up to that point. Put another way, had a "more typical software stack" been used originally, would the acquired business still have achieved the same things and been as attractive for acquisition?

crimsonalucard 7y ago

I bet you the new stack will have more bugs and be significantly more complex and harder to maintain. But you will find tons and tons of developers willing to continuously add technical debt to it.

rowanG077 7y ago

Why not just learn Haskell? It would be decidedly faster then re-implementing everything...

nicoburns 7y ago

Why don't they hire Haskell developers to replace the ones who are leaving? If your company's Java developers were leaving, they'd be ridiculed for deciding to rewrite the codebase. Is it really that hard to hire Haskell developers?

c3534l 7y ago

I've seen this happen with Perl and Ruby (both replaced with Python). Being able to replace workers is not an insignificant business risk. A small company outside of a major tech hub just can't support the development of software in nonstandard languages. I love Haskell, but I couldn't tell my boss that we should invest time in learning yet another technology to train people in just because its my favorite language.

mic47 7y ago

Just curious, what was the reason that Haskell developer left? I know 1 company where this happened, but there Haskell developers left because management decided to move to python (without them even knowing its under consideration).

deleted 7y ago

[deleted]