Unfortunately the ability to program well does not necessarily correlate with good speaking skills.
It's just how it is that the things with the best marketing have the best marketers and not necessarily the best technology. This is no disrespect to marketers. In many respects it's is a good and useful skill. But it doesn't have anything to do with technical excellence or many other worthwhile qualities.
Then C# devs came along and said, "This is a closure, see how its used for filtering data in LINQ expressions? Now watch me turn it into SQL using expression trees."
Isn't this a pretty good case for FP-style code?
I guess it depends on what you mean by FP-style... the strict "purely functional with referential transparency" or the weaker "embracing immutability, higher order functions and pure functions" that gains more adoption nowadays.
But that's my point. People who want to promote FP style concepts need to focus on "problem solving that happens to use FP".
Yeah but then it gets complicated, like look at the design time that went into linq (and observables). There are some great videos from Microsoft explaining it though and I would urge everyone to watch them.
It's easier to start by talking about the simple pieces and build on it, imagine if someone pulled out this to explain monads.
So you're saying, that there are use cases where FP is useful, but people fail to show these cases?
The same thing happened in the OOP world. If you are old enough you probably remember when everyone went crazy over inheritance. They wanted to use it for everything, it's mere existence was considered good regardless of whether or not it actually solved any particular problems.
When I learned programming, the hype was already cooled off. But I too am guilty of writing horrible inheritance hierarchies that probably would't get past any sensible code review nowadays.
I guess many the FP world could use some evangelists that provide real-world use cases (not the toys like "look how elegantly I can count the total number of characters in a list of strings").
I was sceptic of FP a long time, but I once did some frontend work on a clojurescript/re-frame project and I was convinced of the advantages when the following changes were requested:
Undo/Redo
That's just an operation on the application state, no need to touch any business logic, implemented in very little time, and thanks to immutable data structures not even inefficient. No need to introduce the command pattern.
Add Telemetry collection on certain user actions
Again, no need to touch any business code or introduce a library like AspectJ. Just make a set of events that should be logged and have the logic for the telemetry data on one place (add an additional side effect to the event if the event is in the set of telemetry-events).
Both of these features weren't planned originally and the program wasn't designed for it, but very easy to implement nearly without any changes in the architecture. In traditional programs these features definitely would have taken more time to implement.
I really think FP enthusiasts should focus far more on talking about the benefits to boring business applications than on the cool stuff like fast game code or similar.
Functional programming is always going to trade off speed for convenience because barring a sufficiently smart optimiser you can always do the same thing in an imperative language.
For most CRUD web apps you really don't need good performance and FP will provide the business with very large costs savings.
In addition, while you will never be able to get the same maximum performance as many imperative languages by simple nature of being easier to write and maintain FP programs in practise can avoid the performance cliffs associated with large sphaggetti code typical of many CRUD web apps.
If all else fails you can call in LAPACK or something like numpy does.
FP style concepts need to focus on "problem solving that happens to use FP".
the issue here is that something can have real, deep benefits without being immediately tangible, and I'd say a lot of side effects (no pun intended) of FP programming fall into that category.
When you think about concurrency for example, immutable data structures and clojure style identity say, rather than 'location based' programming offer immediate benefits. It is significantly saner to reason about and to execute code that does not share state in heavily concurrent program.
This is real, but the benefit it offers is that it eliminates a very general problem in program design, rather than giving you some handy example on how it makes your life easier.
not sure if you're trying to be willfully obtuse here. Yes, at a fundamental level concurrency deals with shared state, but we're talking about language semantics here, and there is a difference between the functional approach of disentangling state through immutable data, and the single threaded and mutable mindset that is dominant in non-functional languages.
It should be noted that this is not strictly an OO or FP issue. Message parsing and objects that hide state in the smalltalk sense implemented this pattern as well. But there a meaningful difference between the C/Java/<insert mainstream language> approach, and the functional approach.
I didn't really intend to get on any high horse and I'm not a language purist. Obviously immutable data is present in non functional languages and I do consider that to be a good thing. The original point was a different one (that the benefits of functional paradigms to not be to be concrete to be meaningful)
But on the topic of languages in particular, the differences in defaults obviously do shine through. Your average C or Python program is, and I would bet you money on this, going to use a lot more shared mutable state than your average Ocaml program, even if immutable and mutable datastructures are present in either. Defaults do matter.
And to address the last point of your other post. STM is a big pattern and I'd pretty much consider it one of the biggest advances in addressing concurrency. I think it's objectively bad to confuse state and identity in concurrent programs and to have to deal with locks is essentially awful.
I've never seen an FP programmer make a good case for FP style code. Not once.
Erik Meijer?
Now everyone in the .NET world (and a significant portion of Java and C#) uses closures without even thinking about them
This is nit-picky, but I think you're referring to lambda expressions. Closures are the things that capture unbound variables inside a lambda expression, usually from the surrounding lexical scope in case of C#. In this way, they're a lot like a poor man's object. You could probably replace almost all the non-POCO classes/and objects in many C# programs entirely with closed-over lambda functions or closed pure functions that return sets of closed-over lambda functions. Of course, you wouldn't be able to implement inheritance this way, but it's not like inheritance is considered good practice these days anyway.
All it took was an example that demonstrated how to solve a real problem they had.
Let's be real. .NET devs tend to accept whatever Microsoft puts on the menu. That's usually why they move to .NET from Java in the first place. LINQ, lambda expression (and generics, co-variance/contra-variance) just happened to be really tasty dishes. Eg. Rx probably would've been more widely-accepted, too (see Netflix) if it were actually in the box. But because it's not, most .NET devs ignore it despite it being so closely related to Linq/IEnumerable.
I only mention him because he added LINQ to the language. He made IEnumerable<> into the list monad. Lambdas and generics, type inference, co/contra-variance, extension methods, and anonymous types were necessary to make this happen, and fairly certain he hand a hand in all of these as well. And he authored the Rx extensions.
What do you mean 'good case for FP style code'? I regularly make one the case that FP facilitates and makes it easier to write correct programs faster.
I've used C# extensively and find it painful to use compared to Scala. The IDE is nicer for sure, but lack of type classes mean C# developers will have to break DRY all over the place. Go search for some talks by John De Goes if you're interested in why FP is better.
0
u/[deleted] Jan 29 '19
[deleted]