4 ms·

Clojure Protocols & Datatypes — A sneak peek

67 points by budu 16y ago

albertcardona 16y ago
Clojure continues making everyday programming easier, while ensuring type and time and thread correctness. Outstanding.
silkodyssey 16y ago
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?
- KirinDave 16y ago
  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".
- swannodette 16y ago
  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).
- briancarper 16y ago
  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. http://clojure.org/datatypes http://clojure.org/datatypes and http://clojure.org/protocols 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 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.
signa11 16y ago
> Protocols in Clojure are similar to Java Interfaces, though not quite. Basically a protocol is a contract, a set of functionalities without any implementation how is this different from Go's implementation of an 'interface' type http://golang.org/doc/go_for_cpp_programmers.html#Interfaces http://golang.org/doc/go_for_cpp_programmers.html#Interfaces
- zaph0d 16y ago
  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."
regularfry 16y ago
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.
- zaph0d 16y ago
  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."

67 points by budu 16y ago

Clojure continues making everyday programming easier, while ensuring type and time and thread correctness. Outstanding.

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?

KirinDave 16y ago
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".
swannodette 16y ago
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).
briancarper 16y ago
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. http://clojure.org/datatypes http://clojure.org/datatypes and http://clojure.org/protocols 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 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.

signa11 16y ago

> Protocols in Clojure are similar to Java Interfaces, though not quite. Basically a protocol is a contract, a set of functionalities without any implementation how is this different from Go's implementation of an 'interface' type http://golang.org/doc/go_for_cpp_programmers.html#Interfaces http://golang.org/doc/go_for_cpp_programmers.html#Interfaces

zaph0d 16y ago
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."

regularfry 16y ago

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.

zaph0d 16y ago
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."