Hacker News Reader

Comment by adrianm | Hacker News Reader

Clojure is not just a Lisp on the JVM. Clojure is a Lisp but also much more: Readable persistent vectors, hash maps, and sets. Protocols, records, and anonymous (reified) instances of protocols/interfaces. Sequences as a common unifying and extensible abstraction for iteration. Transients, transducers, multimethods with ad-hoc and extensible hierarchies. Namespaces and vars with metadata. Atoms, Agents, Refs, and the STM. Reducers and fork-join. AOT compilation to Java bytecode along with dynamic loading of any code. Now clojure.spec and more, and this is just stuff built into the language.

View on HN

All of those could have been and a lot of them are libraries in the CL ecosystem though(with varying degrees of quality unfortunately). I feel the reason clojure is a separate language at all is because it would be pretty hard to get a lot of non-lispers interested in a collection of lisp libraries, while getting them to try a new language especially on a familiar platform is relatively easier, especially if you are a talented speaker like Rich and some of the other early clojure adopters.

Other reasons might include the fact that the CL ecosystem in late 10 years ago was light-years behind what it is now. And of course people have an irrational repulsion to some characteristics, like the reader upcasing all symbols by default, which has caused me 0 problems other than the fact that I though it was weird in the beginning.

No disrespect to clojure, it probably got a lot of people interested in common lisp and scheme as a result of existing, but that's my view of things.

Most of those features were already present in Common Lisp in the mid-80's.

The main advantages of Clojure are the libraries from JVM/.NET, having a few parenthesis replaced by square brackets and charismatic community speakers like Rich and David.

> The main advantages of Clojure are the ...

I'd argue the main advantage is the consistent focus on making pragmatic engineering decisions and the focus on building a community who are equally pragmatic.

I've got a bunch of Clojure apps that I wrote ~5 years ago that still work on the latest version of Clojure with the latest libraries. That is pragmatic engineering.

Cursive, the Clojure IDE built on top of IntelliJ, is an amazing bit of work when you consider it is written by one guy. Again the clever use of leverage.

A focus on everyday immutability and easily reasoned concurrency makes building and reasoning about medium sized applications much easier.

Etc etc.

For a language not backed by an industry titan it has done an amazing job.

Sure when you look at something like spec there isn't a whole lot of "secret sauce" - almost all of it has been done before (I remember the big Microsoft push for runtime contracts over a decade ago). Despite this I predict it will have a huge impact on overall codebase quality.

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).

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

So how do you use Rust without traits?

I use Rust with traits. But I don't have classes or objects.

Traits are also OOP, not all OOP == Java.

In fact, traits related OO research goes back to Smalltalk variants and Lisp Object Systems.

Traits are more like better interfaces, not classes. Rust doesn't have objects either. It's all structs.

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.

I'm asking you to explain how that relates to objects and classes since I use neither of those when I use traits.

Well, you can start here:

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_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.

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?

Yes Haskell type classes are interfaces from OOP point of view.

And given time on the weekend I might try to find out the talk given by SPJ about this very issue.

Polymorphism and dynamic dispatch are part of OOP.

EDIT: Found Simon's talk

Adventure with Types in Haskell, part 1 and part 2:

https://www.youtube.com/watch?v=6COvD8oynmI

https://www.youtube.com/watch?v=brE_dyedGm0

At 1:01:01 on the first lecture he discusses how Haskell relates to OOP in regards of subtyping and generic polymorphism and how although different on the surface they share those CS concepts in their own ways.

https://www.youtube.com/watch?v=6COvD8oynmI&feature=youtu.be...

I've seen SPJ's talk. You might notice that in the moment you site, he says that OO and parametric polymorphism are both polymorphism systems. Rust and Haskell are both parametric systems, not OO systems, in SPJ's formulation (and mine). The slide is literally a venn diagram of the two concepts and the abstractions they can encode.

What is an example of a language with polymorphism you do not consider to be object oriented? I'm not really interested in being linked to media I've already seen, I'm trying to suss out what you think object oriented means. As far as I can tell, it means "polymorphism," and well - yes I think polymorphism is a great idea, but I don't think its what most people mean when they say "object-oriented."

(Also, if Haskell type classes are interfaces, then so are Rust traits. They have the same semantics. But you've already said that Rust traits are traits.)

Again, it might be concepts developed in OOP languages, but I'm still not using objects. I never said I'm not using OOP, which is a stronger claim. I said I'm not using objects.

Yes, but OOP means Object Oriented Programming.

Rust traits are easily modeled in UML, just to add another point to it.

Better stop here then.

Yes, Object Oriented Programming.

Not Object Programming. I'm not using any objects when I write Rust code, even if I'm using concepts from OOP. But yeah, we've both made our point.

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.)

> 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".

I don't see any links to the relevant material, just namedropping

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).

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.

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.

I've been kind of aggressive in response to your comments, because I've found them condescending, but I think what we're actually revealing is that the way you're using "object-oriented" is ontologically discontinuous with the conception of languages derived from their formal semantics as I understand it. Features with the same formal semantics (Rust traits & Haskell type classes), expressed through distinct syntax, can correspond to different concepts in the ontology of languages which object-orientation exists within.

I might be tempted to say that object-orientation has no explanatory value - "it just means polymorphism!" - but I think what's more accurate is to say that its explanatory value operates within a distinct discourse from the discourse I am familiar with.

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.

> 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

à 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.

Because you can have free functions that take plain data. So you can have methods or you can have free functions. This is why it's à la carte - you can choose if you use methods or free functions. You can choose if your data has behavior or not.

Right, absolutely. I am by no means claiming rust is an OO language, just that I would consider the structs + traits thing a way of making objects. I suppose I could have been more precise - it's not an object system by itself but it certainly can be very easily used as one. I think for a systems langauge they did a very fine job in designing that part of it.

I mean, only if you're viewing it from that point of view. A Haskell programmer would just say Rust has typeclasses.

Protocols are already in CLOS.

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.

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.

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.

> those things make it less of a lisp

those things make it convenient lisp.

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.

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.

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.

These sound just like ramblings of typical elitist. If your main concern is to have language that only appeals to other elitists - you'll take that language to grave with you.

Syntax is something novices judge the language by. Their criticism is not always valid, but if language can make concessions that don't undermine it's core values but lower the learning curve - there is literally no reason to not make these concessions. No reasons apart from elitism and purism that is and those are just plain stupid.

Clojure is great example of lisp that is easier to grasp (one of main reason being sane use of data literals) but still remains lisp all the way down to it's core.

I don't know if understanding LISP is really elitism. I don't think it requires some great intellect to get it. I think the key reason people have the attitude against the syntax is because they learned languages that looked a certain way, and to them - that's programming damn it.

I mean LISP syntax is objectively much more simple. I think if you were to sit programming novices - with no pre-conceived notions - infront of an s-expression language and an ALGOL looking one, you wouldn't find much difference on which is easier to learn.

I genuinely think people have difficulty letting go of stuff when they learn LISP. When I first started I thought all the parens were silly as well, and I thought stuff like sweet-expressions [1] were clearly the way forward and it was only those stuffy old elitist scheme programmers who couldn't see it. But over time I saw that the simplicity and regularity of s-expressions made it worth it.

Clojures awkward smashing together of javascriptish syntax into LISP reminds me of nothing so much as training wheels on a bicycle. Sure I suppose you can call those of us who ride a bicycle with two simple wheels "elitsts" and accuse of rejecting "convenience", but to be honest when I see people defending ugly literals and complicating the syntax of a LISP language, I can't help but suggesting that they learn to ride a damn bike.

[1] http://srfi.schemers.org/srfi-110/srfi-110.html

> I don't think it requires some great intellect to get it

yeah, exactly, it doesn't. which makes lisp elitism very awkward.

> LISP syntax is objectively much more simple

things can be too simple, to the point where it is counter productive and harmful. example - why do you need all these weird symbols to represent numbers 1234567890? seems like 1 does the job just fine. unary arithmetic is trivial - just stitch numbers together and you have addition, just repeat them X times and you have multiplication. no need for weird shenanigans with symbols changing because of trivial operations.

> Clojures awkward smashing together of javascriptish syntax

i genuinely think you have difficulty letting go of your biases. all clojure did was designate two more kinds of parens to mean something useful in a language. it's a tradeoff between being pure lisp and being easier to grasp while still remaining lisp. but i can see now, tradeoffs are hard to understand for elitists/purists.

i wonder if every time when you buy a keyboard/laptop you're ripping off those damn [] and {}. because your arguments are unreasonable enough to think that might actually be true.

> > I don't think it requires some great intellect to get it

> yeah, exactly, it doesn't. which makes lisp elitism very awkward.

The thing is, people sometimes use elitism as a synonym for chauvinism, which it isn't.

"Lisp is easy, everyone should use it for everything" doesn't, by itself, meet the definition elitism because it doesn't refer to some small elite group being somehow better than others.

> "Lisp is easy, everyone should use it for everything" doesn't, by itself, meet the definition elitism

agreed.

> Lisp is only pure s-expressions and everybody who can't read them or wants a more 'convenient' syntax are too stupid to understand it

however does meet that definition in my opinion.

Well, too stupid to be computer programmers, that much is true.

That sort of statement is tech elitism, not Lisp elitism. Usually out of frustration when dealing with trolls.

I don't believe that there are any programmers who genuinely can't deal with Lisp syntax at least as well as they deal with any other syntax.

There are only trolls who lie in making that claim, and there are trolling non-programmers who tell the truth.

Simplified syntax is mostly a threat to those who hold mastery of some arcane syntax as their principal intellectual achievement: i.e. advanced newbies.

The fact that exactly the same semantics can be expressed in a syntax that lesser newbies can learn in a day is a big threat to someone who spent months memorizing some syntax, because it means something in which they take pride as a great value is actually worthless "fool's gold".

If you're a professional who does a lot of numeric work with arithmetic expressions, working in S-exps will make you grumble, but you can do it.

i'll just repeat what i've said before - lisp purism is not a valid reason to not adopt data literals for useful data structures. there is nothing inherently worse about [1 2 3] over (vector 1 2 3) in terms of "the lisp idea", but it is order of magnitude easier to work with in terms of ability to scan structure of code.

There is nothing wrong with shorthand notations which don't disturb the surrounding Lisp syntax (don't introduce strange ambiguities and precedence issues into it and so on: and there is room to even do that a little bit).

Lisp has those short-hand notations. There is nothing worse about 'X over (quote X).

The only thing wrong with [1 2 3] -> (vector 1 2 3) is that it's somewhat of an unimaginative waste of these [ ] characters.

i will waste them as i think fit, thank you very much.

As others have mentioned, all of those are in Common Lisp, either built-in or with with libraries readily available in Quicklisp. Quicklisp didn't exist back then, so it wasn't so easy as it is today, but most of the libraries already existed.

Don't get me wrong, I understand the convenience of having all of that built in, minus the crusty parts of Common Lisp, but as far as language features go, I'd say it was evolutionary, not revolutionary.

Reply on news.ycombinator.com