On Feb 11, 12:46 pm, HB <hubaghd...@gmail.com> wrote:
> Hey, > Since Clojure is a LISP dialect, does this mean that it doesn't > support OOP? > Thanks.
To quote Dr. Alan Kay:
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."
I suspect that Clojure is actually more suited to OOP than Java, assuming you're going by Dr. Kay's definition. :)
You can work with java objects. But clojure itself is not object oriented, because it's functional, and object orientation requires state manipulation. Other lisps support object orientation, common-lisp for example.
On Thu, Feb 11, 2010 at 1:46 PM, HB <hubaghd...@gmail.com> wrote: > Hey, > Since Clojure is a LISP dialect, does this mean that it doesn't > support OOP? > Thanks.
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscribe@googlegroups.com<clojure%2Bunsubscribe@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
Joel Westerberg wrote: > You can work with java objects. But clojure itself is not object > oriented, because it's functional, and object orientation requires state > manipulation.
By whose definition? Are you saying there is no such thing as an immutable object?
> Other lisps support object orientation, common-lisp for > example.
Clojure is not purely functional. In fact, it has special support for managing mutable state in coherent ways.
The problem is about the overloading of the "object based" expression.
A step forward could be to recognize that: * Java is a weak/simplified version of a class based language (simplifications made for several well known reasons: ease of adoption by C/C++ crowd: - algol like syntax-, reduced functionalities for debatable reasons: e.g. no C++ multiple inheritence/templates/pointers-, not fully class based for debatable performance reasons: primitive types, not everything is a class method). It did at least have the good property of popularizing the JVM and the notion of garbage collection, to cite the most evident to me. * Javascript (at least in its ancestral forms, don't know for sure since the later ECMA standardizations) is a prototype based language => true object orientation, methods "belong" to objects, not to their classes (by belong, I mean one can redefine methods on an object basis) * Smalltalk is a pure class based language. No static methods in smalltalk, thanks to its correct use of the meta-class concept.
* Clojure is a pragmatic language, function based, with a clear story for managing the parts of your application which require manipulation of internal (essential) state, or external (I/O resources) state.
I don't know if it is at all possible to map the "concept" of "object orientation" to one category and not the other ...
>> You can work with java objects. But clojure itself is not object oriented, >> because it's functional, and object orientation requires state manipulation.
> By whose definition? Are you saying there is no such thing as an immutable > object?
>> Other lisps support object orientation, common-lisp for example.
> Clojure is not purely functional. In fact, it has special support for > managing mutable state in coherent ways.
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> The problem is about the overloading of the "object based" expression.
> A step forward could be to recognize that: > * Java is a weak/simplified version of a class based language > (simplifications made for several well known reasons: ease of adoption > by C/C++ crowd: - algol like syntax-, reduced functionalities for > debatable reasons: e.g. no C++ multiple > inheritence/templates/pointers-, not fully class based for debatable > performance reasons: primitive types, not everything is a class > method). It did at least have the good property of popularizing the > JVM and the notion of garbage collection, to cite the most evident to > me. > * Javascript (at least in its ancestral forms, don't know for sure > since the later ECMA standardizations) is a prototype based language > => true object orientation, methods "belong" to objects, not to their > classes (by belong, I mean one can redefine methods on an object > basis) > * Smalltalk is a pure class based language. No static methods in > smalltalk, thanks to its correct use of the meta-class concept.
> * Clojure is a pragmatic language, function based, with a clear story > for managing the parts of your application which require manipulation > of internal (essential) state, or external (I/O resources) state.
> I don't know if it is at all possible to map the "concept" of "object > orientation" to one category and not the other ...
> >> You can work with java objects. But clojure itself is not object oriented, > >> because it's functional, and object orientation requires state manipulation.
> > By whose definition? Are you saying there is no such thing as an immutable > > object?
> >> Other lisps support object orientation, common-lisp for example.
> > Clojure is not purely functional. In fact, it has special support for > > managing mutable state in coherent ways.
> > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with your > > first post. > > To unsubscribe from this group, send email to > > clojure+unsubscribe@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en- Hide quoted text -
On 11 February 2010 13:46, HB <hubaghd...@gmail.com> wrote:
> Hey, > Since Clojure is a LISP dialect, does this mean that it doesn't > support OOP? > Thanks.
Regardless of whether Clojure supports OOP, not supporting it certainly doesn't follow from being a Lisp dialect. Take a look at CLOS (Common Lisp Object System), for instance. Incidentally, CLOS was, AFAIK, originally engineered as a package of macros and functions built on top of CL's core and only later included in the language standard.
Similarly for being functional: apart from Clojure, Ocaml and F# offer OOP-like syntactic features in otherwise mostly functional language packages. While for F# this might be considered an interop feature, that's certainly not the case with Ocaml.
I'm ill prepared to debate the correct definition of object orientation, so I won't offer one, but at the very least I feel justified in believing that there simply isn't one superior approach to OOP (personally, I'm partial to the approach of not prodding it with less than a 10 foot pole, but... um... never mind). If anything, Clojure's being a Lisp makes it easier to come up with your own approach, code it up and use it.
And then the Java approach is obviously directly accessible through the Java interop facilities; perhaps not all of it at this stage, but enough to give one's code quite a Javaish smell if one so desires.
On Feb 11, 1:46 pm, HB <hubaghd...@gmail.com> wrote:
> Since Clojure is a LISP dialect, does this mean that it doesn't > support OOP?
Careful not to come to the conclusion that if something's a Lisp, it's not OOP. For instance, Common Lisp has a powerful OOP system which includes multiple-inheritance, metaobject protocol, and so forth. http://en.wikipedia.org/wiki/Common_Lisp_Object_System
The world is a bit upside-down. I suspect people would look at me strangely if I claimed that C++ wasn't seriously OOPish. However, Alan Kay claimed:
As for Clojure, Rich Hickey claims it's not OOP. I guess he means this: Instead of modelling me as an object whose internal state changes as I change (from moment to moment), you instead model me as a reference which points to a different immutable value as I change. That is, I'm a different person from the one a few seconds ago; just that my identity points to the most recent version of me.
(As a software optimization, those immutable versions may share significant structure.)
This means that if you took a snapshot of me (an immutable value), that snapshot won't change. You'll just have an old version of me. But in a traditional OOP language, if you had a pointer to my object, that object could be updated willy-nilly by other threads; you'd need to make a threadsafe deep copy of me or something, to have an immutable snapshot.
I hope I grok the Clojure Way well enough that my explanation is right. http://clojure.org/state
Incidentally, you could create your own OOP system on top of Clojure, if you wish.
On Thu, Feb 11, 2010 at 4:46 AM, HB <hubaghd...@gmail.com> wrote: > Hey, > Since Clojure is a LISP dialect, does this mean that it doesn't > support OOP? > Thanks.
