If anyone’s having trouble reading the code examples, there’s a switch to use dark mode at the top of the blog. The main syntax highlighting colour is white even if that’s also the background!
I think part of the problem is that the principles listed at the end usually aren’t properties of the languages being offered. Rather, they are ideals which we are asked to approximate as a matter of coding style.
Regarding immutability, we should explain the fundamentally-immutable nature of data first, and then explain how mutability arises as an apparent effect while a machine is executing. Don’t motivate some sort of new “functional” approach to handling data, but unassume the traditional explanations for why imperative and mutable models are preferred.
Regarding purity, you probably will not be able to do this at work. The main obstacle is that few of our ecosystems actually enforce pure behaviors! You may find content-addressing systems to be pure. But the actual computation of facts about data, or especially the synthesis of new data from seed data and generative programs, is all-too-often built with some sort of escape hatch. Of everything you’ve listed, maybe Elm comes close, but Elm pays for it by losing access to generic typeclasses.
I’ve worked with codebases that were mostly RamdaJS, and they suffered from the pointfree problem deeply. In some cases it made for great looking code, in others it’d be a complete mess - particularly when you add in the other Ramda functions. I think there’s a very good case to be made for “if your team is fully onboard, you can go for it” - but the problem is any time someone else joins the team, they must all be fully onboard with it. Add in the factor that a fully Ramdaized codebase is somewhat unusual, and you end up with disappointment.
Functional programming should be clean, beautiful, type safe - but most of all, like most paradigms, it should be pragmatic. In most companies, code beauty is not the deliverable. What the code makes is. Good, production-ready FP code enables the team to make the best product they can – without fighting complicated type systems or confusingly named helper functions.
Functional programming should be clean, beautiful, type safe - but most of all, like most paradigms, it should be pragmatic. In most companies, code beauty is not the deliverable. What the code makes is. Good, production-ready FP code enables the team to make the best product they can – without fighting complicated type systems or confusingly named helper functions.
I have found that code beauty tends to align fairly well with production readiness, except in cases where somebody is trying to optimize haskell. This includes typescript where one is doing rxjs stuff.
I think there’s definitely a lot of cases where good, clean FP is good production code. For example - if you have a good clean API, that makes it easier to consume than a messy API. Or if you have multiple small functions, it’s easier to explain to the reader what’s meant to be happening, as well as making the code easier to unit test. The problem, like you say with optimising Haskell, is when someone begins to get too deep into the abstractual concept of purity of the code rather than the usefulness.
I’ve lived in these code bases before. I even started one before I realized it’d be better to get a language with static types. Seriously though: if you are on board with FP, don’t half-measure your front-end–the front-end is what the clients see and react to. If your team can see the value of Haskell on the back-end, the front-end doesn’t need something shoehorned with horrible ergonomics like fp-ts atop the unsound type system of TypeScript to a language where the idioms are normalized and pattern matching is, like, first class.
This is a backwards style article/PDF where anti-patterns are presented. From the article:
If you’re looking to lose functional programming at work, here are a bunch of mistakes I’ve made on JS-heavy web teams over the years that can help you do the same.
This is a sarcastic introductory message and sets the tone for the article/PDF.
If anyone’s having trouble reading the code examples, there’s a switch to use dark mode at the top of the blog. The main syntax highlighting colour is white even if that’s also the background!
I broke that last night. I’ll fix it, and thanks for the report <3
edit: All fixed up, and I’m so sorry for the trouble. A hard refresh should do the trick.
Thanks! I was wondering if I was just the only one using light mode 😅
I think part of the problem is that the principles listed at the end usually aren’t properties of the languages being offered. Rather, they are ideals which we are asked to approximate as a matter of coding style.
Regarding immutability, we should explain the fundamentally-immutable nature of data first, and then explain how mutability arises as an apparent effect while a machine is executing. Don’t motivate some sort of new “functional” approach to handling data, but unassume the traditional explanations for why imperative and mutable models are preferred.
Regarding purity, you probably will not be able to do this at work. The main obstacle is that few of our ecosystems actually enforce pure behaviors! You may find content-addressing systems to be pure. But the actual computation of facts about data, or especially the synthesis of new data from seed data and generative programs, is all-too-often built with some sort of escape hatch. Of everything you’ve listed, maybe Elm comes close, but Elm pays for it by losing access to generic typeclasses.
I’ve worked with codebases that were mostly RamdaJS, and they suffered from the pointfree problem deeply. In some cases it made for great looking code, in others it’d be a complete mess - particularly when you add in the other Ramda functions. I think there’s a very good case to be made for “if your team is fully onboard, you can go for it” - but the problem is any time someone else joins the team, they must all be fully onboard with it. Add in the factor that a fully Ramdaized codebase is somewhat unusual, and you end up with disappointment.
Functional programming should be clean, beautiful, type safe - but most of all, like most paradigms, it should be pragmatic. In most companies, code beauty is not the deliverable. What the code makes is. Good, production-ready FP code enables the team to make the best product they can – without fighting complicated type systems or confusingly named helper functions.
This is a great comment on some expectations and realities, especially with ramda! Thanks for taking the time to write it out.
I have found that code beauty tends to align fairly well with production readiness, except in cases where somebody is trying to optimize haskell. This includes typescript where one is doing rxjs stuff.
I think there’s definitely a lot of cases where good, clean FP is good production code. For example - if you have a good clean API, that makes it easier to consume than a messy API. Or if you have multiple small functions, it’s easier to explain to the reader what’s meant to be happening, as well as making the code easier to unit test. The problem, like you say with optimising Haskell, is when someone begins to get too deep into the abstractual concept of purity of the code rather than the usefulness.
I’ve lived in these code bases before. I even started one before I realized it’d be better to get a language with static types. Seriously though: if you are on board with FP, don’t half-measure your front-end–the front-end is what the clients see and react to. If your team can see the value of Haskell on the back-end, the front-end doesn’t need something shoehorned with horrible ergonomics like
fp-tsatop the unsound type system of TypeScript to a language where the idioms are normalized and pattern matching is, like, first class.I am having a rather tough time figuring out what this is about. The word “lose” is very rarely used in this context.
This is a backwards style article/PDF where anti-patterns are presented. From the article:
This is a sarcastic introductory message and sets the tone for the article/PDF.