Comment by kccqzy
2 years ago
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 don't care about the business goals and only want to write Rust. A few years ago it was Go. Before that it was Node.js. A few more years ago it was Ruby on Rails.
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…)
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.
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.
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.
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.
This is the very first thing I do when picking up a new tech - language, framework, library, tool. After initial familiarization with the basics - Wikipedia/Readme-Intro, I would google "Why does X sucks", and try to avoid becoming overly enamored with it too quickly, and strive to maintain a level-headed perspective.
Ok. For anyone struggling with the second, the answers should be:
Lack of libraries.
Lack of good tools.
My favourite languages are C# and C++, and sometimes I interview developers to work with them. Saying these languages are lacking libraries or good tools is unreasonable.
10 replies →
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).