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.
It’s a spectrum, it’s multidimensional and it changes over time though.
I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece of elegant code against the pleasure of positive business outcomes. I think that makes me neither a “boring business person” nor a diehard code nerd, but somewhere at the intersection with attributes in other directions not captured by either stereotype.
That said, if you really are 100% motivated by abstract technical challenges, then maybe academia is more for you than industry is. Or working at the small slice of companies that truly make their bread and butter on cutting edge technical excellence and not, say, applying tried and true tools to some underserved niche.
I do find the “algorithm nerd” charisma also tends to intersect with having warped views of how the world operates and weak self-awareness, so maybe easier said than personally realized.
>
That said, if you really are 100% motivated by abstract technical challenges, then maybe academia is more for you than industry is.
Of course. Such people very typically attempt to get a foothold in academia. The central reason why they nevertheless leave academia is because of the precarious job situation.
Hello! I'm just starting my career as a dev now and I am definitely more drawn to academia and research than to the business world. Could you point me to some resources where I can learn more about companies or projects that work researching CS/programming topics?
> 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.
> who love to think about whether there is a deeper hidden mathematical structure behind the business problems.
Yup and lots of whom started with programming as a hobby, and could chase after any shiny thing they saw, or run off whenever on any side quest that interested them.
Nobody wants to pay you hundreds of thousands of dollars to navel gaze, or run off down whatever path you feel is mathematically satisfying. Do that on your own time. You're being paid hundreds of thousands dollars to deliver business value - so do that. Build mathematical towers on your own time.
It's like paying someone by the day to paint your house and they paint the Mona Lisa in white paint on white and take 3x as long because it's more artistically beautiful even if the end result is just an all white painted house.
"Don't you see the deeper hidden artistic structure!?"
I can't plus this enough. I hired a unicorn business minded, brilliant, can solve any software engineering or UI/UX problem engineer who happened to have a predilection for functional programming.
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.
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 don't see why anyone should be a $LANG dev. All programming languages suck (there is this theoretical language that doesn't suck, but it isn't invented yet). Surely $LANG devs recognize that their language sucks, right?
And that's why we switch languages constantly. For some problems, some languages suck a little less.
> You wouldn't have this problem in the first place if the language you chose -did- have an actively maintained JWT library.
Actively maintained does not mean it’s good. We have to read and fork all libs we use (regulatory) so it won’t end up getting hacked etc, at least, less likely and a lot of ‘actively maintained libraries’ especially npms/pips are total garbage. We often spend less time just rolling ourselves than figuring out if this unreadable, overarchitected resume driven garbage even works.
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.
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
Not even sure these guys fit the standard mantle of language hyping charlatans. Most of the catastrophic choices were things you could do in any language. With the bonus of no meaningful comments and just committing to master so there's no PR comment history to help the future team's archeology project.
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, 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 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.
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).
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.
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.
> 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.
> 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.
> As I said, the problem is a classic one; it was formulated during the war, and efforts to solve it so sapped the energies and minds of Allied analysts that the suggestion was made that the problem be dropped over Germany, as the ultimate instrument of intellectual sabotage.
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.
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.
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 it.
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.
Readit News
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.
I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece of elegant code against the pleasure of positive business outcomes. I think that makes me neither a “boring business person” nor a diehard code nerd, but somewhere at the intersection with attributes in other directions not captured by either stereotype.
That said, if you really are 100% motivated by abstract technical challenges, then maybe academia is more for you than industry is. Or working at the small slice of companies that truly make their bread and butter on cutting edge technical excellence and not, say, applying tried and true tools to some underserved niche.
I do find the “algorithm nerd” charisma also tends to intersect with having warped views of how the world operates and weak self-awareness, so maybe easier said than personally realized.
Of course. Such people very typically attempt to get a foothold in academia. The central reason why they nevertheless leave academia is because of the precarious job situation.
Thank you in advance.
> 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.
Deleted Comment
Yup and lots of whom started with programming as a hobby, and could chase after any shiny thing they saw, or run off whenever on any side quest that interested them.
Nobody wants to pay you hundreds of thousands of dollars to navel gaze, or run off down whatever path you feel is mathematically satisfying. Do that on your own time. You're being paid hundreds of thousands dollars to deliver business value - so do that. Build mathematical towers on your own time.
It's like paying someone by the day to paint your house and they paint the Mona Lisa in white paint on white and take 3x as long because it's more artistically beautiful even if the end result is just an all white painted house.
"Don't you see the deeper hidden artistic structure!?"
I found out that unicorns are unicorns.
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.
And that's why we switch languages constantly. For some problems, some languages suck a little less.
Most programming languages are pretty neat. Learning is a joy. That's why language hops are fun and common.
But yes, few things make me cringe more than someone selling themselves short by introducing themselves as a $LANG dev
I only have one life and I prefer not to suffer too much; switching languages is not helping me at all in preventing that suffering.
Actively maintained does not mean it’s good. We have to read and fork all libs we use (regulatory) so it won’t end up getting hacked etc, at least, less likely and a lot of ‘actively maintained libraries’ especially npms/pips are total garbage. We often spend less time just rolling ourselves than figuring out if this unreadable, overarchitected resume driven garbage even works.
It's hard to know from an interview what the quality of your Haskell code is.
It's probably relatively easy to find out in an interview that you had a lot of trouble with Clojure and are currently porting to Java.
Please explain.
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...
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
Deleted Comment
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.
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.
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.
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.
Lack of libraries.
Lack of good tools.
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.
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.
Deleted Comment
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.
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.
Deleted Comment
This is the right attitude
This is incredible
Multi-armed bandits were introduced in the 50s, years after the end of World War 2.
> As I said, the problem is a classic one; it was formulated during the war, and efforts to solve it so sapped the energies and minds of Allied analysts that the suggestion was made that the problem be dropped over Germany, as the ultimate instrument of intellectual sabotage.
[0]: https://academic.oup.com/jrsssb/article-pdf/41/2/164/4909740...
Deleted Comment
[0] https://xkcd.com/356
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.
Be careful with this statement: many programmers value very different properties of the product than the typical customer.
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.