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.
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.
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
The library situation is a bit better now. But without a big company contributing in terms of libraries, the language usage will just be very low.
JS aside, I think there's probably some survivorship bias going on here. I don't think there are a lot of 15 year old, relatively unpopular languages that are still under active development. Maybe it's not that languages that don't become popular in 10 years never will, but rather that languages that don't become popular in 10 years tend to be abandoned by their developers, thus sealing their fate.
> I don't think there are a lot of 15 year old, relatively unpopular languages that are still under active development.
There are quite a few. If you look in virtually any language ranking, places 10-40 have many 10 year-old and even 15 year-old language. Here are some continuously developed >=15yo languages that are less-than-middling-popular and have always been so: Common Lisp, Racket, Clojure, OCaml, SML/NJ, F#, TCL, Haskell, Idris, Groovy, Squeak, Erlang, D, Ada, Nim. There are more of these than there are super-popular languages. (I didn't include any language that was, at one time, at least somewhat popular but is no longer, such as Visual Basic, Delphi, and Perl 5).
There might still be survivorship bias, but I am not saying all that is fate, just a clear historical observation.
> Languages that get adopted faster than 7 years are unusual, and it indicates that they came out at highly opportune times to address specific needs.
Not only is it not unusual, over hundreds of languages I think there has really been one exception (for 10 years; maybe not 7). At age 10 how well a language does is more or less how well it's ever going to do. I am not saying this is a prediction, but it has been the case historically with almost no exceptions. Any language has the chance to buck this trend, but it has been the trend.
As background, style insensitivity was introduced so that codebases can use a consistent camelCase or snake_case regardless of the style used by upstream libraries.