DEV Community

Discussion on: Teaching Functional Programming: Two Big Picture Approaches

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

Thanks for the article. I like where it is going, and I’d love to see more.

One thing though. I do not believe FP is hard, not harder than OO. I think changing paradigms is what is hard. I’ve brought fresh devs into FP and I never had to explain SOLID or inheritance gotchas or law of Demeter or many other things which are considered normal in OO. These just aren’t things that trip up FP programmers. In training them I also never got into type theory. I just focused on pure functions. The reuse you get from some type-based things are nice discoveries along the way. However when you already know how to solve a lot of problems in one paradigm, changing to the other means having to relearn, which is hard. I think it would be equally difficult switching from lots of experience in FP to OO, but not many of those people exist to tell us.

Collapse
 
sudeeprp profile image
Sudeep Prasad

Are they really two different things? Sometimes a function needs state, so we can combine/hide/abstract it in an object... Mostly we can avoid coupling it to state, so it can remain a pure function. Maybe I'm too focused on the implementation... Am I missing something here?

Collapse
 
kspeakman profile image
Kasey Speakman

Yes, the characteristics and design of one versus the other are drastically different and do not work well together. Objects lead you to create an object graph (object containing references to other objects) with mutable state distributed all throughout the graph, and that is what constitutes a program. State is shifting sand -- it is always moving underneath you due to mutations (from external method calls on the object). FP uses immutable state where possible and programs look like a tree of functions with data flowing between them. You can examine/modify an individual pure function in that tree in complete isolation -- you don't have to know or care what the rest of the program is doing because its outputs only depend on its inputs. But to get that benefit, you have to design and solve problems slightly differently than what OO programmers muscle memory will be.

Thread Thread
 
sudeeprp profile image
Sudeep Prasad

I understand what you mean. I'd been stuck with the 'smeared state in objects' rut for a while. I realized that I was just bucketing shared-state without really thinking about the decomposition-goals. I would hesitate to call my mess as object-oriented. It felt more like 'class-oriented random-partitioning'
These days I recognize object-oriented as a caching mechanism, like when UI Widgets need to keep local state to animate/re-draw themselves without a round-trip to the server (like StatefulWidget in Dart). Relationships are more like constraints. Where caching is not needed, a pure function that can be tested in isolation is the way to go!

Collapse
 
dizid profile image
Marc de Ruyter

Similar to going from SQL to no-SQL databases or changing from (PHP) to asynchrone (node.js).
An old dog can learn new tricks, but it takes alot of re-training.

Collapse
 
eddroid profile image
Ed Toro

You make a good point about the advantage of being first (First-mover advantage? First-learned? I don't know if there's a name for it.)

I get a sense from FP evangelism that, if not for some historical accident, the tables would be turned. FP would be the dominant paradigm and I would instead feel compelled to write an article about teaching OOP. But I don't know enough about the history of this debate to say one way or the other.

I'm inclined to believe that OOP dominated (and still dominates) because of something inherently more desirable about it rather than a coin toss that always landed in OOP's favor at engineering meetings over the past decades. But I admit I could be wrong.

The "mistake" I hint at in this article is that, upon first learning (or "first-learning", if I may coin a new term) FP (like I did with Scheme), to later see it ignored in the industry is disheartening to a new, job-seeking graduate. Throwing a bunch of FP juniors into the marketplace to see them struggle to find work isn't going to solve the problem, no matter how superior FP may seem to some.

Instead we need to acknowledge that OOP has "won" and try to figure out why and what that means for the future of coding education.

As a bootcamp instructor I like to start with OOP because it's more relevant to the job search, then introduce FP concepts gradually because I believe it's a good skill for the future. To do the reverse, given my local market conditions, would be a disservice to my student's tuition money. So this article represents a teaching strategy for that style of curriculum.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

Thanks for your generous response.

I tend to agree about starting learners with OOP. Outside of work, I have a youth mentee, and I am starting with imperative/OOP too. Mainly because that's really the only youth learning material available. And that state reflects the broader market for developers. However, internally at our company, I rather feel like I am making our devs all the more valuable by teaching them FP plus experience running FP in production. Because FP work tends to pay pretty well. At least, according to SO salary surveys.

I haven't tracked the history of FP either, but I feel like OO won (like most things that win in the market) because it had compelling products sooner. Smalltalk is a common cited example, and is generally considered a great experience. Interestingly, I see some parallels between Smalltalk and functional methods, which were lost in later incarnations of OO. For example, there was no if in Smalltalk. Instead, you tell the boolean object: ifTrue, run these statements. And your other objects with multiple data cases tended to be modeled this way too. Seems structurally similar to category objects and their operations. Of course, it was still imperative and it still mixed state and behavior together.

I also meant to mention. I agree that FP is generally done a disservice by people being religious about it. OO is and will continue to be a perfectly valid way to solve problems. Follow your bliss! But I like to share my FP experiences in case someone is interested. My particular journey into FP was because, despite my best efforts, I was dismayed at the long term quality of products I created. FP was one of many things I tried. FP doesn't fix the quality problem on its own, but it plays a helpful part for me. In that FP makes pure functions easier to write. And pure functions make refactoring significantly less risky.

Thread Thread
 
mkoennecke profile image
mkoennecke

I would like to chime in that the difficult bit is the change in paradigm. I started my career with Fortran 77 and I still remember learning OOP. It was hard to get my head around that and the first two OO programs I wrote were crap. Working but crap.

The next paradigm shift came with UI code being event based.