Hacker News Reader

Comment by drcode | Hacker News Reader

The reason Clojure is successful right now IMHO is because:

    1. It isn't afraid to revisit the basic design tenets of Common Lisp and Scheme
    2. It has reasonably useful libraries (both through the JVM and written in native Clojure)

No other Lisp dialect has done this recently. My point is that its success doesn't have much to do, from what I can tell, with the actual design of the language. Clojure does fix annoyances in CL and Scheme (low hanging fruit) but I personally still prefer other modern dialects, like arc, in terms of basic language design.

The reason arc is crashing and burning right now is that it doesn't address #2 at all. Plus, arc is suffering from an absentee benevolent dictator.

View on HN

its success doesn't have much to do, from what I can tell, with the actual design of the language

Of course it does. "Revisit[ing] the basic design tenets of Common Lisp and Scheme" is actual language design. Moreover, "fixing" CL and Scheme is not "low hanging fruit". It's a hard thing to do, and most people who try make a mess of things.

Moreover, "fixing" CL and Scheme is not "low hanging fruit". It's a hard thing to do, and most people who try make a mess of things.

I agree here. Most people think fixing CL means making "let" use fewer parenthesis. (Clojure does this.)

Anyone that has used Lisp for more than 30 seconds knows that this is not a particularly worthwhile change. More syntax characters just to save two characters in a let binding? No thanks.

(BTW, you can always use destructuring-bind instead of let -- (destructuring-bind (foo bar baz) '(1 2 3) ...). There, you saved some parens!)

Honestly, Clojure doesn't sit really well with me. It tries to be different from both CL and Scheme simply for the sake of being different, which is pretty annoying. For example, look at the "definers". In CL, the scheme is pretty simple -- defun, defvar, defgeneric, defmethod, ... In Scheme, "define" is polymorphic, so it's all you ever need. In Clojure, the "definers" are just random words; def/defn, etc. Oh boy, we saved 3 characters! I am going to be so much more productive now!

Anyway, I will stick to CL for now.

The syntax changes are a very minor part of what "fixing" CL/Scheme means. Clojure makes some serious semantic changes.

For instance, data structures are immutable (not setq). If you need state, you have to use the software transactional memory system. These two features combine to make Clojure very safe for concurrency.

Clojure also uses sequences as it's primary object, which are more like "immutable" python generators than lisp lists.

Take a closer look, Clojure is actually quite nice.

I guess my point is that I wish it only made semantic changes and not syntactic change, or that I could easily turn off the odd syntax.

> its success doesn't have much to do, from what I can tell, with the actual design of the language.

Wow, really? This seems way off base to me. The only reason I care about Clojure is 'persistent' data structures that give us some chance of writing code that /just, maybe, possibly/ will execute usefully on the 1024+-core boxes we're going to be using shortly. That's the only reason I care about it, and I'd say that's fundamentally the design of the language.

Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They're not the critical ingredient if you're trying to make something to last; they may even hurt.

Libraries are just one aspect of it. Clojure's already got an excellent VM and a sound programming model to deal with concurrency.

How could it hurt a language's lasting power for it to have powerful libraries?

Do you mean that it might hurt Clojure specifically, because it relies on Java's libraries in particular? Or was it a more general point?

It was just a general point. I don't know anything about Clojure.

The dangers of libraries are that they distract one's attention from the core language, and that they could conceal or perpetuate flaws in the core language.

I'm not saying that languages shouldn't have powerful libraries, btw, just that they may not be 100% upside.

I think it's unfortunate you haven't even looked at Clojure. If you did, it's possible both languages could benefit. While I am a fan of the JVM, one downside of the language is that compromises were needed to work nicely on the JVM. Besides that, Clojure has many features that make programming in it great for experimentation (and large-scale), and I don't see those features in Arc. If Arc had immutability, threading, STM concurrency, lazy functions, and literal data structures, but without the JVM compromises and with the 100-year goal, it might be more interesting to me and others. I looked at Arc when it first came out, but the homepage still doesn't spell out what makes it worthwhile other than "brief and malleable".

Yes, but without powerful libraries a language isn't much good for real world use. And if nobody uses the language it won't have a community and feedback. Without a community people will move on, and it will end up as a pet project.

There are two senses of powerful: breadth and depth. To make a language massively popular you need breadth. But for a language to have a user community all you need is depth, which is why I released news.arc with Arc.

This post just seems to be begging for comment ~ maybe it's because it's relatively rare that we get pg talking about arc.

they may even hurt.

I'm assuming you are referring to the maintenance and backward compatibility that is required as soon as you have libraries. Plus good libraries can be had even in bad languages - so it's not a good reflection of the language. Are you suggesting libraries should be a completely separate project with potentially many choices? The problem with this can be seen in Scheme. It's hard to move from project to project (job to job) when they use different implementations and those related libraries. Learning the related core libraries is often not worth it; if the scope of the project is small. Invariably libraries do not transfer well - maybe that is the problem that needs to be solved... Even with formalities like R5RS or R6RS core libraries are still implementation specific.

Plus, arc is suffering from an absentee benevolent dictator.

... You are missed over at the arclanguage forums. (http://arclanguage.org/item?id=8462) Specifically some direction for those of us that enjoy writing arc would be great. There are plenty of people that know and write arc - why not put them to work. What is your opinion of the community version of arc (http://github.com/nex3/arc/tree/master)? Do you use it? Is it blasphemy? Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?

> Is this all just a giant social experiment to see what will happen to the language and community given no leadership and x-number of years?

It's pretty clear already: arc has failed.

arc has failed

Failed at what, exactly? Being a toaster?

You guys all seem to be projecting your own expectations about "language and community" onto Arc, none of which have to do with the stated goals of the project. What part of making-a-better-Lisp-where-better-mostly-equals-shorter-programs don't you understand?

Failed at being a hundred year language. Arc programs are shorter, but only by a constant factor due to small syntax enhancements. It doesn't provide interesting new abstractions like Lisp did.

To make the statement that arc has failed with credibility, you'd need the following:

1. A completed version of arc 2. 100 years since 1.

Like which Lisp did?

the original

What about the design of Arc do you prefer over Clojure?

Number 2 is the killer feature in my opinion. Leveraging a humongous, popular, and mature set of libraries that the JVM gives makes Clojure stand out, and is probably why it's getting so much attention. The "real world" usually favors languages with "batteries included".

If that were true, Kawa and SISC (good Scheme compiler and interpreter for the JVM, respectively) would already have grabbed that attention.

It's too early for libraries to be built on a language that is still in the experimental stage.

While I enjoyed writing arc code, I'm in no hurry to see a huge infrastructure pop up around the language as it stands. What's the rush? Let pg and rtm take whatever time they need to build a language they are happy with.

> Let pg and rtm take whatever time they need to build a language they are happy with.

Yeah, pg and rtm can do whatever they want. Meanwhile, I want a language I'm happy with.

I guess you could choose a different language, provide ideas to enhance arc, or design your own...

Reply on news.ycombinator.com