Casey Muratori on getting rid of OOP mindset [video](youtube.com)
youtube.com
Casey Muratori on getting rid of OOP mindset [video]
https://www.youtube.com/watch?v=GKYCA3UsmrU
8 comments
Functional (FP) tends to be a "personality fit" thing. Many who do just fine in procedural and/or OOP don't transition to FP well.
FP shops have tried since the early 60's to stay viable and expand, but usually fail outside of niche domains. I'm just the messenger. FP has had more than plenty of shots throughout history to prove its mettle in the real world.
I personally have found FP hard to debug. The "naked state" of imperative programming is actually helpful when debugging, because the context is laid out on a nice little e-desk to examine. With FP you mostly have to open and inspect one drawer at a time.
One FP proponent replied, "well, then make fewer bugs." No comment, other than reminding that one can't control other people's creation of bugs even if they can control their own.
FP shops have tried since the early 60's to stay viable and expand, but usually fail outside of niche domains. I'm just the messenger. FP has had more than plenty of shots throughout history to prove its mettle in the real world.
I personally have found FP hard to debug. The "naked state" of imperative programming is actually helpful when debugging, because the context is laid out on a nice little e-desk to examine. With FP you mostly have to open and inspect one drawer at a time.
One FP proponent replied, "well, then make fewer bugs." No comment, other than reminding that one can't control other people's creation of bugs even if they can control their own.
> I personally have found FP hard to debug.
I can very honestly say pure functions are the easiest thing to debug and test: Inputs, outputs. Trivial for unit testing.
I can't speak for MLs/Haskell, but debugging pure functions in any language tend to just be glancing at the stack trace, seeing the values on the stack going in, and then seeing where the unexpected wrong output came out, and being fairly confident knowing the issue is going to be in that function.
> The "naked state" of imperative programming
Are we including OO in this definition? The fundamental design pattern of OO is to encapsulate state. It's anything but naked, always being wrapped in object instances, only accessible via getters/setters, scattered into a million pieces across many instances of the system.
Conversely, Clojure has the most naked state ever. There's usually little to no state, and the current state is right there on the stack. Most simple Clojure programs with state have a singular atom aptly named "state" which is passed around, easy to inspect and modify as it's a simple data structure.
I think, ultimately, there's a common conflation of "Functional Programming" meaning "Declarative Type-Driven Functional Programming", when the reality is there are alternatives to ML/Haskell, aside from applying Functional patterns in "non-functional" languages.
I can very honestly say pure functions are the easiest thing to debug and test: Inputs, outputs. Trivial for unit testing.
I can't speak for MLs/Haskell, but debugging pure functions in any language tend to just be glancing at the stack trace, seeing the values on the stack going in, and then seeing where the unexpected wrong output came out, and being fairly confident knowing the issue is going to be in that function.
> The "naked state" of imperative programming
Are we including OO in this definition? The fundamental design pattern of OO is to encapsulate state. It's anything but naked, always being wrapped in object instances, only accessible via getters/setters, scattered into a million pieces across many instances of the system.
Conversely, Clojure has the most naked state ever. There's usually little to no state, and the current state is right there on the stack. Most simple Clojure programs with state have a singular atom aptly named "state" which is passed around, easy to inspect and modify as it's a simple data structure.
I think, ultimately, there's a common conflation of "Functional Programming" meaning "Declarative Type-Driven Functional Programming", when the reality is there are alternatives to ML/Haskell, aside from applying Functional patterns in "non-functional" languages.
If you can document how to do and think "properly" and efficiently under FP, that would be helpful. Sometimes it's really hard to convey how our mind works to other minds. Thus, "it works for me" is hard to extrapolate.
I really like the concept of "compression oriented programming" that Casey outlines here. You write an imperative program and make functions and objects as "compressions" of your original code, where suitable. That way you don't end up with a jungle of objects, and, on the other hand, don't start constructing monads or producing hundreds of tiny functions just for the ideology of it all.
Keep in mind that what may seem like "personality fit" may be more related to "learned imperative programming first".
As an analogy, depending on which spoken language a person learned first (as a child, _automatically), learning some new languages may be particularly difficult or quite natural.
If we had all learned functional programming concepts first, our minds would be trained to think that way. We all learned functional (declarative) math, and we don't even think about it as such. It's just math.
This video gives some plausible explanations as to why imperative programming is more common than functional: https://youtu.be/QyJZzq0v7Z4
As an analogy, depending on which spoken language a person learned first (as a child, _automatically), learning some new languages may be particularly difficult or quite natural.
If we had all learned functional programming concepts first, our minds would be trained to think that way. We all learned functional (declarative) math, and we don't even think about it as such. It's just math.
This video gives some plausible explanations as to why imperative programming is more common than functional: https://youtu.be/QyJZzq0v7Z4
That may be part of the problem, but it also may be true that some minds simply work better under one paradigm than another. Since one must show proficiency in imperative to get into the field, that's a filtering mechanism that guarantees most programmers can handle imperative already. If they change to functional, some may not handle it so well, taking much longer to learn.
Observations of various organizations that tried it seem to confirm this. They have problems after the original team leaves.
Observations of various organizations that tried it seem to confirm this. They have problems after the original team leaves.
I’m starting to think that technology doesn’t change nearly as quickly as strong opinions about technology. FP has been around forever and it will still be around when someone digs up an idea from the seventies that got forgotten because everyone was being brow beaten by the “forget X the only true way to program is Y” crowd. Im tired of the dogma and the stifling of real criticisms. Everyone taking a dump on everyone’s ideas only to turn around and repackage it and sell it as something new to unquestioningly champion. There’s a wasteland of technologies that were once the one true way that were discarded as unworthy when something new came along. Usually there wasn’t anything fundamentally wrong with it which is why they’re resurrected years later but I wonder what the cost is of these boom and bust cycles are.
If the language in question does provide OOP features, these features (well implemented or not) are probably not going to be taught in the normal path of education for the language. Thus, you probably won't have to make an effort to avoid them.
Again, this suggestion is for the new to programming segment of people; so also assuming these are undergraduate or younger level, I wouldn't suggest something like Haskell. While it is probably an excellent language to learn as part of one's path to being a good developer, it might be a bit steep for someone new to programming.
Instead, I would choose F#, Clojure, or Elixir in that order. I would not choose Scala, because there's more of a chance that some early educational material would be from the OOP perspective.