Where are you meeting all these people? LOL I've never met people like that. But I sense some creative histrionics.
Have I ever taken any creative license?? Sure. But also keep in mind two things: 1) I've been doing this now for almost a quarter century and I tend to be a bit restless in my jobs - so I'm not typically in one place more than a year or two. This means that I've met a lot of people. 2) When I talk, in general, about some of these people, I haven't met many of them in person. But that doesn't mean they don't exist. Some nights I spend hours watching/listening to programming presentations on YouTube. Or reading programming blogs. Or sifting through the new-feature debates in various open source communities. So while I haven't met all of these people in person, I'm very confident that there's a lot of dogma out there.
As for your general approach to FP, I think we're almost perfectly aligned. I'm genuinely a fan of FP concepts. And I keep striving to be a little more FP in my coding. But I don't get hung up on the theory.
Write small standalone (atomic, even) functions that "do one thing, and do it well". Minimize dependence upon global data or any data outside the function scope. Simplify application "flow". Craft features that can be independently tested. I could go on...
I truly believe that FP's greatest strengths lie not in the rigid application of dogma. It's more - as you put it - aspirational.
I agree that this a very interesting way to quantify one's approach. With almost any language, there are far more tools / keywords / packages / frameworks / etc. available to us than we would ever use (or ever want to use). The tools you purposely choose to avoid probably say a lot about your coding style and your priorities when crafting solutions.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Have I ever taken any creative license?? Sure. But also keep in mind two things: 1) I've been doing this now for almost a quarter century and I tend to be a bit restless in my jobs - so I'm not typically in one place more than a year or two. This means that I've met a lot of people. 2) When I talk, in general, about some of these people, I haven't met many of them in person. But that doesn't mean they don't exist. Some nights I spend hours watching/listening to programming presentations on YouTube. Or reading programming blogs. Or sifting through the new-feature debates in various open source communities. So while I haven't met all of these people in person, I'm very confident that there's a lot of dogma out there.
As for your general approach to FP, I think we're almost perfectly aligned. I'm genuinely a fan of FP concepts. And I keep striving to be a little more FP in my coding. But I don't get hung up on the theory.
Write small standalone (atomic, even) functions that "do one thing, and do it well". Minimize dependence upon global data or any data outside the function scope. Simplify application "flow". Craft features that can be independently tested. I could go on...
I truly believe that FP's greatest strengths lie not in the rigid application of dogma. It's more - as you put it - aspirational.
I think a good way for one to introspect on how they approach designing systems, is to reflect on what one does NOT use.
It helps answer the question, "How minimalist am I?"
Or, how "As simple as possible but no simpler" am I?
I created a list of "program constructs I do not use" here...
dev.to/functional_js/what-subset-o...
I agree that this a very interesting way to quantify one's approach. With almost any language, there are far more tools / keywords / packages / frameworks / etc. available to us than we would ever use (or ever want to use). The tools you purposely choose to avoid probably say a lot about your coding style and your priorities when crafting solutions.