Hacker News Reader

I personally think how clojure has been presented so far is its greatest strength and it is the reason why it is so strong so far and why it continues to get stronger. You have to be a better than average programmer, one who has worked with multiple languages from multiple paradigms, who has worked with real production code before, to recognize why it is so much superior to any other programming language currently available right now.

I'm GLAD that there is currently no killer app for Clojure, like how Rails became the killer app for Ruby. IMO Rails killed Ruby. Ruby started out in the right direction but once Rails became popular there was an influx of so-so programmers who started polluting the language with inefficient concepts, constantly reinventing the wheel poorly because they did not know enough computer science to know that a better solution had already been invented. Now the system has been bogged down by so much cruft, it is difficult to see if it still serves the purpose it was originally designed for (a language the people can enjoy programming in).

Clojure is not ready yet. The core team is still working on refining the fundamentals for what maybe can become the 100 year language [http://paulgraham.com/hundred.html] -- look at reducers in 1.4. Right now Clojure doesn't need more people. It needs more smart people. If you are not smart enough to understand why it is worth switching to it, maybe you should wait a bit and let the design mature more. The killer apps will come. Clojure's ability to scale complexity will eventually overcome its current drawbacks, as the tools and the ecosystem matures.

Some of us have been "marketing" Clojure for a number of years now. :-)

The results from the last two years of the survey (e.g. 2011's are here: http://cemerick.com/2011/07/11/results-of-the-2011-state-of-...) might be illuminating for you.

Clojure has a ton of compelling use cases, but it's stubbornly not going to fit into the shoebox of a single domain. Thus, it's going to be hard to say, "Clojure is great because it allows me to address narrow problem X". It's a general-purpose language, and increasingly, a multiplatform/multienvironment one as well.

Also, only ~7% of the respondents to last year's survey came from a Lisp. Most come from Java, Ruby, or Python. Make of that what you will re: Clojure's "weirdness".

Yes Chas, you're definitely no stranger in the Clojure community :) (I watched your O'reilly webcast btw).

I'm not saying that Clojure should address a narrow problem but if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection, nice standard library, and the promise of WORA (albeit lots of hiccups here and there). By real I mean something that people can see and immediately take advantage of.

I'm sure there are always going to be alpha-nerds who love to try new programming languages out there (especially the hip ones) but when these people are to write Clojure code or to build Clojure tools, they tend to bring their old habit from the previous language, which in turns make their code look like the previous language as opposed to something totally new, probably refreshing, or even have the potential to blow people's mind.

> if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection

Perhaps the problem is that it's hard to explain referential transparency, or that the problems caused by the lack of referential transparency are less obvious than those caused by the lack of GC. I mean, I've never heard of someone reading through "Out of the Tarpit" and then saying, "why bother with something like Clojure?"

(If you watched the O'Reilly live webcast, then give this a try: http://cemerick.com/2012/05/02/starting-clojure/)

Riffing on what technomancy said nearby, a lot of the issues that Clojure addresses are so taken for granted in most of the broader software development world, that it can be challenging to wrap up its benefits into a tasty, easily digestable nugget comparable to "Java gets rid of malloc and pointers" (sorta). Some have taken some whacks at doing just this, including Paul DeGrandis' talk you linked to already, as well as "Neal Ford's master plan for Clojure enterprise mindshare domination": http://blip.tv/clojure/neal-ford-neal-s-master-plan-for-cloj...

That said, the benefits of immutability and pure functions are generally obvious to any reasonably-capable programmer (my personal bias shone forth) given 10 minutes in front of a whiteboard. Can we get the, say, 10 million Java developers to sit still long enough for that? No, probably not. Maybe a tenth of them eventually, maybe. And, if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it.

A more interesting question to me lately is, what is the objective of language evangelism? Let's set aside any notion that Clojure will be "the next Java", or even achieve the same penetration as Python or Ruby. For those of us that use the language, none of those goals are particularly important. "How many developers use language X" used to be a critical question when the language you used largely delimited the reach of your eventual application/system/whatever; that is hardly the case anymore. I can write my server side in literally anything, and transpiling to JavaScript or C for client side as necessary is either within reach, or a solved problem depending on your preferred language.

So, what should be the objective? Having a large enough pool of talent to meet business objectives is the only thing I can think of that is an actual potential blocker. I know lots of people that know Clojure that would like to work in Clojure, and there are more people like that every day. Seems like the vector is trending positive; we only need to make sure it stays that way.

(This leaves out the enterprise guys to a certain degree, but that's largely due only to their [and their managers'] self-inflicted risk profile.)

Finally, I leave you with this:

http://www.indeed.com/jobanalytics/jobtrends?q=clojure%2Chas...

Note that those are absolute trendlines, not growth. You can very reasonably say that Clojure is the most in-demand functional programming language. (…for some definition of 'functional programming language' ;-)

I can't help but respond:

http://www.indeed.com/jobtrends?q=java%2Cclojure%2Chaskell%2...

Having any "most in-demand functional programming language" seems to be a bit silly. In the larger view, there simply isn't any demand.

I REALLY want this to change. I think if Clojure can make some inroads to the enterprise, there will be trickle-down effect that will help increase opportunities to work in Clojure. I think increasing working opportunities is what language evangelism is for.

As a hacker who loves the repl, functional programming, weird languages, and was at the first Clojure/conj, it is not clear to me at all that immutability and pure functions are wins in general - lots of excellent working systems are out there that don't bother using this stuff at all (no silver bullet is kind of what I am driving at). I might instead argue that in the hands of good-to-great hackers, that immutability and pure functions offer some benefits that are hard to quantify when you normalize across raw hacker abilities.

PS - Thanks so much for the book. A large part of Clojure's success is directly attributable to the high quality and number of books that have popped up so soon in its life as a programming language.

In truth, I hate these Indeed charts…but then, I started it, eh? Live by the sword and all that.

Some additional perspective: http://www.indeed.com/jobtrends?q=java%2Cruby%2Cpython%2C%22...

The Java market is massive. Nearly everything else is essentially background noise compared to it. I'm skeptical that any single language will ever have the same reach as it.

Runtimes, on the other hand, are a different story. The JVM, standardized JavaScript engines, even the CLR/Mono to some extent: polyglot sandboxes where you have the leverage to use whatever language will get the job done. That's a huge win for, as you put it, good-to-great hackers, trying to find the edge of what's next.

'course, that's a wash to a loss (i.e. increased risk) for those with the enterprise mindset. Thus, Java 8 with its closures may very well consolidate its position in such environments.

Glad you enjoyed the book, BTW. :-)

TPS reports rule (I know it's really below the belt) . . .

http://www.indeed.com/jobtrends?q=sql%2Cjava&l=

I had not thought deeply about runtimes in relation to this question. It's certainly true that one reason I can hack around in Clojure and count on that code running on our production servers is that the JVM is ubiquitous there. Quite a different story than when I was doing some stuff in SBCL and had to compile it in my user space.

"if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it"

Unnecessary (if slight) nastiness directed towards (developers choosing) Scala. Unworthy of you (imo). There are significant differences between Scala and Clojure (other than {} vs ()) and trivializing a valid choice of one over another by ascribing it to fear of parantheses (or whatever) isn't a particularly compelling argument.

I've never really noticed Scala devs (leave alone book authors!) throwing darts at Clojure, but have seen the reverse (and at Haskell, on the Clojure mailing list but Rich Hickey shut that down hard and fast, good for him). Sad, and unnecessary (imo).

Scala and Clojure are both awesome and (totally imo) evangelizers of both languages should realize we are all on the same side (again totally imo, feel free to ignore).

Yes there are trolls in all language communities, but I think the expectations about the top developers in each community are (and should be) much higher.

Otherwise, solid comment. And hey, your book is awesome.

Really nice summary, Chas ;). I hope I haven't spoiled the statistics by filling in "just started" - the same response as the last year.

I guess some of us are start over all the time. But at least this time I've read through a half of Clojure in Action and going through 4clojure exercises to "finally get started".

This time using instarepl by Chris instead of LaClojure or Emacs/Slime (where just a tiny subset works for me).

And it's fun! If only errors were not such a drag. I guess complains from 2011 will repeat on those...

On a sidenote, really enjoying your book so far, Chas. I'm really liking the chapter breakdown and sections like the practicums.

Clojure's killer app is managing complexity. This allows you to keep your mental stack clean.

With OO, you have to keep track of the state of each object and how each method affects that state. With Clojure, you don't need to be concerned with the guts of a function, just the inputs and outputs. This keeps your mental stack from building up and makes programs easier to understand and debug.

I strongly disagree with that slogan re: complexity.

Complexity covers so much, its definition so sprawling, that the phrase has no meaning.

I'd rather focus on the language's real strength, fast, concurrenty, portable computation in very well tooled managed environment with a large number of quality libraries.

I don't want to get into a situation where people think that clojure is the universally 'best' language, which is were certain people in the community are.

That POV horribly damaged ruby's popularity after Rails' rise, and I'd hate to see it happen again to another language.

It damaged Ruby's popularity? You feel Ruby hasn't been popular enough the past few years?

While Rails has been a massive success the ruby language hasn't been particularly popular much beyond that.

I'd say python has a more even distribution in terms of use in varied fields for instance.

I disagree; it's very important to talk about complexity. Otherwise, we can't minimize it, and however you define it, it is a problem in software.

You're right, though, the definition is sprawling, so I think it makes sense to use smaller more precise words. The good news is we have some of these: Referential transparency, pure functions, immutability, and neologisms such as "complection". These are very useful, meaningful terms.

Rich Hickey has gone to great lengths to define simplicity and complexity (http://www.infoq.com/presentations/Simple-Made-Easy), and the paper "Out of the Tar Pit" (http://shaffner.us/cs/papers/tarpit.pdf) goes further.

Software projects are becoming increasingly complex, and multicore concurrency is becoming increasingly important. Immutability and referential transparency are key ingredients in Clojure concurrency so I think the slogan is apt.

> Clojure's killer app is managing complexity. This allows you to keep your mental stack clean.

There's a big PR problem with environments that have this as a core strength: it's very hard to demonstrate this without a lot of involvement. It's very hard to demonstrate this with a "hello world." sized experience.

Perhaps I have not pushed OO to the limit but for the most day-to-day tasks I've ever done, OO state is hardly the issue unless you have to write a paper or explain something via state-machine or whatnot.

Request -> App Server -> Processing -> Response -> End, no state lingering around...

I do understand what you're saying but I believe the era of complex OO with states is declining, at least at web-development level...

It's true that Clojure is "weird" because it's a different paradigm. It's not just a different language like Ruby was, it's a different family of languages. It's going to be strange if you aren't already familiar with Lisps and/or functional programming.

To some extent, I don't think any "killer app" is going to change that, although it certainly wouldn't hurt. The concurrency features are pretty compelling in that space already.

Clojure's primary appeal is not, and cannot be, that it's easy for most programmers out there right now. The appeal is that once you learn it, it's a better general purpose programming language that runs on the JVM.

Yes, that seems to be the case: "you need to learn it to believe it". And I hope people take their time to learn it because there seems to be a few articles out there with the message of "I picked up Clojure in a few weeks and re-wrote critical piece of my software in 2 days and it works super-scale".

Maybe that's the power of Clojure?

I really think that it will take a few years before a select few (persistent users, not alpha-geeks) from the Clojure community can come up with some sort of breakthrough that replaces today's best practices, whether it is the replacement of the whole OOP/*DD-movement or the way testing is done, or something else, I don't know. But I do believe that this is what needed.

It's mostly a mental barrier. Clojure isn't inherently hard, at all, it's just different. Once you get the hang of it, you can start reaping the benefits fairly quickly.

Unfortunately, most people judge difficulty in terms of familiarity, so the strangeness is off-putting even if it wouldn't be that hard for them to learn.

Hello Edwin, Clojure appeals to people: who enjoy a Lisp dev style with bottom up repl coding, who need to be on the JVM, and who like some of the neat features of the language (universal seq APIs for collections, mostly immutable data, etc.) BTW, there are some amazing projects built on Clojure - choose an application domain you are interested in and try searching for that domain + clojure

Hi Mark, I'm interested to see Clojure in the LoB type of application. Yes, LoB is boring, but I'd like to see some comparison between the model-heavy/oop-heavy vs Clojure.

Would be nice if the apps show internationalization and some way to handle Time and Money.

Time and Money are handled exactly the same as in Java.

As in using Joda-Time, Joda-Money (or JDK Money)?

Would there be any other way to represent them in Clojure? (i.e.: the more Clojure-way as opposed to use JDK classes?)

Joda Time is actually a great example of a library letting you work in terms of values instead of the mutable object disaster that is java.util.Date; it just happens to be implemented in Java itself.

If you can imagine the same benefits of working with stable values applied across the board to all your built-in data structures, that might help.

Is mixing Java classes in Clojure okay? or to some degree it is acceptable but there are gotchas or the do's and don'ts?

Hey, I checked your website just for fun and it says there you can speak Indonesian, awesome :).

Operating directly on Java classes is pretty standard. Of course you have to be very careful when working with classes which allow mutability, (true in all languages, really) but with Joda that's not an issue.

The only thing you miss out on is that Java methods can't be used as higher-order functions.

My Indonesian is pretty rusty; I should probably update it to say that I understand it rather than speak it. =)