
Why I am so excited about Clojure - llambda
http://technotzen.wordpress.com/2013/06/06/why-clojure-is-the-next-big-thing/
======
tomp
Reasons I believe Clojure will never be successful:

(1) it's a lisp. This is 2013, compilers can deal with +-*/, I don't need to.

(2) it lacks good documentation. Most functions are documented, but badly. In
particular, they lack examples; sometimes they are really tricky to use

(3) it lacks tutorials (on the main page). There is a set of pages that
explain the basic concepts of clojure, such as datatypes, variables and
multimethods/protocols, but they are really terse. I think Clojure assumes you
already know lisp, quote, unquote, syntax trees, defs, vars, etc...

(4) it's full of magic. You can feel it, but you can't really understand it
without digging through the source code.

I know OCaml, can read Haskell, and wrote a small library in closure. I still
find it very hard do get around and very hard to learn.

~~~
RivieraKid
I was quite enthusiastic about Clojure at first, I rally enjoyed experimenting
with it but when the novelty fade off I lost interest because of:

1\. The minimal syntax makes it harder to read than more traditional
languages.

2\. It's uncomfortable to do imperative or object-oriented programming in
Clojure. (Yes, many problems are easier to express in other than the
functional paradigm.)

3\. Using state is not a priori wrong but it's difficult in Clojure.

4\. The parentheses are sometimes annoying, especially when I want to quickly
test something in the REPL.

Some lispers (like Paul Graham) believe in something like "macros make lisp
the most productive language on Earth, at least for the top x % programmers".
From my experince, this is just wishful thinking. It makes them feel special
and better than others.

~~~
kaoD
Macros are frowned-upon within the Clojure community, and for very good
reasons.

EDIT: okay, I got downvoted for some reason. Care to explain why?

The mantra in Clojure is "don't write macros until you NEED macros" (or some
alternative[1]). They make things horribly complicated and are awful to debug
and make code that uses them hard to debug too... especially within a JVM
environment (your code gets translated twice).

[1] [http://clojurefun.wordpress.com/2013/01/09/when-do-you-
need-...](http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-
in-clojure/)

~~~
RivieraKid
I didn't downvote you but the only significant advantage of the lisp syntax is
macros. I was always under the impression that the syntax is a price for
macros. If macros aren't really used, I don't see reasons for the lisp syntax.

~~~
kaoD
Macros are frowned-upon but used when necessary.

To put an analogy: people would've disgusted if you used a life jacket for no
good reason, but they're handy when you really need them :)

I also like Lisp syntax regardless of macros, mainly because it's simple,
consistent and prefix notation is really handy. The S-expr abstraction IS
useful when dealing with code blocks (see
[https://news.ycombinator.com/item?id=5940620](https://news.ycombinator.com/item?id=5940620))

~~~
RivieraKid
Brainfuck syntax is even simpler and more consistent ;)

~~~
kaoD
If Brainfuck syntax was half as powerful as powerful as S-expressions that
would be a valid comparison.

------
agilebyte
Just a note for anyone interested in what was mentioned in the article but
more comfortable with JavaScript.

There is mori
[http://swannodette.github.io/mori/#mori](http://swannodette.github.io/mori/#mori)
for persistent data structures.

Callbacks are handled by Promises or say async
[https://github.com/caolan/async](https://github.com/caolan/async)

For heavy compute tasks you can launch child processes under Node.js and
communicate with one management process, the Cluster
[http://nodejs.org/docs/latest/api/cluster.html](http://nodejs.org/docs/latest/api/cluster.html)
lib is experimental as of now.

------
bionerd
I don't think it's going to explode. And I don't think it needs to.

Even after decades there are still people who use Lisp-like languages and who
find them fascinating and _just right_ tools for their job. I, for example, am
a huge fan of Common Lisp and I'm really glad to see new stuff happening
around it and new people discovering it because there were times I was a bit
afraid about its future.

But will it ever dominate or explode? No, it won't. Same with any other Lisp.
And it's okay.

------
jdmichal
Does Clojure still have a non-trivial impact on performance? And if it
doesn't, does it still look as pretty?

I only ask because the whole idea of using it for "Big Data" flies right out
the window if it's significantly slower than plain old Java. Especially if
it's slower using naive or expected Clojure methodology. And if there's not a
speed advantage, than companies can find a lot more people who know and can
work Java code than Clojure.

~~~
willismichael
Performance and scalability are two different things. My favorite example is
to think of performance as being like the speed limit, and scalability as the
ability to easily add more lanes to the road. Once there are enough vehicles
on the road, it doesn't matter how high you set the speed limit, they'll still
slow to a crawl. Now imagine if there was a trivial way to add more lanes to
the road.

Clojure has very nice concurrency mechanisms baked right into the language.

~~~
optimiz3
This doesn't answer the author's question. We know the difference between
performance and scalability. How does it perform compared to Java?

~~~
saosebastiao
It is slower than java. It can approach Java with type annotations which
aren't that hard to do. It is faster than any other dynamic language I have
used, including python, ruby, javascript(v8), and lua(jit).

~~~
graue
Faster than LuaJIT? At what? Did you run benchmarks to back that up?

That's a very strong claim, and I've never heard anyone make it before. LuaJIT
is unbelievably fast. I'd be extremely curious to see the proof.

(As a side note, on some level it's hard for me to accept that Clojure is fast
because _using_ it feels gratingly slow — since all the tools take several
seconds to do anything thanks to the JVM's startup time. `lein repl`: 4
seconds wait. `luajit`, or `python` for that matter: utterly instant.)

~~~
saosebastiao
No benchmarks, just a few small algorithm implementations (kmeans, random
forest, ff neural net). Clojure was faster, although the difference was pretty
trivial.

I have been frustrated with Clojure lately because of startup time (I do a lot
of CLI tools), and would love to use Luajit, but my coworkers hate when I
write in languages other than Ruby or Clojure. For my own pet projects it is
great.

~~~
graue
Well that's pretty darn cool to hear that Clojure can achieve LuaJIT's level
of speed. But I agree, I feel Clojure just isn't suited for CLI tools at all,
unfortunately. I know there are solutions that keep a background JVM ready and
reuse it but I've never managed to get that to work smoothly.

------
boothead
It would certainly seem to me (in London at least) that scala has most of the
"enterprise functional programming on the JVM" pie. I hardly see any clojure
jobs pop up. From what I've seen I'd say demand for FP skills looks like:

Scala > F# > clojure > Haskell (really bummed about the last one!)

In London finance circles. Does that sound about right?

~~~
dons
Got about 30 guys here using Haskell. More in other centers.

~~~
boothead
I didn't know the team at SCB was that big! You guys should come to some of
the London Haskell meetups! In fact I think one of your guys is doing a talk
soon right?

~~~
dons
Tomorrow night (Wednesday).

------
gdonelli
Interesting take: "Over the past 20 years or so OO has dominated the landscape
and rightly so. It provides structure and a simplified way of organising your
code. OO design patterns such as MVC are going nowhere. But today with live in
a world with events, mobile phones trigger events, more intricate interaction
with UIs and apps all trigger a vast amount of events and traditional OO
doesn’t embrace this style of interaction as well. Instead functional
programming copes better."

We still need to organize our code tho, even with a functional language... and
I have missed the abstraction of OO (Using node.js)

~~~
frou_dh
I remember reading someone say that much of the class-based OO written in the
wild amounts to little more than a function namespacing convention plus a way
to jam in a bunch of hidden arguments. That hit home to what I was doing.

------
dominotw
I keep hearing this over and over. I like the idea of just changing 'map' to
'pmap' everything just working over multiple cores.

While cool,but really, Is there such a great clamoring for scaling programs
over multiple cores ? I never hear anyone asking about it job postings. May be
I am working in the wrong part of the industry than those mentioned in the
blog post. But I rarely hear game programmers talking about clojure/
functional programming. Most popular clojure projects on github are web
frameworks. I am puzzled why clojure is so popular among web developers if
concurrency over multiple cores is its 'killer' application.

From what I remember this paper never mentions 'concurrency' as to 'why
functional programming matters'

[http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf](http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf)

Neither does this( the only one?? ) poster child for lisp's success in wild
talk about concurrency
[http://www.paulgraham.com/icad.html](http://www.paulgraham.com/icad.html)

I think the whole multiple core thing is over blown in association with
functional programming. I think it would be pretty misguided for someone to
adopt a functional programming with multiple cores in mind.

~~~
ijk
Game programmers are especially unlikely to use Clojure for several reasons:

* New programming practices are adapted after the mainstream programming industry has adopted them.

* Java is not widely used, partially because when the great Java enterprise switch happened, game studios were still debating if switching to C++ was worth it.

* Because games deal with rapid state changes, switching from relatively intuitive object-oriented designs to functional designs requires a rethink of how most game engines operate.

* If it doesn't work on the consoles, the mainstream industry is much less likely to use it. Java isn't natively supported, and Microsoft is unlikely to add anything to the XBox to make it easier.

* Most games are still single-threaded 32-bit Windows applications interfacing with DirectX.

~~~
pjmlp
But they are willing to use Haskell, :)

[http://www.st.cs.uni-
saarland.de/edu/seminare/2005/advanced-...](http://www.st.cs.uni-
saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf)

[https://twitter.com/id_aa_carmack/status/331918309916295168](https://twitter.com/id_aa_carmack/status/331918309916295168)

~~~
epsylon
Not really, no.

Porting a 20 year old game for fun in Haskell doesn't mean that Haskell is
ready for the cutting edge of modern games.

~~~
pjmlp
They don't need to develop the next Crysis on Haskell to make it accepted.

The plain fact that important personalities in the AAA games industry are
willing to spend their valuable time coding something in Haskell instead of
doing something else, means a lot.

For example, are you aware that quite a few studios are now using Erlang for
their MMO servers?

------
ww520
Boy, another blog echos the empty chant on functional being superior than OO
without substantiating the claim.

"OO design patterns such as MVC are going nowhere." Really? MVC is going
nowhere? And how is functional organizing UI and model data better?

You can promote a technology without trashing another one. People know what
functional is and it has its niche as with any other things.

~~~
swannodette
Clojure actually embraces many of the great lessons of OO, you'll find them in
the form of first class namespaces, a standard library built on abstractions
not concrete types, a multimethod facility which supports derivation, and
protocols which support local and future extensions in much safer nicer
fashion than what the current popular OO languages provide.

To your other points - Clojure does data great - much nicer than OO languages
I've used. As far organizing UIs better Clojure programmers adopt many of the
same patterns that are currently en vogue. However I think there are some more
interesting new techniques just around the corner and we will be hearing about
them soon enough.

------
saosebastiao
My excitement about Clojure led me to core.logic, which led me to kanren,
which led me to Prolog. Am I doing it wrong?

~~~
gphil
Not if those tools are helping you solve the problems you want to solve. Also,
not if they're expanding how you think about computation. I'm willing to guess
at least one, if not both, are true for you.

~~~
saosebastiao
Yeah, it is both. It does seem a little counter-intuitive to some people, and
I get made fun of a bit for it.

------
mhd
For those who were around in the early '80s, was the Prolog/Transputer/FGCS
hype similar back then?

Plus ça change, plus c'est la même chose...

~~~
pjmlp
Most of us only had BBS, if we were lucky, so hype levels were kept very low.

~~~
xradionut
We had Byte magazine which had Dick Pountain's articles of sexy hardware with
which fantasize too...

~~~
pjmlp
And Computer Shopper, Micromania, Micro-Hobby, Crash, ....

Oh and books with code listings to type in hexadecimal rows of opcodes. :)

------
cuttooth
If a Lisp-like was ever going to explode, it would have done so within the
last 55 years.

~~~
dllthomas
Right, because nothing in the technological landscape changes, ever, in any
way that could be relevant to the success of a Lisp-like language.

I'm not saying I'm convinced a Lisp-like _will_ explode, much less that it'll
be Clojure in particular, and I do think it important to keep the history in
mind, but I think you overstated things.

------
JPKab
Clojure is the first purely functional language I've ever tried to teach
myself. I'm still learning, but I already find it a liberating experience to
stop worrying about state and learn to love the function.

~~~
yfefyf
Clojure is not 'pure'. At least in Haskell's sense of 'pure'.

~~~
shadowfox
He might be considering it from a functional-as-the-only-paradigm angle as
opposed to the technical definition of pure functional.

------
kybernetyk
I really like Clojure. My only gripe with it is that you absolutely need to
know the Java standard library/ecosystem if you intend to do anything non-
trivial with it. (And my Java experience ended in 2003.)

Though they are more and more 'native' clojure libraries being released.

------
frou_dh
Though I haven't and most likely won't do anything substantial in the
language, I've got a lot out of Rich Hickey's talks that have steadily
appeared on the web. He seems an extremely thoughtful designer and steward.

------
michaelochurch
Clojure is badass the whole way through: great language, great designers,
great support, great community.

I don't think it will ever get more than a 2% share in the software world, but
I think it can get the _right_ 2 percent. At least, that's what I hope will
happen. I also think that it will live (possibly even surviving the JVM) for a
long time.

~~~
skylan_q
_I don 't think it will ever get more than a 2% share in the software world,
but I think it can get the right 2 percent._

There will always be detractors. But then again, you can't teach a dog math.

I spent a tiny amount of time getting to know Clojure. I liked what I saw, but
some things confused me due to lack of looking into it/thinking about it. I'll
need to spend more time with it to find out if I'm a dog. ;)

------
scrapcode
"...I knocked up a lot of stuff which I wanted to write about."

...you did... what?

