10 ms·

When I asked my current employer why they chose it, they simply responded that it attracts the "right" people. From a business perspective, any language is arbi

When I asked my current employer why they chose it, they simply responded that it attracts the "right" people. From a business perspective, any language is arbitrary. What matters is having clever people around to solve problems.

throwthere 5y ago
Jane Street has the same rationale.
- ntbdhalas 5y ago
  Jane Street has big cult energy though you have to admit, if you've known anyone who worked there
- 7thaccount 5y ago
  I think it was more or less the best tool for the job (according to them) back when their tech lead chose it and now they've built all their tech stack around it. I remember a blog post or interview where he said they wouldn't necessarily use OCaml if starting again right now. I don't think he was referring to going the way of Haskell either.
RapperWhoMadeIt 5y ago
Maybe the same applies to building a RESTful API and choosing Go instead of js :)
- jpgvm 5y ago
  You will get slightly better people but still the wrong people. JS is almost never the right tool for the job, Go is occasionally the right tool for the job, mainly if you need to write something that moves bytes from one fd to another without much in the way of business logic. TBH if you are building something boring you should just use Spring w/Java or Kotlin. This will attract pragmatists that ship code that works in ways that anyone else that works with these tools will instantly understand also. In a way it attracts mediocrity but in the good way where you get nice standard code that can be maintained cheaply for a long time and it's easy to hire for the skillset. If you are prototyping extremely quickly then maybe Ruby on Rails might be the right tool for the job (and thus attract the right kind of people). Go attracts mediocrity and not in a good way, it also actively repels the "right " people if you want to hire for highest intellectual horsepower for a given budget. In the same category as Haskell you also have OCaml, the Lisps (Clojure in particular) and Erlang all of which will yield you lots of the "right" people. None of these people will be cheap but none of the good people that write the other languages are cheap either, however there is a strong correlation between interest and proficiency in these languages and high intellectual horsepower - hence "right" in this context.
  - tharne 5y ago
    This can cut both ways. Yes, if you choose Haskell, a Lisp, or something like Erlang, you can get smarter/better devs. But the flip side of that is that the types of people who tend to gravitate toward those languages are often more interested in programming for it's own sake and not the domain they're working in. So you get things like people burning hours writing their own libraries and endless tinkering with programming minutiae instead of getting sh* done. On the other hand, a mediocre programmer who taught themselves Python, may not be winning any programming competitions, but will often have significant domain expertise and a bias toward getting things done. You need to ask yourself whether or not the stuff you're working on really demands the absolute best programmers (it very rarely does). If it does, go with the Erlang/Haskell/Lisp crew, otherwise go with the Python/JS/Go crew.
    - jpgvm 5y ago
      This is where I differ. I think the Python/JS/Go crew gets you stuff that is built poorly and becomes expensive to maintain. I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, their tools aren't constantly changing so for the most part they only need to spend time actually doing work. No fighting with package managers, no updating the latest framework and solving backwards incompatibilities for weeks, no random runtime bugs and shitty native extensions that cause said runtime bugs or memory leaks outside of runtime level heap accounting, etc. Boring tech is the way to go for 99% of problems and to me JS/Go/Python don't qualify because they break too much and require too many workarounds for too many problems. I want my programmers to be thinking about how to solve my business problem, not problems with their tools.
      - mbesto 5y ago
        > I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, I don't think thats what the parent meant. They meant esoteric functional programming languages vs mainstream OOP ones. You're saying the same thing.
        jpgvm 5y ago
DavidWoof 5y ago
I think that's more true in the negative sense. It's not that it attracts the "right" people, it's that it repels the "wrong" people. There plenty of clever efficient devs working in Java or JS but they're surrounded by a sea of mediocrity. And since the interview process is imprecise the point of being broken, it's very useful to attract the right people in the first place.
mbesto 5y ago
This is generally true. > From a business perspective, any language is arbitrary. Counterpoint: And then when the company starts growing quickly and has to hire 10 Haskell devs in 12 months, they realize its pretty much impossible to do without shelling out $200k/person.
- mirekrusin 5y ago
  ...which is likely saving money long run anyway - good developers usually pay for themselves, if not, they're in the wrong place.
  - hnfong 5y ago
    In this case it doesn't mean the 200k dev is necessarily good. It just means the supply has dried up driving up the prices.
    - mirekrusin 5y ago
      It's hard to believe that 10 devs in 1 year would dry up all haskell market.
- caffeine 5y ago
  When they do that they don’t hire devs already experienced in Haskell, they just hire smart experienced devs who are competent at building systems and can learn to build them in Haskell.
_8j50 5y ago
This is the best answer. I read something similar for Ocaml and finance sector.
quixoticaxolotl 5y ago
Eh. The "right" people can have perverse incentives. My former mentor worked at a startup called Takt that billed itself as Haskell-only. It attracted all the top minds - Runar Bjarnason, who wrote a famous Scala book, worked there - and everyone was very eager to write Haskell code for a living. The engineering team quickly went all-in on functional everything. Nix for package managers, a Haskell-to-JS transpiler for writing frontend code, immutable databases, the works. Because they eschewed all the boring technology that had been proven reliable over the years and only played with the bleeding edge in Haskell, they quickly ran into limitations of the ecosystem: performance degradations as they hit corner cases, missing functionality that needed to be patched upstream, corner cases that no tooling had existed to support it, etc. Before long, they were single-handedly supporting the broader Haskell ecosystem rather than spending cycles delivering on the business contracts they had. This was all very fine with engineering - why not contribute upstream? Why not drive Haskell to broader adoption, which was in line with the company's values? - but management balked. They began to raise the possibility of maybe ditching their bespoke tooling and moving to something more standard. This didn't go down well - it caused a schism, where half the engineering team felt the right way forward was to double-down on the existing nascent Haskell technology and offer more support and training, and the others who just wanted to get stuff done. Anyway, the startup failed. Turns out, when you hire for people who really believe in a programming language, you can occasionally attract zealots.
- mbrodersen 5y ago
  I agree. I like Haskell and I highly recommend learning it. But I would not choose it for production projects. I have learned the hard way to only use old, boring, well-known by the team technology when implementing software to solve real world business problems.
  - yakshaving_jgt 5y ago
    Haskell is quite old and boring though.
- tmm84 5y ago
  I don't think this is a programming language fail as much as it is seeing everything as nail because you chose to use only hammers. In the world of programming and technology I wished more people would look at people who invest and see that diversifying is what you need to do sometimes. Pick the immutable database but have a solid regular one along side of it in case you need to jump ship (more cost but it covers the case that the immutable database doesn't work out). This is the difference between investment and gambling. I would say to some degree they betted on immutable being the thing that would give them success instead of investing in immutable technologies that could be useful.
dboreham 5y ago
In the Hitchhiker's Guide to the Galaxy, this is called "The B Ark". https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...
collyw 5y ago
Actually from a business perspective PHP or something would be the best choice? Lots of (relatively speaking) cheap devs available at all levels. Wasn't Java designed around the idea of medicore developers not being able to mess up too badly? Functional languages do appear to attract smart people, but I see far more people with an interest in the language than actual jobs out there. They seem more geared towards compute science (more theoretical) over software engineering (solving real world problems).

throwthere 5y ago

Jane Street has the same rationale.

ntbdhalas 5y ago
Jane Street has big cult energy though you have to admit, if you've known anyone who worked there
7thaccount 5y ago
I think it was more or less the best tool for the job (according to them) back when their tech lead chose it and now they've built all their tech stack around it. I remember a blog post or interview where he said they wouldn't necessarily use OCaml if starting again right now. I don't think he was referring to going the way of Haskell either.

RapperWhoMadeIt 5y ago

Maybe the same applies to building a RESTful API and choosing Go instead of js :)

jpgvm 5y ago
You will get slightly better people but still the wrong people. JS is almost never the right tool for the job, Go is occasionally the right tool for the job, mainly if you need to write something that moves bytes from one fd to another without much in the way of business logic. TBH if you are building something boring you should just use Spring w/Java or Kotlin. This will attract pragmatists that ship code that works in ways that anyone else that works with these tools will instantly understand also. In a way it attracts mediocrity but in the good way where you get nice standard code that can be maintained cheaply for a long time and it's easy to hire for the skillset. If you are prototyping extremely quickly then maybe Ruby on Rails might be the right tool for the job (and thus attract the right kind of people). Go attracts mediocrity and not in a good way, it also actively repels the "right " people if you want to hire for highest intellectual horsepower for a given budget. In the same category as Haskell you also have OCaml, the Lisps (Clojure in particular) and Erlang all of which will yield you lots of the "right" people. None of these people will be cheap but none of the good people that write the other languages are cheap either, however there is a strong correlation between interest and proficiency in these languages and high intellectual horsepower - hence "right" in this context.
- tharne 5y ago
  This can cut both ways. Yes, if you choose Haskell, a Lisp, or something like Erlang, you can get smarter/better devs. But the flip side of that is that the types of people who tend to gravitate toward those languages are often more interested in programming for it's own sake and not the domain they're working in. So you get things like people burning hours writing their own libraries and endless tinkering with programming minutiae instead of getting sh* done. On the other hand, a mediocre programmer who taught themselves Python, may not be winning any programming competitions, but will often have significant domain expertise and a bias toward getting things done. You need to ask yourself whether or not the stuff you're working on really demands the absolute best programmers (it very rarely does). If it does, go with the Erlang/Haskell/Lisp crew, otherwise go with the Python/JS/Go crew.
  - jpgvm 5y ago
    This is where I differ. I think the Python/JS/Go crew gets you stuff that is built poorly and becomes expensive to maintain. I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, their tools aren't constantly changing so for the most part they only need to spend time actually doing work. No fighting with package managers, no updating the latest framework and solving backwards incompatibilities for weeks, no random runtime bugs and shitty native extensions that cause said runtime bugs or memory leaks outside of runtime level heap accounting, etc. Boring tech is the way to go for 99% of problems and to me JS/Go/Python don't qualify because they break too much and require too many workarounds for too many problems. I want my programmers to be thinking about how to solve my business problem, not problems with their tools.
    - mbesto 5y ago
      > I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, I don't think thats what the parent meant. They meant esoteric functional programming languages vs mainstream OOP ones. You're saying the same thing.
      - jpgvm 5y ago

DavidWoof 5y ago

I think that's more true in the negative sense. It's not that it attracts the "right" people, it's that it repels the "wrong" people. There plenty of clever efficient devs working in Java or JS but they're surrounded by a sea of mediocrity. And since the interview process is imprecise the point of being broken, it's very useful to attract the right people in the first place.

mbesto 5y ago

This is generally true. > From a business perspective, any language is arbitrary. Counterpoint: And then when the company starts growing quickly and has to hire 10 Haskell devs in 12 months, they realize its pretty much impossible to do without shelling out $200k/person.

mirekrusin 5y ago
...which is likely saving money long run anyway - good developers usually pay for themselves, if not, they're in the wrong place.
- hnfong 5y ago
  In this case it doesn't mean the 200k dev is necessarily good. It just means the supply has dried up driving up the prices.
  - mirekrusin 5y ago
    It's hard to believe that 10 devs in 1 year would dry up all haskell market.
caffeine 5y ago
When they do that they don’t hire devs already experienced in Haskell, they just hire smart experienced devs who are competent at building systems and can learn to build them in Haskell.

_8j50 5y ago

This is the best answer. I read something similar for Ocaml and finance sector.

quixoticaxolotl 5y ago

Eh. The "right" people can have perverse incentives. My former mentor worked at a startup called Takt that billed itself as Haskell-only. It attracted all the top minds - Runar Bjarnason, who wrote a famous Scala book, worked there - and everyone was very eager to write Haskell code for a living. The engineering team quickly went all-in on functional everything. Nix for package managers, a Haskell-to-JS transpiler for writing frontend code, immutable databases, the works. Because they eschewed all the boring technology that had been proven reliable over the years and only played with the bleeding edge in Haskell, they quickly ran into limitations of the ecosystem: performance degradations as they hit corner cases, missing functionality that needed to be patched upstream, corner cases that no tooling had existed to support it, etc. Before long, they were single-handedly supporting the broader Haskell ecosystem rather than spending cycles delivering on the business contracts they had. This was all very fine with engineering - why not contribute upstream? Why not drive Haskell to broader adoption, which was in line with the company's values? - but management balked. They began to raise the possibility of maybe ditching their bespoke tooling and moving to something more standard. This didn't go down well - it caused a schism, where half the engineering team felt the right way forward was to double-down on the existing nascent Haskell technology and offer more support and training, and the others who just wanted to get stuff done. Anyway, the startup failed. Turns out, when you hire for people who really believe in a programming language, you can occasionally attract zealots.

mbrodersen 5y ago
I agree. I like Haskell and I highly recommend learning it. But I would not choose it for production projects. I have learned the hard way to only use old, boring, well-known by the team technology when implementing software to solve real world business problems.
- yakshaving_jgt 5y ago
  Haskell is quite old and boring though.
tmm84 5y ago
I don't think this is a programming language fail as much as it is seeing everything as nail because you chose to use only hammers. In the world of programming and technology I wished more people would look at people who invest and see that diversifying is what you need to do sometimes. Pick the immutable database but have a solid regular one along side of it in case you need to jump ship (more cost but it covers the case that the immutable database doesn't work out). This is the difference between investment and gambling. I would say to some degree they betted on immutable being the thing that would give them success instead of investing in immutable technologies that could be useful.

dboreham 5y ago

In the Hitchhiker's Guide to the Galaxy, this is called "The B Ark". https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...

collyw 5y ago

Actually from a business perspective PHP or something would be the best choice? Lots of (relatively speaking) cheap devs available at all levels. Wasn't Java designed around the idea of medicore developers not being able to mess up too badly? Functional languages do appear to attract smart people, but I see far more people with an interest in the language than actual jobs out there. They seem more geared towards compute science (more theoretical) over software engineering (solving real world problems).