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

51–60 of 140 posts

Re: The Functional Programming Hiring Problem

#51

Post by Chris_Newton »

sesm wrote: post #19

Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers. But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.

Indeed. Category 3 seems to be about developers who insist on using Gooby regardless of whether or not it’s a reasonable choice for solving the current problem. What about developers who simply have Gooby as one tool in their toolbox, know how to use it, and enjoy doing so when an appropriate opportunity arises?

I once wrote some Haskell professionally. It was a successor to a previous generation of the application that I had written in Python and maintained for several years. Using Haskell was my choice and it was made because some of Haskell’s strengths would address specific pain points learned from that experience. Meanwhile, everything else I wrote for that client was still being done in mainstream languages for mainstream reasons and there was never any suggestion that we would rewrite anything else in Haskell or adopt it by default for any new work, so I think this situation is clearly distinct from category 3 in the article.

Re: The Functional Programming Hiring Problem

#52

Post by lll-o-lll »

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world.

What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems.

The benefit is they will generally be capable of greater innovation than the former group, but the downside is that they may just focus on interesting puzzles and ignore the needs of the (boring) business. Choosing an exotic language will greatly tilt the ratios towards this later group.

Most people in this later group can discipline themselves to focus on delivery, while remaining a great resource when truely challenging puzzles pop up. Most, but not all. Choosing a very esoteric language is pushing the curve far towards this tail, and the result will be many “brilliant, but useless to our business, people”.

Every small business needs a strong technical leader. I’m convinced of this. You need someone in charge that can stop the arguments, make people put down their toys, and remove people that cannot contribute for whatever reason. So this is my conclusion, it’s boring like so much of business. You need the right manager.

Re: The Functional Programming Hiring Problem

#53

Post by aleph_minus_one »

warcher wrote: post #37
sesm wrote: post #19

Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers. But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.

At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently. Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done. I do get cau…

> At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less.

When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.

Re: The Functional Programming Hiring Problem

#54

Post by aleph_minus_one »

singpolyma3 wrote: post #48
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…

I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.

> we always hire from our product community because tech is easier to teach than product.

Whether this is true depends a lot on the product and the tech that is used.

Re: The Functional Programming Hiring Problem

#55

Post by danielscrubs »

jongjong wrote: post #25

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 understan…

Do you have a great example of a code base that meets your ideals?

I think one of the problems is that we just don’t have people that we admire in programming compared to other areas like biology or literature.

Re: The Functional Programming Hiring Problem

#56

Post by bitwize »

jongjong wrote: post #25

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 understan…

> I'm yet to meet an FP fanatic who actually properly understood OOP.

You just haven't met one who has realized that monads in FP map roughly to objects in OOP yet. :) Both are used for the same broad things: encapsulating/hiding/controlling state and allowing state transformations to be sequenced.

I actually have great sympathy for the functional programmer: having decided that managing both kinds of complexity is mentally exhausting, the functional programmer opts to eliminate, as much as possible, the accidental complexity of willy-nilly side effects in order to better address the inherent complexity of the problem domain. A good programmer can write mostly referentially transparent code with controlled side effects in any language, but it takes more care and forethought to do so in, say, Java.

This is why I say Lisp is really for bad programmers. If you're a programming genius, you can apply the same principles used in Lisp all the time to Java or even C++ code... it's just more work. Work you may not even notice because that stuff comes natural to you. But if you're a mid programmer, much of the friction of working in Java or C++ goes away in Lisp and you feel relieved of a burden. Much more feels within your reach. (I happen to love Lisp, and prefer working in it to anything else if I can, so maybe I'm a bad programmer.)

Re: The Functional Programming Hiring Problem

#57

Post by aleph_minus_one »

lll-o-lll wrote: post #52

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both ben…

> What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems.

> The benefit is they will generally be capable of greater innovation than the former group, but the downside is that they may just focus on interesting puzzles and ignore the needs of the (boring) business.

I think the problem rather is that many "business people" have a deep hate against people who love to think about whether there is a deeper hidden mathematical structure behind the business problems. Just to be clear: there also exist some few business people who appreciate this, but the latter are typically "nerds" who mostly switched to business because it pays much better.

It's not my experience that the latter group of programmers ignores the business problems, they just rather have their own much less anti-intellectual way of approaching them.

Re: The Functional Programming Hiring Problem

#58

Post by aleph_minus_one »

MajimasEyepatch wrote: post #43
joe_the_user wrote: post #31

The classic story is how pg created a storefront in lisp that he sold to yahoo. Yahoo couldn't hire lisp programmers and rewrote it in another language (c++?) and it wasn't as good. But the decision still made sense from a business perspective. And this article sadly shows why. Objectively, they aren't fair to "Goody engineers". Often, they mean opinionated engineers . Now opinionated engineers can be good and bad fo…

The problem is not with opinionated engineers. (Almost every engineer I know is opinionated; the ones who are not tend not to be very good.) The problem is with engineers who are excessively opinionated about the wrong things. Having opinions about the product is way more valuable than being obsessed with writing the umpteenth JSON parsing library in Gooby because the others aren’t built exactly the way you’d build i…

> Having opinions about the product is way more valuable

Be careful with this statement: many programmers value very different properties of the product than the typical customer.

Re: The Functional Programming Hiring Problem

#59

Post by snapdaddy »

jt2190 wrote: post #24
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…

I acknowledge that there are passionate users of most programming languages, but I also 100% agree that the FP crowd are something different. I feel like most other languages have some nuance at least; if you're writing transpilers or kernel modules then hell yes, Rust makes sense. If, however, you are trying to churn out a web-based store-front, maybe don't look towards Rust.

But with FP, it seems like it is always the answer. And it's even better if your Operating System can be immutable too. And your build scripts. And, even if it take 10 times as long to write, at least we will be confident that it's type safe at the end.

Re: The Functional Programming Hiring Problem

#60

Post by skydhash »

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…

> and my conjecture is there might be something about keywords that makes them superior cognitively for humans compared to just piles of nested parentheses.

It's the nature of the language and the VM that it runs in. The code is data and data is code. You can construct a list and then decide to evaluate it. Or the current code you're writing is actually data for another piece of code. It's a paradigm that really opens the computation mindset.

The VM looks like the common REPL you see in Python, but it's more powerful. It's more like a OS installation than a language interpreter. You can inspect anything, patch anything. When paired with an editor, that means you can only apply part of the code and then rerun part of the code. You can also try stuff and then formalize stuff down in code, no need to rerun the whole program.

For me, the parenthesis are the same as Python's whitespaces and colons. Or C-like language and their brackets and semicolons. Just syntax. After a while, you just don't notice them other than check that the expression is correct.

Post reply on HN