So does this make Clojure a hybrid functional / object oriented language like Scala? Or how do these features compare to the object oriented features of Scala? Which approach do you prefer?
It makes it a hybrid functional / object oriented language like common lisp, man.
Lisps in general are not functional languages, they're verb-oriented (or classically, “procedure oriented”). The functional stuff is sort of a legacy moniker that meant something very different when Sussman & Steele wrote "Lambda the Ultimate Goto".
Clojure was always a bit of a hybrid- long before datatypes and protocols (see multimethods, hierarchies). Clojure preserves the many good parts of OO while stripping away the yucky cruft we've accumulated over the years.
From what I've seen of Scala, while delivering on a good dose of FP, it continues on with the fundamental problems (encapsulating state inside the object, poor notion of value, and thus very primitive tools for concurrency).
On a low level, Clojure exposes the underlying JVM, so you can instantiate and bang on Java objects all you want. It's "hybrid" in that sense, and always has been. That isn't changing. But dipping into Java in Clojure is used mostly for interop with Java libraries or to get better performance for critical sections of code.
On a higher level, in Clojure itself, there's not much OO going on (depending how you define OO), and that's not changing much either. In the new defrecords: 1) Everything is immutable, 2) There's no encapsulation of methods inside objects, 3) There's no inheritance of method implementations from "parent classes", 4) There's no data-hiding, and all fields are public. Uncontrolled thread-unsafe mutation of "objects" is still not kosher. Defrecords are kind-of-OO in the sense that there are named types that you can instantiate, the resulting things have named fields, and there's some polymorphism going on when you use protocols. But it's not really very OO in my opinion.
"Object oriented" and "functional" are so loosely-defined that it's almost best to avoid using the terms entirely, in my opinion. See http://clojure-log.n01se.net/date/2010-04-21.html for some of Rich Hickey's opinions on how OO Clojure is nowadays. Rich uses the term "abstraction-oriented" to describe Clojure.
> Protocols in Clojure are similar to Java Interfaces, though not quite. Basically a protocol is a contract, a set of functionalities without any implementation
I asked Rich Hickey and this is what he had to say - "they differ from Go interfaces in that Go just uses method conformance to determine interface support (vs explicit declaration of 'I implement this protocol'), and Go's interfaces, last time I checked, were only 'open' within a module."
For someone who knows neither particularly well but is intrigued by the parallels, how closely does this map to Haskell's type classes? To the uninitiated it almost looks like a direct reimplementation.
I asked Rich Hickey, and this is what he had to say - "they differ from Haskell's type classes (from which they draw partial inspiration) in that the dispatch map isn't an independent entity passed around by the type system, and thus can't do return-type based method selection, and generally in that they are not static-type-system-based."
9 comments
[ 0.22 ms ] story [ 53.7 ms ] threadLisps in general are not functional languages, they're verb-oriented (or classically, “procedure oriented”). The functional stuff is sort of a legacy moniker that meant something very different when Sussman & Steele wrote "Lambda the Ultimate Goto".
From what I've seen of Scala, while delivering on a good dose of FP, it continues on with the fundamental problems (encapsulating state inside the object, poor notion of value, and thus very primitive tools for concurrency).
On a higher level, in Clojure itself, there's not much OO going on (depending how you define OO), and that's not changing much either. In the new defrecords: 1) Everything is immutable, 2) There's no encapsulation of methods inside objects, 3) There's no inheritance of method implementations from "parent classes", 4) There's no data-hiding, and all fields are public. Uncontrolled thread-unsafe mutation of "objects" is still not kosher. Defrecords are kind-of-OO in the sense that there are named types that you can instantiate, the resulting things have named fields, and there's some polymorphism going on when you use protocols. But it's not really very OO in my opinion.
http://clojure.org/datatypes and http://clojure.org/protocols are the official docs, if you want to know exactly what you're getting.
"Object oriented" and "functional" are so loosely-defined that it's almost best to avoid using the terms entirely, in my opinion. See http://clojure-log.n01se.net/date/2010-04-21.html for some of Rich Hickey's opinions on how OO Clojure is nowadays. Rich uses the term "abstraction-oriented" to describe Clojure.
how is this different from Go's implementation of an 'interface' type http://golang.org/doc/go_for_cpp_programmers.html#Interfaces