7 ms·

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a norm

by nh2 6y ago

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a project to know a wide array of libraries and feel ready to tackle almost anything. The companies involved were happy to make this time investment for increased productivity over the time they expected their employees to stay with them. On an individual level, it makes sense that if you're just getting into programming, and you have the choice between investing 2 weeks into Python to be productive, or 3 months for Haskell, you pick Python. It's rational. But after you've been in it for a few years, and you realise you want to do it for another 40 years, investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger) suddenly becomes a great deal. Counter point on "complex topics": After 6 years of industrial Haskell, I know nothing about category theory. It has not prevented me from using web frameworks.

pydry 6y ago
I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to see why it was chosen for those things.
- JoelMcCracken 6y ago
  Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” and do not advertise it, in fact those who could speak to details are all under NDA. Personally I am hoping to help with this issue by building cool open source things in Haskell (and purescript) I was skeptical for years for all the reasons you said, but I finally decided to set my skepticism aside and see for myself, and oh boy is Haskell great. It has a lot of problems, but I consider myself at least 2x more productive in Haskell.
  - nh2 6y ago
    > “secret weapon” and do not advertise it Both Standard Chartered and Barclays loudly advertise that they use Haskell. A quick web search turns up their job offers on Reddit, and both also send people to conferences such as Haskell eXchange, to talk about their team tasks, structure, and size. Example: [1] Their code bases were discussed on HN before, e.g. [2]. Standard Chartered also funded the development of GHCs low-latency, non-stop-the-world, incremental GC, for 2 years until it was recently released [3]. [1] https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-day-to-day-practice-of-using-haskell-to-write-large-systems https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar... [2] https://news.ycombinator.com/item?id=13073605 https://news.ycombinator.com/item?id=13073605 [3] https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/
    - JoelMcCracken 6y ago
      There are numerous others who do not, though.
    - dmitriid 6y ago
      Is Standard Chartered the bank that actually uses its own eager subset of Haskell and built everything in it from scratch?
      - tome 6y ago
        I'm not sure if you're being facetious or asking a genuine question. The answer is "yes", with the exception of the word "actually". The "eager subset" was written to target a pre-existing runtime, which before then only supported an in-house, fairly poorly-designed, functional language called Lambda. Some of the team there wanted to be able to use Haskell instead (understandably). For stuff that doesn't require that runtime (as convenient as it is) they just use familiar old lazy GHC. My understanding is that they are progressively moving more and more to GHC, although my knowledge is five years out of date.
        6y ago
deleted 6y ago
[deleted]
quickthrower2 6y ago
Thanks for that. Everything you said is from the perspective on being not only in a Haskell job but in a Haskell team. Your 3 months is 5 years for someone trying to learn on their own in their spare time. And then they need this to get a Haskell job due to the competition for such job and the queue of super smart people lining up for a Haskell job. And the pay cuts are brutal. Now you are an outlier, working on a Haskell team for Google, the rare triad of using Haskell at work, presumably being well paid, and having that mentorship from other team members. > After 6 years of industrial Haskell, I know nothing about category theory. It has not prevented me from using web frameworks. As someone in as Haskell team, maybe this is possible. You don't have to try and pick apart the online knowledge. For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens https://hackage.haskell.org/package/lens. "Yeah but it's just X Y Z". Great - I've been to many FP meetups, and seen a lot of stuff online and there is no simple help for this stuff.
- ArchD 6y ago
  > For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens https://hackage.haskell.org/package/lens. You're making it seem harder that it really is. Yes, it's hard if the package documentation is all you have, but that's the hard way to learn. There are other online unofficial documentation and tutorials (of diverse quality). There's also a book (https://leanpub.com/optics-by-example https://leanpub.com/optics-by-example) that I find adequate for a reasonable learning experience (I think I would have saved much time if I had started learning lens using this book.). And, you don't need to know the entire lens package to use it. The most commonly used part of lens (Lens proper, not Prisms, Isos, etc) is only a small fraction of the whole thing.
  - quickthrower2 6y ago
    Ah OK, things have moved on in recent years. Maybe there are more resources out there than I thought.
    - 6y ago
co_dh 6y ago
It was google, a bad sample of programmers.
- nh2 6y ago
  It's odd how the various smaller companies I referred to, many of which are normal enough that you may never have heard of them, get summarised as "It was Google". I only mentioned it to also include the largest org I know where onboarding onto a Haskell project was not a problem.
  - sizeofchar 6y ago
    I think he meant "bad sample" in the sense that those programmers aren't representative of abilities of average programmers. Ie, he thinks Google programmers are top programmers.
    - nh2 6y ago
      I got that, and it's an often-heard argument, which is why I stated that it worked as described for other companies as well.
cpeterso 6y ago
Can you share what kind of system your Haskell team worked on at Google? I thought Google projects were limited to a few blessed languages. Once upon a time that was Java, C++, and Python but I guess that would now include Go and Rust (in parts of Fuchsia and possibly Chrome).
- nh2 6y ago
  Yes: Ganeti, an open-source cluster-management system: https://en.wikipedia.org/wiki/Ganeti https://en.wikipedia.org/wiki/Ganeti
- seangrogg 6y ago
  Ex-googler here: While the "blessed languages" still exist in a way, it's mostly about not really needing to explain the language choice when considering/pitching a project. Choosing a different language (such as Haskell) is allowed, sure, but it'll be one more hurdle to clear when trying to get go-ahead compared to just using, say, Java.
dmitriid 6y ago
> It takes 2-3 weeks of full-time onboarding > It takes around 3 months of full-time participation Compare that to Erlang's half a day to a day for onboarding, and one to two weeks before pushing stuff to prod. I can't imagine any company that could afford three full-time weeks of onboarding. > investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger) The tales of increased productivity are purely anecdotal. Especially if you're talking about a few percentage points.
- Rick1 6y ago
  > I can't imagine any company that could afford three full-time weeks of onboarding. Oh yes. Months even. Routinely.
- jerf 6y ago
  "Compare that to Erlang's half a day to a day for onboarding," Erlang's a half day for onboarding if you're onboarding a Haskell programmer, not because Haskell programmers are that awesome but because they've already had to learn the hard things involved in Erlang to work with Haskell [1]. Otherwise, that's ludicrous nonsense. Most programmers will need several hours just to figure out how to write the equivalent of lists:map in the new Erlang, immutable world, more hours to figure out how to write things non-trivially with it, and a good couple of weeks at a bare minimum to figure out how to structure applications in an OTP world, then some more time to figure out how to debug it. It's not especially harder than learning SQL or the latest Javascript framework or other things that aren't Algol-descended languages, but it's nowhere near that easy. [1] I went the other way. I found Erlang an excellent introduction to Haskell; you get to absorb some of the challenges like working in pervasive immutability in an environment where you're not also swallowing a complicated type system or strict effects separation.
hopia 6y ago
I'd say it took roughly 3 months on my own to learn enough Haskell to write a web server that does what I want. So I'd expect with professional coaching a smart person would end up on a decent level in 3 months, ready to put code to production.
kungato 6y ago
My first job was at faang and it took me 3 months to be productive in C# working on a compiler and everyone said 3 months is expected so 3 months for Haskell is nice
svara 6y ago
Parent comment said 100 hours to be productive, 1000 to be reasonable, so your experience (2-3 weeks, 3 months) is actually pretty close to that.
- foolmeonce 6y ago
  True, but then the multiple for C# is either nonsense or a false comparison of going between near identical languages or of writing code of very different quality and utility. There are plenty of cases where a broken notebook is about as good as a spreadsheet, and languages suited/typical to that use have a psychological victory that results in apples to oranges comparisons.
deleted 6y ago
[deleted]
yomly 6y ago
Incidentally, I am learning Haskell right now. And fwiw don't have a CS degree. I think the difficulty of Haskell is overrated. It's just different. The crowd who complain about Haskell being hard despite x years experience are the same people who speak English and think Mandarin is hard. And yet 1.7+ billion people speak Mandarin, and most linguists agree that English is actually the harder language owing to its more branched roots. Haskell is what happens when you go full lambda calculus, and the dedication to referential transparency really forces you down some interesting paths/abstractions. It's also worth noting that other functional languages like OCaml and lisp do not force purity so the idioms are not as extreme. The impedance mismatch essentially boils down to Turing Machine vs Lambda Calculus and as such you don't find many familiar friends when switching camp (to begin with, at least!) The Haskell idioms are very different and the consequences of referential transparency ripple throughout the way you need to think about computation. It's also worth noting that Haskell is a language laid bare - much of the features and abstractions are plain-old functions which means you can "just" duck into them, implement them for yourself or read them as libraries. But what we often forget is all the abstractions we needed to learn when grokking "programming" (which was probably imperative style programming) the first time round. Most people have moved on from the time when trying to conceptualise what an object is or how methods work or even working with mutable state. When you get to design patterns - some of the implementations are quite complex the first time round. Eg the visitor pattern/double dispatch is not particularly simple when you sit down and manually expand the execution of those calls and yet when you use it, it's quite simple. When we program with objects, most of us don't stop to think about vtables anymore* we just use the object to solve our immediate problem. The more I see of Haskell, the more confident I am that it just uses a very different set of abstractions that you can just use and forget about except you get the benefit of a HM type system and referentially transparent code. It's also nice that that itself somewhat forces you towards a more functional-core imperative style architecture where your business logic is pure and mostly happy path code and your boundary is a bunch of monad imperative glue. I think at the end of the day FP makes the hard things easy and the easy things hard. But as the Turing Machine and Lambda Calculus are equivalent then being adept at both schools is like having twice the arsenal for dealing with a given problem. *naturally when performance becomes a problem you start to unravel abstractions.
- 6y ago

by nh2 6y ago

pydry 6y ago

I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to see why it was chosen for those things.

JoelMcCracken 6y ago
Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” and do not advertise it, in fact those who could speak to details are all under NDA. Personally I am hoping to help with this issue by building cool open source things in Haskell (and purescript) I was skeptical for years for all the reasons you said, but I finally decided to set my skepticism aside and see for myself, and oh boy is Haskell great. It has a lot of problems, but I consider myself at least 2x more productive in Haskell.
- nh2 6y ago
  > “secret weapon” and do not advertise it Both Standard Chartered and Barclays loudly advertise that they use Haskell. A quick web search turns up their job offers on Reddit, and both also send people to conferences such as Haskell eXchange, to talk about their team tasks, structure, and size. Example: [1] Their code bases were discussed on HN before, e.g. [2]. Standard Chartered also funded the development of GHCs low-latency, non-stop-the-world, incremental GC, for 2 years until it was recently released [3]. [1] https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-day-to-day-practice-of-using-haskell-to-write-large-systems https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar... [2] https://news.ycombinator.com/item?id=13073605 https://news.ycombinator.com/item?id=13073605 [3] https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/
  - JoelMcCracken 6y ago
    There are numerous others who do not, though.
  - dmitriid 6y ago
    Is Standard Chartered the bank that actually uses its own eager subset of Haskell and built everything in it from scratch?
    - tome 6y ago
      I'm not sure if you're being facetious or asking a genuine question. The answer is "yes", with the exception of the word "actually". The "eager subset" was written to target a pre-existing runtime, which before then only supported an in-house, fairly poorly-designed, functional language called Lambda. Some of the team there wanted to be able to use Haskell instead (understandably). For stuff that doesn't require that runtime (as convenient as it is) they just use familiar old lazy GHC. My understanding is that they are progressively moving more and more to GHC, although my knowledge is five years out of date.
      - 6y ago

deleted 6y ago

[deleted]

quickthrower2 6y ago

Thanks for that. Everything you said is from the perspective on being not only in a Haskell job but in a Haskell team. Your 3 months is 5 years for someone trying to learn on their own in their spare time. And then they need this to get a Haskell job due to the competition for such job and the queue of super smart people lining up for a Haskell job. And the pay cuts are brutal. Now you are an outlier, working on a Haskell team for Google, the rare triad of using Haskell at work, presumably being well paid, and having that mentorship from other team members. > After 6 years of industrial Haskell, I know nothing about category theory. It has not prevented me from using web frameworks. As someone in as Haskell team, maybe this is possible. You don't have to try and pick apart the online knowledge. For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens https://hackage.haskell.org/package/lens. "Yeah but it's just X Y Z". Great - I've been to many FP meetups, and seen a lot of stuff online and there is no simple help for this stuff.

ArchD 6y ago
> For example a lot of libraries use Lens. I want to understand Lens? It is not simple: check out the diagram on https://hackage.haskell.org/package/lens https://hackage.haskell.org/package/lens. You're making it seem harder that it really is. Yes, it's hard if the package documentation is all you have, but that's the hard way to learn. There are other online unofficial documentation and tutorials (of diverse quality). There's also a book (https://leanpub.com/optics-by-example https://leanpub.com/optics-by-example) that I find adequate for a reasonable learning experience (I think I would have saved much time if I had started learning lens using this book.). And, you don't need to know the entire lens package to use it. The most commonly used part of lens (Lens proper, not Prisms, Isos, etc) is only a small fraction of the whole thing.
- quickthrower2 6y ago
  Ah OK, things have moved on in recent years. Maybe there are more resources out there than I thought.
  - 6y ago

co_dh 6y ago

It was google, a bad sample of programmers.

nh2 6y ago
It's odd how the various smaller companies I referred to, many of which are normal enough that you may never have heard of them, get summarised as "It was Google". I only mentioned it to also include the largest org I know where onboarding onto a Haskell project was not a problem.
- sizeofchar 6y ago
  I think he meant "bad sample" in the sense that those programmers aren't representative of abilities of average programmers. Ie, he thinks Google programmers are top programmers.
  - nh2 6y ago
    I got that, and it's an often-heard argument, which is why I stated that it worked as described for other companies as well.

cpeterso 6y ago

Can you share what kind of system your Haskell team worked on at Google? I thought Google projects were limited to a few blessed languages. Once upon a time that was Java, C++, and Python but I guess that would now include Go and Rust (in parts of Fuchsia and possibly Chrome).

nh2 6y ago
Yes: Ganeti, an open-source cluster-management system: https://en.wikipedia.org/wiki/Ganeti https://en.wikipedia.org/wiki/Ganeti
seangrogg 6y ago
Ex-googler here: While the "blessed languages" still exist in a way, it's mostly about not really needing to explain the language choice when considering/pitching a project. Choosing a different language (such as Haskell) is allowed, sure, but it'll be one more hurdle to clear when trying to get go-ahead compared to just using, say, Java.

dmitriid 6y ago

> It takes 2-3 weeks of full-time onboarding > It takes around 3 months of full-time participation Compare that to Erlang's half a day to a day for onboarding, and one to two weeks before pushing stuff to prod. I can't imagine any company that could afford three full-time weeks of onboarding. > investing 3 months for life-long increased productivity (even if it's just a few percentage points; most feel the effect is larger) The tales of increased productivity are purely anecdotal. Especially if you're talking about a few percentage points.

Rick1 6y ago
> I can't imagine any company that could afford three full-time weeks of onboarding. Oh yes. Months even. Routinely.
jerf 6y ago
"Compare that to Erlang's half a day to a day for onboarding," Erlang's a half day for onboarding if you're onboarding a Haskell programmer, not because Haskell programmers are that awesome but because they've already had to learn the hard things involved in Erlang to work with Haskell [1]. Otherwise, that's ludicrous nonsense. Most programmers will need several hours just to figure out how to write the equivalent of lists:map in the new Erlang, immutable world, more hours to figure out how to write things non-trivially with it, and a good couple of weeks at a bare minimum to figure out how to structure applications in an OTP world, then some more time to figure out how to debug it. It's not especially harder than learning SQL or the latest Javascript framework or other things that aren't Algol-descended languages, but it's nowhere near that easy. [1] I went the other way. I found Erlang an excellent introduction to Haskell; you get to absorb some of the challenges like working in pervasive immutability in an environment where you're not also swallowing a complicated type system or strict effects separation.

hopia 6y ago

I'd say it took roughly 3 months on my own to learn enough Haskell to write a web server that does what I want. So I'd expect with professional coaching a smart person would end up on a decent level in 3 months, ready to put code to production.

kungato 6y ago

My first job was at faang and it took me 3 months to be productive in C# working on a compiler and everyone said 3 months is expected so 3 months for Haskell is nice

svara 6y ago

Parent comment said 100 hours to be productive, 1000 to be reasonable, so your experience (2-3 weeks, 3 months) is actually pretty close to that.

foolmeonce 6y ago
True, but then the multiple for C# is either nonsense or a false comparison of going between near identical languages or of writing code of very different quality and utility. There are plenty of cases where a broken notebook is about as good as a spreadsheet, and languages suited/typical to that use have a psychological victory that results in apples to oranges comparisons.

deleted 6y ago

[deleted]

yomly 6y ago

Incidentally, I am learning Haskell right now. And fwiw don't have a CS degree. I think the difficulty of Haskell is overrated. It's just different. The crowd who complain about Haskell being hard despite x years experience are the same people who speak English and think Mandarin is hard. And yet 1.7+ billion people speak Mandarin, and most linguists agree that English is actually the harder language owing to its more branched roots. Haskell is what happens when you go full lambda calculus, and the dedication to referential transparency really forces you down some interesting paths/abstractions. It's also worth noting that other functional languages like OCaml and lisp do not force purity so the idioms are not as extreme. The impedance mismatch essentially boils down to Turing Machine vs Lambda Calculus and as such you don't find many familiar friends when switching camp (to begin with, at least!) The Haskell idioms are very different and the consequences of referential transparency ripple throughout the way you need to think about computation. It's also worth noting that Haskell is a language laid bare - much of the features and abstractions are plain-old functions which means you can "just" duck into them, implement them for yourself or read them as libraries. But what we often forget is all the abstractions we needed to learn when grokking "programming" (which was probably imperative style programming) the first time round. Most people have moved on from the time when trying to conceptualise what an object is or how methods work or even working with mutable state. When you get to design patterns - some of the implementations are quite complex the first time round. Eg the visitor pattern/double dispatch is not particularly simple when you sit down and manually expand the execution of those calls and yet when you use it, it's quite simple. When we program with objects, most of us don't stop to think about vtables anymore* we just use the object to solve our immediate problem. The more I see of Haskell, the more confident I am that it just uses a very different set of abstractions that you can just use and forget about except you get the benefit of a HM type system and referentially transparent code. It's also nice that that itself somewhat forces you towards a more functional-core imperative style architecture where your business logic is pure and mostly happy path code and your boundary is a bunch of monad imperative glue. I think at the end of the day FP makes the hard things easy and the easy things hard. But as the Turing Machine and Lambda Calculus are equivalent then being adept at both schools is like having twice the arsenal for dealing with a given problem. *naturally when performance becomes a problem you start to unravel abstractions.

6y ago