The reducers sound interesting.

The new agent/thread commands sound very interesting:

clojure.core/set-agent-send-executor!, set-agent-send-off-executor!, and send-via

The concurrency primitives have been Clojure's biggest conceptual breakthrough so far, and if they extend that to the automation of thread pools and executors that would amount to building on top of Clojure's greatest strength.

I am less interested in the threading macros (thrush). I dislike the fact that Clojure can, in a sense, be written forwards or backwards. There is a sense of Perl's "there's more than one way to do it" that I dislike.

>I dislike the fact that Clojure can, in a sense, be written forwards or backwards.

If you're referring to the distinction between -> and ->>, it's not about direction preference, but rather that functions that conceptually work on a single subject (e.g., conj, assoc) typically take that subject as its first arg, whereas functions that work on a sequence subject (e.g., map, filter) typically take that subject as its last arg. From that consistency emerges the two different threading macros.

The parent is almost certainly referring to the distinction between:

(-> (initial) a b c d e)

and

(e (d (c (b (a (initial))))))

I find -> and ->> useful, but the new threading operators kind of silly; they're very easy to implement in terms of -> and ->>, or in terms of higher-order functions, and don't really cover all the use cases one would want---it offends my sense of aesthetics to have them (in their particular implementation) added to the core ns.

(-> (initial) a b c d e) is like "The city on the bay in California"

and

(e (d (c (b (a (initial)))))) is like "The Californian bay's city".

These variations are different thematic structures to language.

In my view it's exactly the opposite:

    (-> (california) bay-in city-on) ; "The Californian bay's city"

vs.

    (city-on (bay-in (california))) ; "The city on the bay in California"

The former ("->") starts with what's fed into the pipeline, the latter starts with what you get out of it. In addition, "->" avoids the nesting of expressions regardless of the number of steps, which might be useful in some cases. But both styles have their place.

Use it every day and you'll probably think different about it.

(baz 33 (bar 12 (foo 33 (+ 1 42))))

Is way harder to read than:

   (->> (+ 1 42)
        (foo 33)
        (bar 12)
        (baz 33))

I totally agree and personally love using -> and ->> but I've heard people say that the idiomatic way is to use let instead:

    (let [fortythree (+ 1 42)
          foo33      (foo 33 fortythree)
          bar12      (bar 12 foo33)
          baz33      (baz 33 bar12)]
       baz33)

I understand the logic behind preferring let and a lot of times it really does make things clearer to have everything named and explicit, but especially in prototype code, I find the need to name things to get in the way. I would prefer not naming things over badly named things, for example, and that's usually how I decide between let and thrush (all things being otherwise equal).

There is a lot of stuff in Clojure that can be done in more than one way. I know that Python focuses on "only one way to do it", but Clojure's focus is on simplicity, as defined by Rich Hickey in Simple Made Easy [1], and that is a much better focus. I find that, as Rich says (and I'm paraphrasing), simplicity is by far the most important concern when programming. It dominates all other concerns in terms of importance and payoff. I believe I have become a much better programmer since I learned Clojure and listened to Rich's talks.

[1] http://www.infoq.com/presentations/Simple-Made-Easy

> Clojure can, in a sense, be written forwards or backwards

Clojure can in many senses be written forwards or backwards. By defining this short macro somewhere...

    (defmacro topdown-tale [& stmts]
      `(do ~@(reverse stmts)))

we can write our top-level control statement at the top and the functions it calls underneath, by bracketing with...

    (topdown-tale
    ...
    )

Many languages are subject to such assymetries: at times one writes nested calls, and at others, chained calls.

    a(b(c()))
    a().b().c()

the latter form requires less mental overhead so why not favour it whenever possible?

It's more like c().b().a() which shows there is some "overhead" right there.

I dont think so... c() would be evaluated first which is inconsistent with the other examples

Edit: I realize vemv's examples are inconsistent as well

Here's a good talk from Rich Hickey about the underpinnings, mechanisms, and rationale behind reducers: http://www.infoq.com/presentations/Clojure-Reducers. I highly recommend it.

As he says, it's based off of some concepts from Enumerator/Iteratee, which AIUI originated or was explored initially in the Haskell space: http://www.haskell.org/haskellwiki/Enumerator_and_iteratee. I found Hickey's presentation a lot easier to understand.

For a while it seemed like Clojure was capturing a chunk of mindshare, but now I see more slides and presentations in which people are getting things done with Scala, and the "new hotness" factor has moved to languages like Rust.

Does anyone have an opinion on whether Clojure still has a chance to become a major language with widespread adoption?

Is Rust really capturing mindshare when it's still in Alpha? I've read tons of complaints here on HN over that language.

I think that it's impossible to predict what will be hot or not in the future. You have a zillion frameworks, plug-ins, and languages competing for mindshare, and I ultimately think that no one of these will be 100% dominant. People who like Lisp are going to love working in Lisp no matter what, and those that don't, wont, and it's that simple. You can't expect people who are most comfortable working in Java to move to a Lisp, and you most certainly can't ask a Lisper to do something that looks at all like Java.

I think one thing that will stunt Clojure, is the death of SICP at MIT and Berkely. SICP makes and excellent case for immutability and functional programming, and that knowledge is now more difficult to find and teach. I think the semi-movement from RoR programmers testing out Clojure wasn't going to last, and if people thought that RoR programmers were really going to move to Clojure and make it popular, with its lack of frameworks and anti-OO philosophy, they weren't thinking about the situation too well.

Regardless, Clojure is the only Lisp that currently has a chance for wider adoption, with Heroku and the JVM.

Are MIT and Berkeley still so influential that stopping teaching SICP could affect the future of Clojure, and Lisps in general? MIT and Berkeley grads as a proportion of all programmers is much lower now than it was 10 or 20 years ago.

Also, from what I've seen of Rich Hickey's presentations and speeches he's doing a pretty good job making the case for immutability and functional programming.

Yeah, I think so... It's not so much the idea of the raw number of student who go to those schools, but the thought that other schools look toward them for some direction. If I recall that article from the retired teacher from Berkeley correctly, he used to help other teachers teach SICP and Scheme.

I'm going on the assumption that there is some feedback loop going on here, and that without people actually being exposed to Lisp in school, then there is probably going to be less people even aware of Lisp's existence. I wonder how many schools will drop Lisp completely now after MIT and Berkeley dropped it.

Now, if Clojure looked like Python, I bet dollars to donuts it would be the number one language in use already.

Scala was originally released in 2003, and Clojure wasn't released until 2007. There's your difference, I think. I still see Clojure as having a strong chance of becoming a major language. The language itself is relatively stable now, and the I've noticed the community shift towards making it easier for newcomers to get started and improving documentation.

Interesting point about the relative release dates - I had no idea there's 4 years between Clojure and Scala.

Making Clojure easier for newcomers would be a boon - I've battled with setup and configuration each time I've tried to use Clojure. Having a simple but powerful REPL environment like IPython would be fantastic.

Fastest way to start with Clojure (besides the online REPL at http://tryclj.com) is to get yourself leiningen (the widely used build tool for clojure projects under: http://github.com/technomancy/leiningen) and a plugin/mode for your editor of choice, do "lein new <your project name>" and start a REPL via "lein repl" to get working.

> Having a simple but powerful REPL environment like IPython would be fantastic.

Download and install leiningen (http://leiningen.org) and then you can start up a repl with 'lein repl'.

I wrote a little web app using clojure and when it came to deployment I was really positively surprised:

1) 'lein ring uberwar'

2) copy resulting war file into your tomcat webapps directory

3) you're done

There's also a heroku plugin if you don't like hosting yourself.

Without leiningen clojure is just unusable though. You have to mess with classpathes and wrapping java command line calls in boilerplate.

God, I hope not. It is a great language with amazing data types and features. I personally think evolutionary language design goes in the wrong direction when they are pushed in the directions demanded by a community of trend-seekers.

Clojure has a chance to become a major language among those who do not fear parentheses.

Lisp in any form will never be mainstream. That doesn't mean that Clojure can't establish a survivable niche for itself but it will never be as popular as Ruby or Python, never mind Java.

I also think that fear of parentheses will remain mainstream.

Yes, Indeed.

This is a very sad commentary on humanity.

Language adoption does not happen at a linear rate. Ruby languished for a decade until Rails made it hot. Javascript was a neat toy for years, until cross-browser frameworks, like Prototype and JQuery, made it developer friendly. The revival of Erlang, and Lua, is also very interesting.

English books made Ruby hot. Not Rails. Rails was only possible because Ruby was already gaining enough users and an international community.

I guess the issue with my usage of the word "hot" is its relative measurement of popularity. Just like the original comment's use of "widespread".

IMHO I doubt that any language that is bound to some infrastructure (i.e. jvm) and isn't actively supported by the organization behind that infrastructure will ever become a "major" language. If there were a native clojure interpreter/compiler (or at least multiple implementations following a stable specification of the language & the core library), things would be different, I guess.

I don't know what you mean by widespread. But work on it does not seem to be slowing down, and it is a really good language, so I think it will only grow.

I don't think a functional (or even a dynamic?) language has really made to the enterprise yet so I, for one, don't feel too concerned with that question.

There were also some folks going from Scala to Java...

Change log: https://github.com/clojure/clojure/blob/master/changes.md

I don't really get why we are caring if clojure will spreand or not. Would be cool if everybody asked to make a website in compojure and enlive instead of RoR, but I didn't learn ckojure for that.

Who learn clojure is doing so because it will teach him a new way to think. (Clojure will really change the way you think especially if you come from OOP)

The way in which clojure is build makes very difficult to create a single huge framework and it is not helping. You learn Ruby on Rails to build website, not ruby. (That because a framework, for definition, let you do things in just its way). Clojure do not have frameworks, it has a good number of libraries that you can modulate and use as you wish, there is not just one way to do something (macro...?). (Honestly I believe that it is good, especially if you are the kind of programmer who likes to think).

Then what the 1.5 version is bringing (reducers) are pretty cool IMO, then I see the other macros cond->, cond->>, as->, more like sugar, but I have never used it so I am sure I will be surprised.

> Set and map constructor functions allow duplicates

Awesome, finally!

I detect mild arcasm...