I was traditionally trained like you under OOP and procedural methodologies.
After encounter FP I fully bought in and developed two mental models. The fp model lives side by side with the the oop/imperative model.
With equal knowledge in both one can make a more unbiased judgement. The fp model is actually superior imo.
I largely have the opposite strategy now when programming. My mental model is largely fp, and I occasionally cheat and sprinkle in procedural or oop syntax here and there as syntactic sugar.
The basic realization here should be that mutating shared state should be avoided and segregated as much as possible.
To be fair, all languages are syntactic sugar over asm which is s-s over CPU machine code. A mental model is just that: a model for something physical that's in your head. FP or OOP are both mental models for programming in nearly any language. Some languages have first-class FP or OOP features, and some don't, but you can tack-on either of these, and others, to nearly any language you want to. It's really dumb to look down on others choice of mental model if it works for them. I have seen successful projects that were designed around both OOP and FP models.
Yes everything is technically syntactic sugar but the context in which I used the word implied that the usage is mostly as a shortcut. From his post it seems he's not following a mental model of fp, he's just occasionally using an anonymous function or map and reduce in place of a procedural counterpart.
I'm not looking down on anyone here, let's be clear. I am simply stating my counter opinion to his opinion. That's all.
>I have seen successful projects that were designed around both OOP and FP models.
No project can be fully and perfectly designed around the fp model. This is because there is such a thing as mutating state and side effects. Something has to mutate, side effects must exist. Unless your project is 100 percent Haskell some aspect of it will likely not be fp. Usually for web this is the database or the cache or some function that touches io.
When we talk about the fp model there is merit in saying that it is superior to the oop model. Many experts agree that the most modular form of programming is to use pure combinators as building blocks. The minute you introduce side effects and mutations into the system those side effects pollute the code with modules that are harder to break down and code becomes harder and harder to test.
Many will agree that the goal of the fp model is the reduction of mutation and side effects as much as possible. Write your code in such a way that io and mutation are small, modular and segregated away from your pure logic.
Most people think of fp as map, reduce and "functions as values". This is not the "model of fp". These features of fp exist to overcome the strict rules of fp. They can be used in other contexts as well, but using these "features" in other contexts does not mean you are following the fp model. I have yet to find a person who understands the fp model and does not think it is superior to oop.
The ultimate form of modularity where your code becomes Lego building blocks which you fit together in a sort of type Tetris is only fully realized with fp. No other programming paradigm achieves it as the pure combinator is the most fundamental building block of logic. To do fp is to declare that most of your program will be composed of these modular blocks.
I genuinely believe that if you and the GP fully get what I'm talking about and it clicks for you, both of you will agree. Again I'm not looking down on you guys. Just offering my real opinion. It's unfortunate that in order for me to point out this opinion I have to point out a certain lack of familiarity for FP among the GP and you, but I mean no harm by it. If the tables were turned I would welcome such opinions.
You underestimate the importance of compatibility and familiarity for existing developers. You can show C# code to any C++, Java or even JS programmer and expect them to grasp the idea of what's going on very quickly. This is a big deal and should not be discarded lightly
I think the reason it sometimes seems like it is that easy is that, as we gain experience with tools, we tend to forget the difficulties we had learning them.
Learning F# it instantly clicked.
OOP learning issues IMHO are intrinsic to the style, because it's just so seldom helpful in making programming easier.
Design patterns are just a symptom of this issue. That OOP is just a misunderstanding another.
"Real" OOP as practiced in Erlang/Elixir is quite useful.
their target audience does not want this
This one I still can't wrap my head around. F# basically was the source of almost all innovation in C# and C# still is missing some features and was not designed in the same way as F# so a lot of the features they "stole" feel tacked on.
Microsoft should have just made F# the C# successor.