2 ms·

This definitely affects my decision. Personally, I love functional programming, and will use it as much as possible. Professionally, I typically go with OOP or

This definitely affects my decision. Personally, I love functional programming, and will use it as much as possible. Professionally, I typically go with OOP or even procedural whenever it's my call to make. The vast majority of people I've worked with are much more comfortable in one of those two paradigms, and that makes onboarding new people onto the project much easier. Even people who express a desire to work in a functional language don't necessarily have the experience or training to know how best to do it in a professional setting. It's to the point where I don't even like to advertise that I like to work in functional languages around the office. Too much risk of being called in to be the hero when the last person who understood the code for some pilot project to try out Scala or Clojure that grew to become mission critical decides to leave the company.

naasking 3y ago
That's why I think C# is did the industry a great service by introducing LINQ. It really drove a movement to adopting some functional-style idioms in lots of languages, even Java in the end with it's stream API. It at least got functional programming's foot in the door among industry standard OOP languages. Still a long way to go though.
- bunderbunder 3y ago
  Though, Java's stream API is not suitable for use with typical functional programming idioms the way that LINQ is. In my opinion, no code that touches it should be considered functional. That's a big part of why Scala and Kotlin code tends to avoid it.
- pjmlp 3y ago
  Was actually driven by VB.NET initially, and Erik Meyer's contribution. https://dl.acm.org/doi/abs/10.1145/1297105.1297078 https://dl.acm.org/doi/abs/10.1145/1297105.1297078 Ironically LINQ is something that was already present in Smalltalk collections, yet kind of lost in OOP languages until closures came to be.

naasking 3y ago

That's why I think C# is did the industry a great service by introducing LINQ. It really drove a movement to adopting some functional-style idioms in lots of languages, even Java in the end with it's stream API. It at least got functional programming's foot in the door among industry standard OOP languages. Still a long way to go though.

bunderbunder 3y ago
Though, Java's stream API is not suitable for use with typical functional programming idioms the way that LINQ is. In my opinion, no code that touches it should be considered functional. That's a big part of why Scala and Kotlin code tends to avoid it.
pjmlp 3y ago
Was actually driven by VB.NET initially, and Erik Meyer's contribution. https://dl.acm.org/doi/abs/10.1145/1297105.1297078 https://dl.acm.org/doi/abs/10.1145/1297105.1297078 Ironically LINQ is something that was already present in Smalltalk collections, yet kind of lost in OOP languages until closures came to be.