4 ms·

Semi off-topic, but might helps others as well: What should an experienced OO dev read to better understand how dynamic FP languages, like Clojure, alleviate th

by pwm 11y ago

Semi off-topic, but might helps others as well: What should an experienced OO dev read to better understand how dynamic FP languages, like Clojure, alleviate the aforementioned cons of OO in the architecture of large-scale agile projects? In other words: I know from experience what's the downside of OO, but I don't know how dynamic FP languages would help without sacrificing the benefits of OO?

Skinney 11y ago
What are the benefits of OO? I normally think of encapsulation, but this isn't that big of a deal in Clojure (or many other functional languages) as you normally can't mutate objects anyway.
- danenania 11y ago
  I see encapsulation as being more or less orthogonal to mutability. The main benefit is helping to preserve a consistent interface that doesn't expose much implementation structure. Functional languages are at least as capable of encapsulation as oo. It's just accomplished through namespaces instead of objects.
- pwm 11y ago
  Hm, good question :). By the "benefits of OO" I meant a collection of strategies that evolved over time to tackle the difficulty of building complex systems: encapsulation, composition, interfaces, patterns, SOLID principles, etc... I think what I'm after is an OO-FP map of these concepts, or more probably: alternative strategies.
  - grayrest 11y ago
    I'll answer these specifically for Clojure since they vary by language. > encapsulation Encapsulation is primarily a state control concept. It reduces the surface area of a piece of data to the object it's contained in. The reduction in the amount of code that can touch the data makes it easier to reason about. Clojure works around this by having most of its data be immutable and most functions pure. Debugging is walking up the stack trace to find the change you didn't expect. > composition Pure functions compose trivially. Encapsulating data in a class actually limits your composition by design. Using maps lets you re-use the many functions in the standard library pretty much everywhere. > interfaces Clojure has an extended version called protocols. It provides an api guarantee but it can be retroactively implemented on Java classes you don't control. Look up the expression problem in clojure for considerably more depth. You can also use multimethods if you want to dispatch on something besides class. > Patterns I subscribe to the argument that patterns are workarounds for limitations in a language. Most languages have them but nobody else formalizes them like the Java people. There are ways to accomplish the same objectives, generally with less ceremony. > SOLID Single Responsibilty - Concept carries over to functions in a namespace, a good idea in general Open/Closed - I've always understood this to mean encapsulation, see above. Liskov substitution - Dynamic languages are duck typed. If you want more assurance you can add something like Schema, which does structual subtyping instead of nominal subtyping. Interface segregation - Preference in the community is for protocols to be VERY small, usually 1-5 functions. Dependency inversion - Tends to not come up. Usually when you're designing an API you have a good idea for when a consumer is going to want different behavior. In those cases, you have the API take a function instead.
  - robto 11y ago
    I found this article[0] a pretty enlightening tour of how SOLID principles don't require traditional OO. You might find it useful in transitioning - it explains how each of these concepts maps onto idiomatic Clojure. [0]http://www.lispcast.com/solid-principles-in-clojure http://www.lispcast.com/solid-principles-in-clojure
g8gggu89 11y ago
> but I don't know how dynamic FP languages would help without sacrificing the benefits of OO? Are the comparisons are hard to find online, or are they not addressing your exact issue? What benefits of OO do you think you'd be losing?
cies 11y ago
> the benefits of OO? For me understanding the greatness of FP was build on the understanding that there are no "benefits of OO". Once I realized that the "abstractions of classes and inheritance" and "encapsulations of state in objects" (and other OO-paradigm pillars) where harmful, I started truly researching the alternatives. I could go back to C --imperative, state-all-over-the-place, self-managed memory-- but it seemed like an impossible step in web development. Quickly I found promise in languages like Clojure and Haskell. High-level enough for web development, yet faster them my trusted Ruby code, and seemingly more maintainable. The main benefit of OO I know experience is it's popularity. Going from Java to Ruby is a lot easier then from Ruby to Clojure or Haskell. The good news: many OO languages are incorporating FP'isms, and allowing a functional approach to solve problems, this helps FP like myself newcomers quite a bit. TL;DR: I came to the realisation that the benefits of OO where mainly theoretical and did not hold in practice. Main 'real' benefit of OO is its popularity.
- pjmlp 11y ago
  So you never make use of multimethods or type classes? Most of those FPisms (LINQ) are already present in Smalltalk.
- adrianm 11y ago
  I encourage you to read Practical Common Lisp for an introduction to CLOS - the Common Lisp Object System. It's available for free online. (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) If you are convinced that there may be something to object-oriented programming in Common Lisp that might be interesting and novel, I suggest two further advanced readings: Object Oriented Programming in Common Lisp and The Art of the Metaobject Protocol. I use Clojure professionally, and CLOS is easily the thing I miss most.
  - SpaceCadetJones 11y ago
    Do you have some examples of when you prefer to use an OO style vs traditional FP? This is something I've been contemplating as I learn FP
- 11y ago
pjmlp 11y ago
> but I don't know how dynamic FP languages would help without sacrificing the benefits of OO? What do you mean, given that Smalltalk, JavaScript, SELF, Ruby, Python, Dart, Dylan, Common Lisp, Julia, StrongTalk .... Are all dynamic languages with OOP features.
rifung 11y ago
I might just be confused, but from what read/understand I don't think FP vs OO is a proper comparison. I think the right question should be FP vs imperative languages? As far as I know even functional languages can have OO features, but functional programming is more about getting away from an imperative style of programming. Maybe someone who knows more can chime in though. But in my personal experience, using a functional language just helps me write correct code. Using an imperative language makes it easy to be sloppy and include bugs

by pwm 11y ago

Skinney 11y ago

What are the benefits of OO? I normally think of encapsulation, but this isn't that big of a deal in Clojure (or many other functional languages) as you normally can't mutate objects anyway.

danenania 11y ago
I see encapsulation as being more or less orthogonal to mutability. The main benefit is helping to preserve a consistent interface that doesn't expose much implementation structure. Functional languages are at least as capable of encapsulation as oo. It's just accomplished through namespaces instead of objects.
pwm 11y ago
Hm, good question :). By the "benefits of OO" I meant a collection of strategies that evolved over time to tackle the difficulty of building complex systems: encapsulation, composition, interfaces, patterns, SOLID principles, etc... I think what I'm after is an OO-FP map of these concepts, or more probably: alternative strategies.
- grayrest 11y ago
  I'll answer these specifically for Clojure since they vary by language. > encapsulation Encapsulation is primarily a state control concept. It reduces the surface area of a piece of data to the object it's contained in. The reduction in the amount of code that can touch the data makes it easier to reason about. Clojure works around this by having most of its data be immutable and most functions pure. Debugging is walking up the stack trace to find the change you didn't expect. > composition Pure functions compose trivially. Encapsulating data in a class actually limits your composition by design. Using maps lets you re-use the many functions in the standard library pretty much everywhere. > interfaces Clojure has an extended version called protocols. It provides an api guarantee but it can be retroactively implemented on Java classes you don't control. Look up the expression problem in clojure for considerably more depth. You can also use multimethods if you want to dispatch on something besides class. > Patterns I subscribe to the argument that patterns are workarounds for limitations in a language. Most languages have them but nobody else formalizes them like the Java people. There are ways to accomplish the same objectives, generally with less ceremony. > SOLID Single Responsibilty - Concept carries over to functions in a namespace, a good idea in general Open/Closed - I've always understood this to mean encapsulation, see above. Liskov substitution - Dynamic languages are duck typed. If you want more assurance you can add something like Schema, which does structual subtyping instead of nominal subtyping. Interface segregation - Preference in the community is for protocols to be VERY small, usually 1-5 functions. Dependency inversion - Tends to not come up. Usually when you're designing an API you have a good idea for when a consumer is going to want different behavior. In those cases, you have the API take a function instead.
- robto 11y ago
  I found this article[0] a pretty enlightening tour of how SOLID principles don't require traditional OO. You might find it useful in transitioning - it explains how each of these concepts maps onto idiomatic Clojure. [0]http://www.lispcast.com/solid-principles-in-clojure http://www.lispcast.com/solid-principles-in-clojure

g8gggu89 11y ago

> but I don't know how dynamic FP languages would help without sacrificing the benefits of OO? Are the comparisons are hard to find online, or are they not addressing your exact issue? What benefits of OO do you think you'd be losing?

cies 11y ago

> the benefits of OO? For me understanding the greatness of FP was build on the understanding that there are no "benefits of OO". Once I realized that the "abstractions of classes and inheritance" and "encapsulations of state in objects" (and other OO-paradigm pillars) where harmful, I started truly researching the alternatives. I could go back to C --imperative, state-all-over-the-place, self-managed memory-- but it seemed like an impossible step in web development. Quickly I found promise in languages like Clojure and Haskell. High-level enough for web development, yet faster them my trusted Ruby code, and seemingly more maintainable. The main benefit of OO I know experience is it's popularity. Going from Java to Ruby is a lot easier then from Ruby to Clojure or Haskell. The good news: many OO languages are incorporating FP'isms, and allowing a functional approach to solve problems, this helps FP like myself newcomers quite a bit. TL;DR: I came to the realisation that the benefits of OO where mainly theoretical and did not hold in practice. Main 'real' benefit of OO is its popularity.

pjmlp 11y ago
So you never make use of multimethods or type classes? Most of those FPisms (LINQ) are already present in Smalltalk.
adrianm 11y ago
I encourage you to read Practical Common Lisp for an introduction to CLOS - the Common Lisp Object System. It's available for free online. (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) If you are convinced that there may be something to object-oriented programming in Common Lisp that might be interesting and novel, I suggest two further advanced readings: Object Oriented Programming in Common Lisp and The Art of the Metaobject Protocol. I use Clojure professionally, and CLOS is easily the thing I miss most.
- SpaceCadetJones 11y ago
  Do you have some examples of when you prefer to use an OO style vs traditional FP? This is something I've been contemplating as I learn FP
11y ago

pjmlp 11y ago

> but I don't know how dynamic FP languages would help without sacrificing the benefits of OO? What do you mean, given that Smalltalk, JavaScript, SELF, Ruby, Python, Dart, Dylan, Common Lisp, Julia, StrongTalk .... Are all dynamic languages with OOP features.

rifung 11y ago

I might just be confused, but from what read/understand I don't think FP vs OO is a proper comparison. I think the right question should be FP vs imperative languages? As far as I know even functional languages can have OO features, but functional programming is more about getting away from an imperative style of programming. Maybe someone who knows more can chime in though. But in my personal experience, using a functional language just helps me write correct code. Using an imperative language makes it easy to be sloppy and include bugs