This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
If you choose an FP language like Haskell, you tend to value things beyond that. Stability, engineering culture, retention, big rate, the ability to extend things for cheap only because you did the hard part of using Haskell to begin with, etc
It's just throughput vs latency
I don't think it is.
At work, I'm adding some basic metrics/logging functionality to an internal library, to see how it's being used. The idea is to log a few parameters and the tech lead suggested using JSON format.
No problem right? Well my work environment is quirky and let's just say it is hard to use outside libraries for various reasons. It can happen there is just a lengthy IT process to go through... eventually most reasonable requests will be filled (copied/mirrored internally, or binaries imported). But there is a delay.
This is all besides the point other than to say: I either need to wait a few weeks, or write my own minimal JSON library.
How hard can that be? I mean, it's just JSON. Well earlier today I was checking reddit and saw an announcement that "JSON for Modern C++ was released" (https://www.reddit.com/r/cpp/comments/p69plb/json_for_modern...). Hey cool, I can see what the library looks like and maybe rip off some of their code while I'm waiting for a "please mirror this internally" request to finish.
This library is thousands of lines long... for JSON. I'm not disparaging the author or JSON, it looks like an awesome library with great diagnostics, I'm more trying to point out that even for the SIMPLE format of JSON, a serious library is 10K+ lines. That's a hell of a lot of extra work to put on a team when writing a JSON (or whatever) library probably isn't the actual work that needs to be done.
Elm likely has a JSON library ready to use, but having your seasoned team reinventing the wheel for so many other libraries isn't a good use of dev time. I can't think of simpler libraries to write than JSON and even that is 10K lines long. Other than the insanity of nodejs and leftpad and libraries like that. If the attitude for every single library needed is "we can write that from scratch" the team is never going to get anywhere.
You can define a JSON AST type very simply, and then converting that to wire bytes is also quite trivial. Also simple to test via golden testing (you could even use property testing + shell out to jq to validate the json)
https://github.com/nikita-volkov/jsonifier This one is nowhere near 10k lines - and it is heavily optimized and polished!
> My opinion is the long-term technical & cultural benefits and opportunities pay off.
How, though? These two points contradict each other. Is using FP going to pay off with technical benefits? Or is it just going to reduce your software development efficiency?
I enjoy writing FP code and using niche frameworks like Elm for hobby projects, but I specifically avoid them for production work because I'm familiar with them.
I always hear claims that using Elm and niche languages is going to pay off in vague benefits somewhere down the road, but in practice the payoff never really arrives. I think a lot of developers pushing these niche frameworks tend to mentally dismiss the actual costs and overhead incurred by using something like Elm.
It's tempting to categorize the struggles as "learning" and therefore try to pretend it doesn't count as lost time, but at the end of the day if your team has to spend extra cycles doing extra things just to accomplish basic tasks, it's a drag on productivity.
But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work.
FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include writing libraries.)
If you have frequent deadlines (or treat 2 week sprints as deadlines), then FP won't jive..and you probably have bigger pain points in your company than PL choice lol.
This is the core point I was disagreeing with:
In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on.
And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. I'd rather invest our time and energy in mainstream languages that have staying power, where we're not obligated to carry large parts of the open-source ecosystem by ourselves.
But that was Haskell I guess. It's obviously not a "niche language trend" by now, so it was pretty clear it had staying power.
Definitely has paid off for me personally. My side projects move a lot faster and more stably now that I cut my teeth in production Haskell. A real free 10xer to my skills personally. And I gained the skills by getting my employer to finance my learning lmao.
This probably depends on the complexity of what you need to do, as well as how well you want to do it.
I've seen people writing their own packages and pieces of systems in months, to typically pretty underwhelming results. However when writing code with tests, proper documentation, getting started guides etc., then what you're saying does sound way more plausible, especially if scope creep of any sorts is also present.
Would you care to comment on what sorts of systems take years to properly develop, though? Because in my experience that could be applicable to very few software projects out there.
This is not a "discussion" question, but a "fill my blind spot" question.
I always read how good FP is, and how much better it handles all the complexity. Yet I never see it win from software written with state.
Is there any big and/or complex sofware written in FP that I am overlooking?
If you want real production software, Starbucks Rewards is/was powered entirely by pure Haskell code and made big bucks
Software having complex state actually makes Haskell even better than the competition. Because most state has nuanced rules about its state transitions.
Haskell definitely has more of a learning curve when it comes to dealing with state, but that curve will guide you towards a ceiling mainstream languages can't even approximate.
In business domains with strict audit requirements, it’s a peace of mind thing, to know that “side effects” (aka persistence and the mutation of persisted data) are constrained to a tiny and highly testable corner of your code base.
For OSS, the examples that spring to mind for me are RabbitMQ (Erlang) and Pandoc (Haskell).
What proof of this is there though? People have made the same claims about lots of things: FP, OOP, statically typed languages, dynamically typed languages, LISP variants, etc. The fact is, any of these solutions can work, and you can also write terrible code with any of them.
Maybe in the context of the parent comment this holds true, but in my experience this is like walking on a knife's edge.
There's the very distinct possibility that you'll end up with homebrew frameworks and libraries that are overcomplicated, buggy, not commented and exceedingly hard to work with. I've seen that happen many times and it makes me consider not just whether people want to do that, not whether people have the time to do that, but even whether it's possible for them to do.
In one project people wanted all of their front end components to be custom and as a consequence spent 3x-5x longer building everything, none of their components were Googleable for someone who's been onboarded and thus people forgot how they even work after 2 weeks of not editing them and had to rediscover that later. I tried adding a component sandbox/playbook to help them provide examples, but no one was interested in doing that when they were already behind the expectations of the business. Picking an off-the-shelf framework would have saved them all of these troubles. Maybe there were actual reasons behind the choice of approaching the project this way, apart from padding their resumes, however after inquiring about those, i didn't get a convincing response.
In another case, i had to work on a custom web back end framework, which had been developed by another company, in a country the language of which i don't speak. Curiously enough, all of their code comments were in this language, there yet again was a lack of any sorts of documentation, the implementation was obtuse, slow and any simple changes to the forms took days to implement properly, even when it would take around 30 minutes in established technologies. Furthermore, the actual framework hadn't received any updates in years and therefore i fear to think what sorts of security issues it had. An off-the-shelf framework would have at least been updated and probably would have more decent documentation.
In short:
- never underestimate the ability of people who lack oversight to make things worse
- frameworks and libraries that are used by thousands of people are probably at least decent
- there's definitely also something to be said about how well tested they are and how known the bugs are
- because of the above, popular technologies seem like a pretty safe bet, as does off-the-shelf code appear to be
- of course, despite all of the above, it's perfectly okay to explore new tech stacks and write your own code, just don't half ass it
The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies.
In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages.
But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point.
My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)