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

31–40 of 140 posts

Re: The Functional Programming Hiring Problem

#31

Post by joe_the_user »

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 for profits - they work hard and point maybe good direction and maybe bad directions. But they make the company harder to sell and that objectively reduces the stock price and so it's bad from the "economic standpoint" even if it makes profits somewhat higher.

Re: The Functional Programming Hiring Problem

#32

Post by readthenotes1 »

One of brooks's papers (the guy that brooks's law is named after) is about how software developers would rather write the tools to solve the problem and then solve the problem itself.

A fair amount of this article is observing this problem persists 60 years later.

Re: The Functional Programming Hiring Problem

#34

Post by agentultra »

Sometimes just using the language the majority of folks enjoy working in is fine.

You get programming astronauts in every language. There’s nothing special about Gooby or functional programmers that makes them deficient in the ways described. You could easily replace Gooby with Rust, Lisp, Python, C++, C#, Java, JS.

What makes the functional programming astronauts stand out is pure optics. If you’re tolerant of C++ templates or Python’s metaclasses you might view discussions on Profunctors to sound like gibberish. If you’re not someone who even uses those tools at all and avoid them out of principal it can sound like a plot for a hostile takeover. To an experienced Haskell programmer it’s likely to be fairly banal.

Which kind of blows this whole theory that Gooby programmers are the problem.

The real problem are those who seek to use a hammer regardless of what problem they’re trying to solve. I’m certain anyone whose been around for a while had encountered the “patterns astronaut,” who will view every problem as an opportunity to figure out how to apply as many GoF patterns as possible. These are the misguided souls we need to bring back into the fold.

Re: The Functional Programming Hiring Problem

#35

Post by CrimsonCape »

dboreham wrote: post #5
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…

For the casual reader: Rust is one of the most functional of the not-totally-functional languages.

For the casual reader, if you think Rust is a casual way to play with functional programming, you will encounter the lifetimes booby trap.

It's almost always better to 'play' in a language that abstracts everything away except for the problem domain. Not like Rust, which introduces multiple complex language domains to learn before you can play wih your target domain.

Re: The Functional Programming Hiring Problem

#36

Post by [deleted] »

bri3d wrote: post #10
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…

This - I’ve had this same experience in both the FP, middle ground (Kotlin, Scala, etc.) and Rust space. It’s not FP, it’s that some engineers are interested in business goals and others are interested in conceptual goals. Those who are interested in conceptual goals gravitate towards conceptually interesting paradigms. Those who are interested in business goals gravitate towards business goals. It’s not mutually exc…

[deleted]

Re: The Functional Programming Hiring Problem

#37

Post by warcher »

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 caught in HR filters a lot without a bunch of projects in gooby though.

Re: The Functional Programming Hiring Problem

#38

Post by nathanaldensr »

rqtwteye wrote: post #27
yarekt wrote: post #21

Earlier quoted context omitted.

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.

Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.

Re: The Functional Programming Hiring Problem

#39

Post by [deleted] »

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.

[deleted]

Re: The Functional Programming Hiring Problem

#40

Post by Yoric »

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

Are then even worse than Go's?
Post reply on HN