4 ms·

A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freak

A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. 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 :)

vlunkr 5y ago
> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here 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.
- mst 5y ago
  I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
- whateveracct 5y ago
  Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
  - adamwk 5y ago
    What's this higher reason? Isn't the point to crank out business code?
    - whateveracct 5y ago
      "Crank out" was supposed to imply optimizing the short-term. Ensuring your next sprint has the most output as possible. 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
kingaillas 5y ago
>The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here 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_c_3100/ 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.
- panzagl 5y ago
  The answer is ditch JSON for something already supported (XML? CSV?) or homebrew a more minimal serialization format that you can implement in a couple of days.
- whateveracct 5y ago
  A json serialization (no parsing) library is not going to be 10k+ lines, and it's going to be extremely simple. 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 https://github.com/nikita-volkov/jsonifier This one is nowhere near 10k lines - and it is heavily optimized and polished!
PragmaticPulp 5y ago
> 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. 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.
- whateveracct 5y ago
  Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. 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.
  - PragmaticPulp 5y ago
    > When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. 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.
KronisLV 5y ago
> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. 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
adamwk 5y ago
I don't think it's merely small librarys. Last I checked localization in Elm was a pain, and I'm sure there are numerous other features missing.
- whateveracct 5y ago
  Elm's library ecosystem is a bit iffy in my experience compared to Haskell or Scala. Those two don't really have huge gaps nowadays, and they're buoyed by better FFI (Haskell w/C, Scala w/Java) than Elm's draconian JS interop.
- razze 5y ago
  Check https://package.elm-lang.org/packages/ChristophP/elm-i18next/latest/ https://package.elm-lang.org/packages/ChristophP/elm-i18next...
  - 1-more 5y ago
    This is rad. TYSM

vlunkr 5y ago

> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here 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.

mst 5y ago
I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
whateveracct 5y ago
Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
- adamwk 5y ago
  What's this higher reason? Isn't the point to crank out business code?
  - whateveracct 5y ago
    "Crank out" was supposed to imply optimizing the short-term. Ensuring your next sprint has the most output as possible. 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

kingaillas 5y ago

>The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here 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_c_3100/ 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.

panzagl 5y ago
The answer is ditch JSON for something already supported (XML? CSV?) or homebrew a more minimal serialization format that you can implement in a couple of days.
whateveracct 5y ago
A json serialization (no parsing) library is not going to be 10k+ lines, and it's going to be extremely simple. 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 https://github.com/nikita-volkov/jsonifier This one is nowhere near 10k lines - and it is heavily optimized and polished!

PragmaticPulp 5y ago

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

whateveracct 5y ago
Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. 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.
- PragmaticPulp 5y ago
  > When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. 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.

KronisLV 5y ago

> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. 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

adamwk 5y ago

I don't think it's merely small librarys. Last I checked localization in Elm was a pain, and I'm sure there are numerous other features missing.

whateveracct 5y ago
Elm's library ecosystem is a bit iffy in my experience compared to Haskell or Scala. Those two don't really have huge gaps nowadays, and they're buoyed by better FFI (Haskell w/C, Scala w/Java) than Elm's draconian JS interop.
razze 5y ago
Check https://package.elm-lang.org/packages/ChristophP/elm-i18next/latest/ https://package.elm-lang.org/packages/ChristophP/elm-i18next...
- 1-more 5y ago
  This is rad. TYSM