[HN Gopher] The Functional Programming Hiring Problem
       ___________________________________________________________________
        
       The Functional Programming Hiring Problem
        
       Author : _peeley
       Score  : 31 points
       Date   : 2024-06-09 22:11 UTC (48 minutes ago)
        
 (HTM) web link (blog.janissary.xyz)
 (TXT) w3m dump (blog.janissary.xyz)
        
       | coolThingsFirst wrote:
       | Tldr: we want experts in our programming language but they charge
       | a lot so it's not good for our budget.
        
       | tjbai wrote:
       | > The multi-armed bandit is a really interesting problem in
       | mathematical optimization... This problem is so interesting, in
       | fact, that during World War II the Allies proposed air dropping
       | copies of the original paper over Germany. The end result, or so
       | it was theorized, was that German scientists would be so
       | fascinated and distracted by the problem that they would abandon
       | the war effort and cripple any German military research projects
       | in the process.
       | 
       | This is incredible
        
         | chrisco255 wrote:
         | Sounds like an impractical (and ineffective) idea that was
         | never implemented, so not actually all that incredible. Rather
         | boring, inconsequential anecdote that adds nothing to the
         | discussion.
        
         | lijok wrote:
         | I heard something similar about the collatz conjecture that it
         | was pushed/popularized by soviets to distract western
         | development
        
         | bavell wrote:
         | Wait, they actually tried nerd sniping[0]?!?
         | 
         | [0] https://xkcd.com/356
        
         | RheingoldRiver wrote:
         | Yeah, by far the highlight of the article for me. In the very
         | abstract, the idea to stop destruction by inspiring creativity
         | is kinda beautiful
        
       | kccqzy wrote:
       | 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 functional
       | language) who doesn't care about the business goals and only
       | wants to write Rust. A few years ago it was Go. A few years ago
       | it was Node.js. A few more years ago it was Ruby on Rails.
        
         | dboreham wrote:
         | For the casual reader: Rust is one of the most functional of
         | the not-totally-functional languages.
        
         | lmm wrote:
         | Not sure if this was a deliberate bait to demonstrate the
         | problem, but Rust is a functional language in the modern sense
         | (it has most of ML's features).
        
         | bri3d wrote:
         | 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 exclusive; I've met
         | Scala and Rust obsessed engineers who also deliver; and Java
         | engineers who can't see past the next AbstractProxyFactory. But
         | if I were forced to stereotype, new paradigms come with people
         | who are more interested in the concepts than the goal (yes, I
         | know FP isn't new, blah blah, professionally speaking...)
        
       | wavemode wrote:
       | 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 about homotopy type theory or continuations or whatever.
       | Meanwhile, you're a week behind on that Jira ticket for issuing
       | JSON Web Tokens because there's no actively maintained JWT
       | libraries for Gooby.
       | 
       | You wouldn't have this problem in the first place if the language
       | you chose -did- have an actively maintained JWT library.
       | 
       | Like, a company that chooses Haskell is a lot more likely to run
       | into this problem than a company that chooses Clojure, due to the
       | simple fact that Clojure can use Java libraries, whereas Haskell
       | exists within its own isolated ecosystem. So, between the two,
       | the likelihood is generally lower that you will, in the first
       | place, run into a problem that Clojure can't easily solve.
       | 
       | So, in my mind, this essentially boils down to the same sort of
       | risk/reward assessment you always need to make when choosing any
       | language for any project.
        
       | mjmsmith wrote:
       | If you've already decided to use Gooby, a senior engineer who has
       | already made significant contributions to successful Gooby
       | projects seems like an ideal hire. If you haven't decided to use
       | it, it's a waste of their talents, which they're letting you know
       | before you hire them.
        
       | BWStearns wrote:
       | 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 a startup.
       | 
       | They way overspent their strangeness budget[0] at every step of
       | the stack. Even though I love (this) Gooby in general, in this
       | case it has caused extreme damage to the organization.
       | 
       | I am still angry at the original devs for their choices because
       | they basically poisoned the whole org against the language even
       | though it would be useful for the org as a whole to adopt it in a
       | non psychotic manner. It basically resulted in a reflexive ban
       | for all Gooby in the future even when it might make sense.
       | 
       | [0] https://steveklabnik.com/writing/the-language-strangeness-
       | bu...
        
       | ggm wrote:
       | Hire from group #2
        
       | jll29 wrote:
       | 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 may
       | just as well have been Simon Peyton-Jones himself (only slightly
       | exaggerating here).
       | 
       | Note the Haskel NLP mailing list -
       | https://archives.haskell.org/projects-pipermail/nlp/ - did not
       | exist then, it was formed in 2009.
       | 
       | In the end, I forced a re-write in Java of our initial "rapidly
       | prototyped" codebase at the time, and I often wonder what I would
       | do nowadays, nearly 20 years later (Python is slow, has the
       | commercial disadvantage of letting customers read off your secret
       | sauce if code runs on their machines, but has a good dev pool to
       | hire from, and definitely is both high-level enough as well as
       | suitable regarding library support; ironicall,y Java is still a
       | contender, despite the boilerplate Kotlin isn't getting the
       | traction that Rust is getting against C, C++ has changed
       | dramatically every 5 years in the 20 years since, and still ads
       | complexity, which is all very scary, and Julia has a small talent
       | pool, and isn't ready for prime time yet, certainly not regarding
       | NLP libraries).
       | 
       | I know, since this is HN, people will say "LISP!", but I'm not
       | sure; I always loved the aestetics of Scheme, but not the
       | ergonomics - and my conjecture is there might be something about
       | keywords that makes them superior cognitively for humans compared
       | to just piles of nested parentheses.
        
       | DrDroop wrote:
       | I used to be more into functional programming but then I found
       | other excuses to learn mathematics. I still think about how my
       | imperative implementation can be turned into a functional one, or
       | the other way around, but honestly the computer graphics
       | programmers and machine learning engineers are doing cooler
       | stuff. Even learning about category theory without needing to
       | have an excuse to implement it makes it a lot more enjoyable.
        
       ___________________________________________________________________
       (page generated 2024-06-09 23:00 UTC)