Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Functional Programming Hiring Problem

blog.janissary.xyz

Post reply on HN
Print view View original

21–30 of 140 posts

Re: The Functional Programming Hiring Problem

#21

Post by yarekt »

wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well

Re: The Functional Programming Hiring Problem

#22

Post by downrightmike »

jll29 wrote: post #16

In 2005, I needed to hire a Haskell dev with deep NLP expertise to replace a member of my startup team. After a posting on the Haskell mailing list, zero responses came back. We realized the world had about 3 people that matched all the requirements: one was the dev that needed to be replaced, the other one was a tenured professor of a U.S. university (Hi, Hal!), and there was one more, whom I don't remember but it m…

When you have one expert in something, you'll need to back them up or replace them in the future. You're job is to find three or four people that are decent at thing, and then put them all on expert tasks, as a team, so they grow into experts. This also frees up your expert to do that level or higher work.

Re: The Functional Programming Hiring Problem

#23

Post by jsyang00 »

The author brings up some good points here, but I would just make sure to build my business around trading obscure financial instruments in a clever way, so as to generate such an overwhelming amount of profit that we can singlehandedly rewrite and maintain everything in our stack from scratch.

I acknowledge, however, a lot of people never think to do this when starting their business, and consequently run into all sorts of this kind of trouble, sadly.

Re: The Functional Programming Hiring Problem

#24

Post by jt2190 »

kccqzy wrote: post #4

This is just a hiring problem, not related to functional programming. I agree with the basic premise of the article however: depending on the financial condition of the company, hiring people who are overly attached to or obsessed with a single technology probably isn't a good idea. But that's of course not exclusive to functional programming. Right now you will find plenty of people obsessed with Rust (not a functio…

While there’s some truth to “there are programmers obsessed with every language”, functional programming encourages a higher level of correctness, and this can lead to over-analysis and premature optimization if one is not careful. Yes, the additional correctness can be a real benefit, but only if the correctness is correct, and that really depends on the business. If the business comes back every week with “you know, actually we want…” you didn’t get a lot of benefits from the extra analysis.

Couple that with other challenges of running a niche stack in production and it can be quite a burden. Experienced, pragmatic developers will have techniques for managing this even in a functional language, but again, pragmatic may require compromise that doesn’t sit well with the purist.

Re: The Functional Programming Hiring Problem

#25

Post by jongjong »

The way I see it, functional programming converts are often people who failed to properly grasp other, more challenging methodologies and decided that they need training wheels on their bikes. Though they won't frame it that way of course; they'll say that other methodologies lack the 'proper guardrails' which is telling...

I'm yet to meet an FP fanatic who actually properly understood OOP. Few seem to even understand the core principles of 'high cohesion, loose coupling' and fewer are even able translate that into a programming methodology.

My view of FP proponents is the opposite as the author claims. They're not rockstars who can master anything. More like the opposite; they're often people who are incapable of taking something complex and simplifying it. They're people who can't keep complexity under control and they need an external tool to do it for them.

Re: The Functional Programming Hiring Problem

#26

Post by drewcoo »

wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

That approach also keeps you from hiring disgruntled devs.

It's hard to know from an interview what the quality of your Haskell code is.

It's probably relatively easy to find out in an interview that you had a lot of trouble with Clojure and are currently porting to Java.

Re: The Functional Programming Hiring Problem

#27

Post by rqtwteye »

yarekt wrote: post #21
wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well

I think Newtonsoft is quite ok, but the MS library lacks a lot.

Re: The Functional Programming Hiring Problem

#28

Post by aranchelk »

wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

Definitely the same story for PureScript. I rarely reach for Haskell now because I know I can leverage virtually any library off of NPM.

Re: The Functional Programming Hiring Problem

#30

Post by aranchelk »

drewcoo wrote: post #26
wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

That approach also keeps you from hiring disgruntled devs. It's hard to know from an interview what the quality of your Haskell code is. It's probably relatively easy to find out in an interview that you had a lot of trouble with Clojure and are currently porting to Java.

> It's hard to know from an interview what the quality of your Haskell code is.

Please explain.

Post reply on HN