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

61–70 of 140 posts

Re: The Functional Programming Hiring Problem

#61

Post by snapdaddy »

PheonixPharts wrote: post #20

Is this written from a different time line were TypeScript doesn't exist? I have a long history of doing FP in a bunch of the traditional FP languages (Scheme/Haskell/etc). Ended up working at a young startup with equally young employees awhile back and was sort of surprised to see that the long heralded fantasy of cranky FP enthusiasts has, for better or worse, come true in Type Script. I saw a generation of new pro…

That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.

Re: The Functional Programming Hiring Problem

#62

Post by Chris_Newton »

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…

This hasn’t been my experience. One attraction of functional programming style is that you tend to separate pure/declarative code from effects, one way or another, and then express each using familiar patterns of computation or interaction that are the essence of what you’re implementing. This often results in simpler and more explicit code, with exactly the kind of high cohesion and low coupling you’re advocating.

It is no coincidence that an expressive functional language like Haskell has concise, descriptive names for numerous common folding patterns over common data structures such as mapAccumWithKey¹ that let you express what you want to achieve in just a line or two of code with minimal boilerplate or ambiguity, where using a generic loop in a mainstream imperative language would take 3x that and need a little thought to recognise the pattern being used and make sure there wasn’t anything else happening that was tangled up in the same code.

¹ https://hackage.haskell.org/package/containers-0.7/docs/Data...

Re: The Functional Programming Hiring Problem

#63

Post by skydhash »

aleph_minus_one wrote: post #53
warcher wrote: post #37

Earlier quoted context omitted.

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

> 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.

Not really, unless you're trying to extract the maximum performance from the compiler, or you're trying to publish your own libraries. You learn Java, C# is pretty close. You know LISP and Java, you can pickup Clojure really quick.

As for the ecosystem, what you need to learn depends on the problem, not on the solution. If you need to do JSON parsing, you take a few days to investigate the available libraries, write your own parser if none exists. That assumes you know what JSON is and what serializing data entails. These are universal problems that exists outside of the Knowing Language X scope.

I'd much prefer hiring someone who can build web applications than someone who knows express.js.

Re: The Functional Programming Hiring Problem

#64

Post by [deleted] »

aleph_minus_one wrote: post #57
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 t…

[deleted]

Re: The Functional Programming Hiring Problem

#65

Post by pkaye »

tmpz22 wrote: post #42
Yoric wrote: post #40

Earlier quoted context omitted.

Are then even worse than Go's?

What is bad about encoding/json?

There is a version 2 being implemented to fix some of the known issues.

https://github.com/golang/go/discussions/63397

https://pkg.go.dev/github.com/go-json-experiment/json

Re: The Functional Programming Hiring Problem

#66

Post by pram »

BWStearns wrote: post #13

I work at a place that has ancestral Gooby code. It is truly horrific and an affront to whatever machine god (GPT-X?) may judge us in the future. The badness has literally nothing to do with the language. All the bad parts are due to the original team having reached for the most esoteric thing available at the time. I like playing with weird tech shit but there is a time and a place, and that place is not in prod for…

I've personally seen this, it can be pure goddamn cancer.

The company hired a very smart charlatan and he convinced them to start a greenfield project in Haskell. Then they need to hire Haskell developers for this specific thing because everyone else only knows Java and Python. Nearly a year later they're barely getting started, but it's getting hyped like you couldn't believe. A lot of sprint planning time starts to become 'how do we start integrating [New thing]' because the Directors have been fluffing it so hard.

Anyway it never got used in prod. The development turned into a disaster and the original guy quit. The team got dismantled and the whole thing got memory-holed. Anyone in the org hearing the word "Haskell" would invariably just think about it lol

Re: The Functional Programming Hiring Problem

#68

Post by jballanc »

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 is why one of my favorite series of questions to pull out during an interview are:

What is your favorite programming language/library/technology?

What do you hate about it?

Anyone that jumps to answer the first but struggles to answer the second is likely not someone you want to hire.

Re: The Functional Programming Hiring Problem

#69

Post by juancn »

Language or any other technology you choose has the same problem.

Getting lost in the "tech $X is better for this than $Y" can easily become a distraction. Engineering is a form of applied science for money.

Since it's economically driven, the two most important things you as an engineer need to know are:

- who is paying for this?

- why?

Those two questions should underpin every single decision you make. If you lose sight of that, theres a huge chance you won't succeed.

Re: The Functional Programming Hiring Problem

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN