3 ms·

> a lot of its idiomatic abstractions are object oriented in nature This is a curious comment, and I'd like to hear some elaboration. I used C++ for years, th

> a lot of its idiomatic abstractions are object oriented in nature This is a curious comment, and I'd like to hear some elaboration. I used C++ for years, then 2 years as a full-time Clojure dev, and I don't see any OO parallels in Clojure at all.

pvdebbe 10y ago
A couple comments. * clojure protocols map to interfaces (abstract classes for C++ folks) * one can define records that satisfy protocol(s). This is one way to do OO in clojure, happens to map to the underlying JVM mechanisms for JVM optimizations to kick in. * Gamma et al., Bloch and many others tell to prefer composition over inheritance. Clojure makes this guideline easy to follow. * overall the OO leaders also recommend making classes "value classes" (everything immutable; smart copy semantics; etc) as often as humanly possible. * Multimethods allow arbitrary dispatch (most versatile kind of polymorphism) and there is also a faster method when you only want to dispatch by protocols (the (sadly) 'usually' only way to dispatch in most OO languages) that reuses JVM notion of classes and interfaces behind the curtains. * What you don't get is encapsulation, (and many, a great many authors cite encapsulation to be the definite trait of an OO language,) it can also be argued that immutable values do not need encapsulation per se. A value should be able to stand on its own, convey the semantics it needs & so on..
- hellofunk 10y ago
  > a great many authors cite encapsulation to be the definite trait of an OO language Yes this is what I was referring to, Clojure is not OO in the way that many think of OO. But your other points are right on.
  - pvdebbe 10y ago
    But what exactly is achieved with information hiding, hmm? :) Now there forms many schools of opinion, and in many of them it suffices to have data immutable and value-like, and suddenly it doesn't matter if the information is hidden into opaque memory addresses or not.
    - gkya 10y ago
      You can make sure that no other bits of code depend on that value being available and thus modify what is internal to the encapsulating unit of code rather freely.
      - hellofunk 10y ago
        You can still do this in functional programming by programming functions that only interact with their arguments, and limiting what those arguments are. Additionally, in Clojure, you can in fact hide data by not exporting it from a namespace and only providing functions that operate on it in the namespace, and some other FP languages do this also. The difference is that within the namespace/module, all data is available to all functions, which is often easier to think about and organize than adding the complexity of marrying certain data to certain functions.

pvdebbe 10y ago

A couple comments. * clojure protocols map to interfaces (abstract classes for C++ folks) * one can define records that satisfy protocol(s). This is one way to do OO in clojure, happens to map to the underlying JVM mechanisms for JVM optimizations to kick in. * Gamma et al., Bloch and many others tell to prefer composition over inheritance. Clojure makes this guideline easy to follow. * overall the OO leaders also recommend making classes "value classes" (everything immutable; smart copy semantics; etc) as often as humanly possible. * Multimethods allow arbitrary dispatch (most versatile kind of polymorphism) and there is also a faster method when you only want to dispatch by protocols (the (sadly) 'usually' only way to dispatch in most OO languages) that reuses JVM notion of classes and interfaces behind the curtains. * What you don't get is encapsulation, (and many, a great many authors cite encapsulation to be the definite trait of an OO language,) it can also be argued that immutable values do not need encapsulation per se. A value should be able to stand on its own, convey the semantics it needs & so on..

hellofunk 10y ago
> a great many authors cite encapsulation to be the definite trait of an OO language Yes this is what I was referring to, Clojure is not OO in the way that many think of OO. But your other points are right on.
- pvdebbe 10y ago
  But what exactly is achieved with information hiding, hmm? :) Now there forms many schools of opinion, and in many of them it suffices to have data immutable and value-like, and suddenly it doesn't matter if the information is hidden into opaque memory addresses or not.
  - gkya 10y ago
    You can make sure that no other bits of code depend on that value being available and thus modify what is internal to the encapsulating unit of code rather freely.
    - hellofunk 10y ago
      You can still do this in functional programming by programming functions that only interact with their arguments, and limiting what those arguments are. Additionally, in Clojure, you can in fact hide data by not exporting it from a namespace and only providing functions that operate on it in the namespace, and some other FP languages do this also. The difference is that within the namespace/module, all data is available to all functions, which is often easier to think about and organize than adding the complexity of marrying certain data to certain functions.