Clojure and OOP
HB
Since Clojure is a LISP dialect, does this mean that it doesn't
support OOP?
Thanks.
Timothy Pratley
> Since Clojure is a LISP dialect, does this mean that it doesn't
> support OOP?
You might find this article interesting:
http://blog.thinkrelevance.com/2009/8/12/rifle-oriented-programming-with-clojure-2
Regards,
Tim.
James Reeves
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. :)
- James
Joel Westerberg
cheers,
/J
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Jeff Schwab
> 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.
Laurent PETIT
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 ...
2010/2/11 Jeff Schwab <je...@schwabcenter.com>:
John Pall
On Feb 11, 8:11 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 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 ...
>
> 2010/2/11 Jeff Schwab <j...@schwabcenter.com>:
>
>
>
> > 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.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@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+u...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en- Hide quoted text -
>
> - Show quoted text -
Michał Marczyk
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.
Sincerely,
Michał
.Bill Smith
how to define OOP, I recommend watching
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey.
Tayssir John Gabbour
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:
"Actually I made up the term "object-oriented", and I can tell you
I did not have C++ in mind."
-- http://video.google.com/videoplay?docid=-2950949730059754521
... and later in that video strongly regrets coining the term, as it
gives the wrong impression.
OOP is a term which can mean many (even conflicing?) things, as
Jonathan Rees discussed:
http://www.paulgraham.com/reesoo.html
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.
All the best,
Tayssir
Richard Newman
> assuming you're going by Dr. Kay's definition. :)
Another Kay quote:
"I invented Object-Oriented Programming, and C++ is not what I had in
mind."
Raoul Duke
Michael Wood
> can we creat threads in clojure?
Yes.
Clojure 1.2.0-master-SNAPSHOT
user=> (Thread.)
#<Thread Thread[Thread-0,5,main]>
But often you would use an agent or pmap etc. instead of creating
explicit threads.
--
Michael Wood <esio...@gmail.com>
Daniel Simms
> support OOP?
Another answer is that ``it could be if you wanted it to be'', for example:
http://s-expressions.com/2009/12/10/frumios-a-silly-object-system-for-clojure/
.