Re: Ants: Clojure vs. Common Lisp

Discussion in 'Java' started by fft1976, Jun 18, 2009.

  1. fft1976

    fft1976 Guest

    What bothers me a little bit about Clojure's overall philosophy is
    that it uses OOP (in one of the many senses of the term) like the
    "sequence abstraction", etc., but at the same time, it discourages OOP
    (such as creating your own abstractions).

    It feels like biting the hand that feeds you.
     
    fft1976, Jun 18, 2009
    #1
    1. Advertising

  2. fft1976

    jgrant27 Guest

    On Jun 18, 11:15 am, fft1976 <> wrote:
    > What bothers me a little bit about Clojure's overall philosophy is
    > that it uses OOP (in one of the many senses of the term) like the
    > "sequence abstraction", etc., but at the same time, it discourages OOP
    > (such as creating your own abstractions).
    >
    > It feels like biting the hand that feeds you.


    Yes the larger issues of Clojure's philosophy bother me to.

    STM is cool but it comes with it's own issues. There's no silver
    bullet for concurrent programming.
    Pushing the use of STM along with the idealistic but impractical
    purely "functional" use of data structures on programmers, as part of
    Clojure's philosophy, is where I take issue. Let the programmer decide
    what works best for their needs without making too many important
    assumptions for them. That is the Java way.

    There was a more detailed discussion on concurrent/multi-core
    programming regarding "purely" functional languages (Clojure /
    Haskell) vs. Common Lisp here --> http://clozure.com/pipermail/openmcl-devel/2009-May/009516.html
     
    jgrant27, Jun 18, 2009
    #2
    1. Advertising

  3. fft1976

    Rich Hickey Guest

    On Jun 18, 4:45 pm, jgrant27 <> wrote:
    > On Jun 18, 11:15 am, fft1976 <> wrote:
    >
    > > What bothers me a little bit about Clojure's overall philosophy is
    > > that it uses OOP (in one of the many senses of the term) like the
    > > "sequence abstraction", etc., but at the same time, it discourages OOP
    > > (such as creating your own abstractions).

    >
    > > It feels like biting the hand that feeds you.

    >
    > Yes the larger issues of Clojure's philosophy bother me to.
    >
    > STM is cool but it comes with it's own issues. There's no silver
    > bullet for concurrent programming.
    > Pushing the use of STM along with the idealistic but impractical
    > purely "functional" use of data structures on programmers, as part of
    > Clojure's philosophy, is where I take issue. Let the programmer decide
    > what works best for their needs without making too many important
    > assumptions for them. That is the Java way.
    >
    > There was a more detailed discussion on concurrent/multi-core
    > programming regarding "purely" functional languages (Clojure /
    > Haskell) vs. Common Lisp here -->http://clozure.com/pipermail/openmcl-devel/2009-May/009516.html


    A language comes with some data structures. Each is either immutable
    or not (they can't be both!). Clojure's providing some immutable data
    structures is no more it 'deciding for' or 'pushing' the programmer
    than is Common Lisp's decision to provide mutable ones (and no,
    choosing not to mutate a mutable data structure does not convey the
    benefits of an immutable persistent data structure - you can't make a
    cheap copy, you can't trust it won't be accidentally modified once
    shared, the optimizer can't leverage the immutability etc).

    If you want to program with mutable data structures, locks, etc with
    Clojure you certainly can. In fact, if you want to use Clojure's
    sequence library with mutable data structures you can. Can I use CL's
    sequence library with immutable data structures? No - it is hardwired
    to the (very few) mutable ones CL comes with. How is that letting the
    programmer decide?

    Rich
     
    Rich Hickey, Jun 18, 2009
    #3
  4. fft1976

    jgrant27 Guest

    > A language comes with some data structures. Each is either immutable
    > or not (they can't be both!).


    Haskell (a 'purely' functional language) has mutable and immutable
    versions of the same data structures :
    e.g. Data.Array.MArray vs. Data.Array.IArray
    http://hackage.haskell.org/packages/archive/array/0.1.0.0/doc/html/Data-Array-MArray.html#7
    Also, for immutable/mutable arrays in Haskell there are functions to
    convert/copy between each kind.
    See freeze, unsafeFReeze, thaw and unsafeThaw.
    The GHC compiler also does the write kinds of optimizations('cheap
    copies') between certain pairs of array types.
    All this allows the programmer to make the decisions.

    > (and no,
    > choosing not to mutate a mutable data structure does not convey the
    > benefits of an immutable persistent data structure - you can't make a
    > cheap copy, you can't trust it won't be accidentally modified once
    > shared, the optimizer can't leverage the immutability etc).


    All this can be implemented in CL (but convention goes a long way
    instead).
    As for STM, there are libraries (and not part of the language) for
    this --> http://common-lisp.net/project/cl-stm/doc/Examples.html#Concurrent_0020counter


    -Justin
     
    jgrant27, Jun 19, 2009
    #4
  5. fft1976

    Paul Rubin Guest

    jgrant27 <> writes:
    > Pushing the use of STM along with the idealistic but impractical
    > purely "functional" use of data structures on programmers, as part of
    > Clojure's philosophy, is where I take issue. Let the programmer decide
    > what works best for their needs without making too many important
    > assumptions for them. That is the Java way.


    Replace the acronym "STM" with "GC", and "functional use" with
    "automatic management", and we heard the exact same song about C
    vs. Java.
     
    Paul Rubin, Jun 19, 2009
    #5
  6. fft1976

    jgrant27 Guest

    On Jun 18, 5:45 pm, Paul Rubin <http://> wrote:
    > Replace the acronym "STM" with "GC", and "functional use" with
    > "automatic management", and we heard the exact same song about C
    > vs. Java.


    C and Java are imperative languages. We're talking about functional
    languages here, either 'pure' or 'impure'.
    This is a critical difference. STM with imperative languages means
    that we are dealing with mutable data structures while in functional
    languages we may or may not be dealing with mutable data structures.

    STM is a good tool in many situations where we want to perform
    concurrent programming WITH MUTABLE TYPES. The whole point of using
    STM is to read/write something safely and so immutable data structures
    don't add much value here. Even in the Haskell 'purely functional'
    camp which has been around a while, there are many valid reasons that
    they have Monads, immutable/mutable data structures and ways to modify
    them. Things are usually immutable in Haskell by default but that does
    not mean state cannot be changed, just that when it's done it's
    explicit.

    Of course there are many other valid uses for immutable data
    structures too but why are they required with STM in Clojure ? If we
    use immutable data structures in Clojure then why do we need STM at
    all ?
    In Clojure they are probably required because there are layers of type
    systems. The Clojure types(immutable) live on top of Java types
    (mutable). Then there is also the Java interop ability of Clojure
    which means that STM does have value because we could be dealing with
    mutable Java types. This is a bizarre mix to have to keep in mind when
    trying to write software (let alone concurrent software).

    If STM is being used for concurrent programming then the argument for
    immutable types only seems to lose weight more quickly in Clojure(or
    any other language). Optimization hints, 'cheap copies' (just
    pointers ?) and ensuring no accidental changes with mutable data
    structures is easy enough. C has it's 'const', Java has it's 'final'
    keyword, Lisp has defconstant etc etc.


    -Justin
     
    jgrant27, Jun 19, 2009
    #6
  7. fft1976

    Scott Burson Guest

    On Jun 18, 2:19 pm, Rich Hickey <> wrote:
    >
    > If you want to program with mutable data structures, locks, etc with
    > Clojure you certainly can. In fact, if you want to use Clojure's
    > sequence library with mutable data structures you can. Can I use CL's
    > sequence library with immutable data structures? No - it is hardwired
    > to the (very few) mutable ones CL comes with.


    Not if you use FSet :)

    (I know you know that -- I just couldn't resist the opportunity to
    plug FSet :)

    -- Scott
     
    Scott Burson, Jun 19, 2009
    #7
  8. fft1976

    jgrant27 Guest

    On Jun 19, 1:27 am, Jon Harrop <> wrote:
    > jgrant27 wrote:
    > > Let the programmer decide what works best for their needs without making
    > > too many important assumptions for them. That is the Java way.

    >
    > Nonsense. Java is the OO+generics way or the high way.


    You either misread this or I should have phrased it better, I actually
    agree with you.
    The Java way assumes that the Java language designer knows best and
    will make many assumptions for the Java programmer.
    I have always had a problem with this.
     
    jgrant27, Jun 19, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jy
    Replies:
    1
    Views:
    342
    Anders =?iso-8859-1?Q?Engstr=F6m?=
    Sep 11, 2003
  2. ekzept
    Replies:
    0
    Views:
    386
    ekzept
    Aug 10, 2007
  3. Developer

    Fire Ants

    Developer, Sep 11, 2008, in forum: HTML
    Replies:
    1
    Views:
    488
    stermen
    May 22, 2009
  4. Developer

    Fire Ants?

    Developer, Sep 11, 2008, in forum: C Programming
    Replies:
    2
    Views:
    406
    Keith Thompson
    Sep 11, 2008
  5. Brian Schröder
    Replies:
    4
    Views:
    106
    Brian Schröder
    Sep 29, 2004
Loading...

Share This Page