8 ms·

Clojure is a Lisp but also much more: Readable persistent vectors, hash maps, and sets. This is kind of oxymoronic - because those things make it less of a lis

Clojure is a Lisp but also much more: Readable persistent vectors, hash maps, and sets. This is kind of oxymoronic - because those things make it less of a lisp. And to be frank, if you don't think (vector 1 2 3) is readable, then I don't think you really get lisp. Protocols A greenspunning of OO features with a different name because Hickey doesn't get OO (probably never made it through to the bit SICP where you implement objects, or read the "closures are a poor mans object" koan). 90% of the rest of what you list can be found in in various lisps - often all in the same place (racket, common lisp).

iopq 10y ago
What's the point of objects? I don't find myself needing objects when I code in Rust.
- pjmlp 10y ago
  So how do you use Rust without traits?
  - iopq 10y ago
    I use Rust with traits. But I don't have classes or objects.
    - pjmlp 10y ago
      Traits are also OOP, not all OOP == Java. In fact, traits related OO research goes back to Smalltalk variants and Lisp Object Systems.
      - iopq 10y ago
        Traits are more like better interfaces, not classes. Rust doesn't have objects either. It's all structs.
        pjmlp 10y ago
        I know what traits are, both in Rust as well as in language design, better read some SIGPLAN and OOPSLA papers about traits and OOP.
        iopq 10y ago
        I'm asking you to explain how that relates to objects and classes since I use neither of those when I use traits.
        pjmlp 10y ago
        Well, you can start here: https://en.wikipedia.org/wiki/Trait_(computer_programming) https://en.wikipedia.org/wiki/Trait_(computer_programming) "a trait is a concept used in object-oriented programming, which represents a set of methods that can be used to extend the functionality of a class." Then follow on protocols as an idea of generic interfaces https://en.wikipedia.org/wiki/Protocol_(object-oriented_programming) https://en.wikipedia.org/wiki/Protocol_(object-oriented_prog... Then travel back in time to 2003 and read the European Conference on Object-Oriented Programming (ECOOP) paper "Traits: Composable Units of Behaviour" for a possible view on traits long before Rust was born. The way programming languages do information hiding, polymorphism, method/function dispatch, data modelling is also part of OOP and there are several ways to combine them. OOP is so much more than just plain objects and classes.
        tatterdemalion 10y ago
        The implementation of traits described in that paper is totally different from the implementation of traits in Rust. Rust has adopted an ontology and syntax familiar to programmers in object oriented programming to make accessible a form of polymorphism which is quite different. In fact, the same concept exists in Haskell, where it is called "type classes." (In this case, I think the adoption of OO terminology is harmful to comprehension, rather than helpful). Are we to believe that Haskell is object-oriented also? Is there a language with polymorphic abstraction that is not object-oriented in your formulation?
  - tatterdemalion 10y ago
    What is your definition of "object system"? I'm afraid it seems open enough to include any system for polymorphism. (As an aside: I am the author of several Rust trait RFCs & I have read "Traits: Composable Units of Behaviour," though "How to make ad-hoc polymorphism less ad-hoc" is more relevant to Rust. Your smugness about this toward the other poster is not appreciated.)
    - deleted 10y ago
      [deleted]
    - lacampbell 10y ago
      > Your smugness about this toward the other poster is not appreciated. I don't see him being smug at all. Is it smugness to suggest reading material to someone when they've shown ignorance of a topic? People do that to me here often from time to time and I don't interpret it as "smugness".
      - iopq 10y ago
        I don't see any links to the relevant material, just namedropping
      - tatterdemalion 10y ago
        It is when you make the recommendation in a tone which is didactic, patronizing, and superior. That's the definition of smug (I've also found your comments somewhat smug).
        lacampbell 10y ago
        If you find it smug that's really your problem. It's a bit tiresome to see people talking about OO when they haven't educated themselves about OO at all. Which is probably why I don't like Rich Hickeys talks, incidentally.
    - pjmlp 10y ago
      My definition is the same as the CS literature expressed in SIGPLAN, OOPSLA and ECOOP papers, written by people doing OOP language research since the mid-70s. No need to invent my own. As for the other poster, sorry if it appears like that. I did not offended anyone and provided information where to read more about trait systems. HN comments are not big enough to provide an history of OOP systems, their similarities and differences.
- lacampbell 10y ago
  The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. I regard rusts structs + traits as an object system. But I understand why they chose to not mention objects at all - they don't want to conjure up images of Java boiler plate and heavy mutation, which is sadly what it means to most people now.
  - deleted 10y ago
    [deleted]
  - iopq 10y ago
    > I regard rusts structs + traits as an object system I don't regard them as an object system because they are à la carte, while objects tie data and behavior together
    - lacampbell 10y ago
      à la carte in what sense? I feel like data and behaviour is very much tied together in a rust struct. With the right visibility modifiers it can be completely opaque - it's literally a black box you are sending messages to. The methods are attached to the object in my mind. But I am by no means a rust expert. I'm curious is to why you think the data and behaviour are not tied together.
      - iopq 10y ago
pjmlp 10y ago
Protocols are already in CLOS.
cutler 10y ago
Hickey doesn't get OO? You obviously aren't familiar with is work as he makes it clear that he worked professionally with OO in Java and C++ on large projects for more than 10 years before working on Clojure.
- lacampbell 10y ago
  Does working in two pseudo OO Languages for 10 years make you an expert in OO? In one of his talks he mentions that he ended up writing java in such a way that all his classes were static ones. Again, he clearly hadn't figured out that instantiating an immutable object is a way of partially applying multiple related functions at once. A brief look at this site for the other "OOFeatureButNotOOBecauseItHasADifferentName" finds this gem Clojure multimethods are a simple yet powerful mechanism for runtime polymorphism that is free of the trappings of OO, types and inheritance. This guy just doesn't get it and I am tired of him being held up as an authority.
  - cutler 10y ago
    Neither he nor I ever claimed he was an OOP expert. I was merely defending him from your accusation that he doesn't get OOP at all. I think it's the other way round - maybe you don't get Rich Hickey's innovative contributions. Clojure is a reaction against the OOP approach in general, not limited to the implementations in Java and C++. If you'd followed his work you would have noticed that many times he defines the OOP problem as the conflation of data and functions. Tying up data and methods in classes and objects creates complexity which Clojure was designed to untangle. In that he has succeeded where CL failed. Clojure is arguably the first lisp to gain mainstream adoption and for that alone Rich Hickey deserves the respect of all lisp/scheme advocates.
keymone 10y ago
> those things make it less of a lisp those things make it convenient lisp.
- lacampbell 10y ago
  If you're unwilling to let go of your pre-conceived notions of what syntax is supposed to be, sure. I find clojure code really ugly, like it secretly wants to be javascript but can't commit to it. Pure s-expression code is very pleasing on the eyes once you get used to it.
  - keymone 10y ago
    If you're unable to let go of biases formed by previous experiences - why should i listen to you? I find clojure code really beautiful, like by letting go pre-conceived notions of "everything is a list" had really unleashed the power of concise, immutable and predictable data structures. Pure s-expression code puts unnecessary mental strain on a developer because a multitude of semantics is attached to single kind of parens without any practical or pragmatic reason to do so, as if early lispers didn't have other kinds of parens or didn't have other useful data structures and subsequently a need to denote them concisely.
    - lacampbell 10y ago
      These just sound like complaints from a typical novice to LISP. LISP syntax is made of nested lists (an AST) and atoms. Representing sequential types as atoms with ugly reader macros based on the implementation of said sequential types strikes someone who knows a real LISP language as an ugly and ignorant thing to do. If you find real LISP code unreadable because it doesn't look like javascript - because you can't tell when your sequence is a linked list or an array when there's no curly braces - I suggest learning to read and write LISP code and understand how LISP works. A real LISP I mean, not clojure. Again, other LISPs have data structures aren't from linked list. A complete myth that that they only use linked lists.
      - 10y ago

iopq 10y ago

What's the point of objects? I don't find myself needing objects when I code in Rust.

pjmlp 10y ago
So how do you use Rust without traits?
- iopq 10y ago
  I use Rust with traits. But I don't have classes or objects.
  - pjmlp 10y ago
    Traits are also OOP, not all OOP == Java. In fact, traits related OO research goes back to Smalltalk variants and Lisp Object Systems.
    - iopq 10y ago
      Traits are more like better interfaces, not classes. Rust doesn't have objects either. It's all structs.
      - pjmlp 10y ago
        I know what traits are, both in Rust as well as in language design, better read some SIGPLAN and OOPSLA papers about traits and OOP.
        iopq 10y ago
        I'm asking you to explain how that relates to objects and classes since I use neither of those when I use traits.
        pjmlp 10y ago
        Well, you can start here: https://en.wikipedia.org/wiki/Trait_(computer_programming) https://en.wikipedia.org/wiki/Trait_(computer_programming) "a trait is a concept used in object-oriented programming, which represents a set of methods that can be used to extend the functionality of a class." Then follow on protocols as an idea of generic interfaces https://en.wikipedia.org/wiki/Protocol_(object-oriented_programming) https://en.wikipedia.org/wiki/Protocol_(object-oriented_prog... Then travel back in time to 2003 and read the European Conference on Object-Oriented Programming (ECOOP) paper "Traits: Composable Units of Behaviour" for a possible view on traits long before Rust was born. The way programming languages do information hiding, polymorphism, method/function dispatch, data modelling is also part of OOP and there are several ways to combine them. OOP is so much more than just plain objects and classes.
        tatterdemalion 10y ago
        The implementation of traits described in that paper is totally different from the implementation of traits in Rust. Rust has adopted an ontology and syntax familiar to programmers in object oriented programming to make accessible a form of polymorphism which is quite different. In fact, the same concept exists in Haskell, where it is called "type classes." (In this case, I think the adoption of OO terminology is harmful to comprehension, rather than helpful). Are we to believe that Haskell is object-oriented also? Is there a language with polymorphic abstraction that is not object-oriented in your formulation?
- tatterdemalion 10y ago
  What is your definition of "object system"? I'm afraid it seems open enough to include any system for polymorphism. (As an aside: I am the author of several Rust trait RFCs & I have read "Traits: Composable Units of Behaviour," though "How to make ad-hoc polymorphism less ad-hoc" is more relevant to Rust. Your smugness about this toward the other poster is not appreciated.)
  - deleted 10y ago
    [deleted]
  - lacampbell 10y ago
    > Your smugness about this toward the other poster is not appreciated. I don't see him being smug at all. Is it smugness to suggest reading material to someone when they've shown ignorance of a topic? People do that to me here often from time to time and I don't interpret it as "smugness".
    - iopq 10y ago
      I don't see any links to the relevant material, just namedropping
    - tatterdemalion 10y ago
      It is when you make the recommendation in a tone which is didactic, patronizing, and superior. That's the definition of smug (I've also found your comments somewhat smug).
      - lacampbell 10y ago
        If you find it smug that's really your problem. It's a bit tiresome to see people talking about OO when they haven't educated themselves about OO at all. Which is probably why I don't like Rich Hickeys talks, incidentally.
  - pjmlp 10y ago
    My definition is the same as the CS literature expressed in SIGPLAN, OOPSLA and ECOOP papers, written by people doing OOP language research since the mid-70s. No need to invent my own. As for the other poster, sorry if it appears like that. I did not offended anyone and provided information where to read more about trait systems. HN comments are not big enough to provide an history of OOP systems, their similarities and differences.
lacampbell 10y ago
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. I regard rusts structs + traits as an object system. But I understand why they chose to not mention objects at all - they don't want to conjure up images of Java boiler plate and heavy mutation, which is sadly what it means to most people now.
- deleted 10y ago
  [deleted]
- iopq 10y ago
  > I regard rusts structs + traits as an object system I don't regard them as an object system because they are à la carte, while objects tie data and behavior together
  - lacampbell 10y ago
    à la carte in what sense? I feel like data and behaviour is very much tied together in a rust struct. With the right visibility modifiers it can be completely opaque - it's literally a black box you are sending messages to. The methods are attached to the object in my mind. But I am by no means a rust expert. I'm curious is to why you think the data and behaviour are not tied together.
    - iopq 10y ago

pjmlp 10y ago

Protocols are already in CLOS.

cutler 10y ago

Hickey doesn't get OO? You obviously aren't familiar with is work as he makes it clear that he worked professionally with OO in Java and C++ on large projects for more than 10 years before working on Clojure.

lacampbell 10y ago
Does working in two pseudo OO Languages for 10 years make you an expert in OO? In one of his talks he mentions that he ended up writing java in such a way that all his classes were static ones. Again, he clearly hadn't figured out that instantiating an immutable object is a way of partially applying multiple related functions at once. A brief look at this site for the other "OOFeatureButNotOOBecauseItHasADifferentName" finds this gem Clojure multimethods are a simple yet powerful mechanism for runtime polymorphism that is free of the trappings of OO, types and inheritance. This guy just doesn't get it and I am tired of him being held up as an authority.
- cutler 10y ago
  Neither he nor I ever claimed he was an OOP expert. I was merely defending him from your accusation that he doesn't get OOP at all. I think it's the other way round - maybe you don't get Rich Hickey's innovative contributions. Clojure is a reaction against the OOP approach in general, not limited to the implementations in Java and C++. If you'd followed his work you would have noticed that many times he defines the OOP problem as the conflation of data and functions. Tying up data and methods in classes and objects creates complexity which Clojure was designed to untangle. In that he has succeeded where CL failed. Clojure is arguably the first lisp to gain mainstream adoption and for that alone Rich Hickey deserves the respect of all lisp/scheme advocates.

keymone 10y ago

> those things make it less of a lisp those things make it convenient lisp.

lacampbell 10y ago
If you're unwilling to let go of your pre-conceived notions of what syntax is supposed to be, sure. I find clojure code really ugly, like it secretly wants to be javascript but can't commit to it. Pure s-expression code is very pleasing on the eyes once you get used to it.
- keymone 10y ago
  If you're unable to let go of biases formed by previous experiences - why should i listen to you? I find clojure code really beautiful, like by letting go pre-conceived notions of "everything is a list" had really unleashed the power of concise, immutable and predictable data structures. Pure s-expression code puts unnecessary mental strain on a developer because a multitude of semantics is attached to single kind of parens without any practical or pragmatic reason to do so, as if early lispers didn't have other kinds of parens or didn't have other useful data structures and subsequently a need to denote them concisely.
  - lacampbell 10y ago
    These just sound like complaints from a typical novice to LISP. LISP syntax is made of nested lists (an AST) and atoms. Representing sequential types as atoms with ugly reader macros based on the implementation of said sequential types strikes someone who knows a real LISP language as an ugly and ignorant thing to do. If you find real LISP code unreadable because it doesn't look like javascript - because you can't tell when your sequence is a linked list or an array when there's no curly braces - I suggest learning to read and write LISP code and understand how LISP works. A real LISP I mean, not clojure. Again, other LISPs have data structures aren't from linked list. A complete myth that that they only use linked lists.
    - 10y ago