
Shall We Use Clojure? - kschrader
http://www.andrewhjon.es/142343729
======
JackC
The other thing I think is worth considering in a move to Clojure is how
different functional thinking is. I mean, if you're used to moving between C
and Perl and Python and PHP and Java and Javascript and so on, you're used to
language transitions within more or less the same paradigm. It feels like a
categorically different problem to try to transition a team from one of those
to a functional language.

I'm thinking in particular of this section from O'Reilly's Clojure book:
[http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6...](http://books.google.com/books?id=I8KdEKceCHAC&ots=wNiLN6Tce5&pg=PA138)

They lay out a couple of algorithms in an imperative style, and then gradually
morph them into a functional style. It's pretty wild: you go from a story, "do
this, then do this, then do this" to a math problem: "your answer is a list
composed of f() of g() of h() of another list". (Unfortunately you only get
snippets from that link -- it's worth the money to get the whole thing if
you're interested.)

Anyway, having followed through their examples and done some of my own Clojure
programming, I ended up not so convinced that people who are good at solving
story-style imperative problems will necessarily be good at solving math-style
functional problems. It felt like a different part of my brain.

This is not _at all_ a reason not to dabble with functional languages, just a
potential pitfall to be aware of if you're thinking of bringing a whole team
over. And maybe I'm overstating it? I haven't dabbled too much myself.

~~~
grannyg00se
"C and Perl and Python and PHP and Java and Javascript and so on, ... It feels
like a categorically different problem to try to transition a team from one of
those to a functional language."

I just have to throw a flag here and point out that Javascript is also a
functional language. With Javascript you can declare functions as variables,
pass functions as arguments to other functions, return functions as the result
of other functions, and use them as part of a data structure. Javascript is
much closer to Scheme than it is to a C paradigm.

~~~
silentbicycle
Well, you can pass around function pointers, return function pointers, and
store function pointers in data structures in C, too. You can also use
closures - a closure is just a (function pointer, struct with its closure
values) struct. Sure, OCaml, Scheme, and company box the pair for you, garbage
collect it, and don't make you flatten your code into a single file-level
scope, but the difference between Javascript and C isn't as big as you think.

Javascript is kinda sorta maybe functional if you look at it right, but it's
still mostly the same imperative/object-oriented mishmash as Java, Python, or
Ruby.

~~~
abecedarius
Being able to nest first-class functions without manual closure-conversion /
lambda-lifting makes a big difference for the feel of a language, to me.

(Java is sort of in between -- it technically has that feature but with
verbosity getting seriously in the way of using it.)

~~~
silentbicycle
Indeed. I'd certainly rather be able to nest functions, but C became a lot
more powerful to me after I learned how to compile a bunch of high-level
features to it. (Your 'ichbins' helped, by the way. That, LiSP, and some SML
papers.) I'd still rather automate much of the heavy lifting, of course.

I'm weirded out by the idea of writing CPS-transformed code _by hand_ for
node.js, but apparently people like it? Perhaps it's something similar.

~~~
abecedarius
The thing I don't get about node.js is that it used to have a promise
abstraction and they dropped it to go callback-only. I guess the abstraction
leaked, in a language not built around it?

I like to imagine Node's success comes from bringing some of E's insights to a
community just ready to use them, and if the cost is manual CPS, apparently
it's not too high. (Relevant E theory at
<http://erights.org/elib/concurrency/overview.html> )

------
spacemanaki
This example is missing the corresponding Clojure code, which is important for
Java interop:

    
    
        object.method(arg) // Java 
    
        (.method object arg) ; Clojure 
    

I'm not sure if focusing on syntax and succinctness is such a great approach
though. When I've discussed Clojure with colleagues familiar with Java,
they've been more interested in the concurrency support via immutable data
structures and reference types, which really sets Clojure apart from other
Lisps. I think it's a much more compelling sell that way, since Java
programmers seem to be attached to Java's syntax and static typing, but are
aware of how difficult it is to write correct concurrent code. YMMV of course.

~~~
Tuna-Fish
I agree. A good way to sell Clojure to an experienced Java programmer is to
ask him has he ever serialized data to a string for passing it around in a
program, and why. Then when he explains how the semantics for all the
composite Java types except for string suck, tell him that every type in
Clojure just works right, like string does in Java.

~~~
tubes
Why would anyone do that? We use immutable collections, immutable value
objects, unmodifiable views and deep/shallow copies, but never serializing
data to a string just for passing it around. I think most experienced Java
developers would go for the type-safe alternatives.

------
dxbydt
I made a similar presentation a year ago to a bunch of fellow quants at the
bank. I chose Scala, and my presentation was mostly code. Quant Finance tends
to be one of those areas where Scala really excels. For example, a time series
is just a running fold. So instead of having an imperative for block with
various indices & guards, you can write a 1-line prefix scan to price a 5 year
CDS. My examples also included bond pricing, vanilla calls and puts, binomial
trees, monte carlo generators, portfolio optimization, risk calculations ( VaR
& CVaR ) and a few graphics. My manager was very open-minded when it came to
technology choice, and my fellow quants were somewhat tough on the 2 hour
presentation, but the end result was what I believe is called a win-win. We've
since pushed a bunch of apps coded in Scala into production, and the group has
embraced the language quite enthusiastically.

~~~
dons
> where Scala really excels.

Functional programming in general.

An awful lot of finance (that used to run in Excel) is just side-effect free,
compute-centric transformations over data. Time series, for example, have a
relatively nice algebra that makes it easy to manipulate in terms of maps,
scans and folds. And anything that makes it easier to avoid off-by-one errors
is a big win, especially if your traders and quants aren't trained software
engineers.

~~~
ansgri
For offline analysis, I'd eagerly agree. But have you had any success with FP
for online analysis? E.g. you have 100 time series updating every second, and
must yield some other series and events.

~~~
dons
Yep. We use Haskell for all systems, online and offline, including the soft-
real time stuff that watches the live feeds.

------
gav
If I was manager wanting to decide on a substantial technology change like
Clojure with a presentation like that I'd have to answer "no". It doesn't
answer some of the most important questions:

1) What level of support is there for the Clojure toolchain? Is this likely to
be around in 5 years from now?

2) We are going to need to hire programmers in the future. Are there people
with Clojure skills (or those that we can cross-train) around? In our
geographic region? At the price point we can afford? In 5 years from now is it
likely that this is going to be a marginalized technology that we have trouble
finding skills for?

These are the more important questions, not how succinct the language is. I've
had first-hand experience of how technology choices affect companies and it
can be very painful down the road.

(Note: this isn't intended as a dig at Clojure, you could replace it with
Scala, or any other up-and-coming language choice.)

~~~
dxbydt
While I wholly sympathize with your rather pragmatic pov, technology is not a
staple industry like agriculture or the diary business or the furniture
industry. It is more like the fashion industry. You have to be a bit of a
visionary to succeed in this trade.

>Is this likely to be around in 5 years from now?

In 1997 when I graduated, career services told me to erase Java from my resume
and replace it with "Borland C++ OWL 2.0" so that I could land a job.
(<http://en.wikipedia.org/wiki/Object_Windows_Library>) At that time, Java =
dancing duke on netscape navigator. Right now, I'd give a million dollars to
find another OWL 2.0 developer ( ok not a million, maybe $10 )

>5 years from now is it likely that this is going to be a marginalized
technology

5 years == light years in tech. Nobody can predict that far out.

>it can be very painful down the road.

If you future-proof yourself by only using the most stable, well supported
toolchain, it can be much more painful down the road when you are stuck with
some legacy platform nobody is willing to code in because everybody has moved
on to the next big thing.

>you could replace it with Scala, or any other up-and-coming language

There should be a statute of limitations on when you can stop using "up-and-
coming" w.r.t a language :) Seriously,Scala has been around in some shape/form
since 2003. We've had stable releases since 2008. At this point it is no
longer "up-and-coming".

~~~
brehaut
Pedantic point: Light years are a unit of distance, not time.

<http://en.wikipedia.org/wiki/Lightyear>

~~~
emil0r
So it's further ahead and you can't see what will happen there. Sounds like a
perfectly good use of the word, given the context :).

------
prakashk
To the OP: If you have to take a cheap shot at Perl in order to demonstrate
the benefits of Clojure, then you have failed.

For the record, I am not implying that Perl is above criticism. But, showing a
single arbitrary perl code segment, and touting that Clojure doesn't look like
it is not fair comparison.

~~~
DigitalJack
He was anticipating the argument that succinctness leads to unreadable code.
Perl is a language where you can choose to be so terse as to be nearly
unreadable.

I don't think he was trying to claim that was idiomatic perl. Rather he was
saying that clojure is succinct and still very readable.

~~~
prakashk
If he chose his example without consideration of idiomatic Perl, then his
attempt appears even worse. Further he chose to remove all spaces from the
example, presumably to demonstrate that Perl code is "not clear".

I have not written a single line of clojure, and don't know how idiomatic
clojure looks like. I tried to translate his example to clojure using my very
limited knowledge and looking at the examples on ClojureDocs site:

    
    
        (sort #(compare (second (re-matches #".*([aeiou]).*" %1)) (second (re-matches #".*([aeiou]).*" %2))) %)
    

I am sure this is not idiomatic clojure, and probably a very bad way to write.
If I cited this as an example of typical clojure code, then I'd be making a
totally unfair judgment.

The funny thing is, when I just add spaces to the Perl code segment, it looks
quite readable to me. But then, I probably know more Perl than him.

    
    
        sort { ($a =~ /([aeoui])/)[0] cmp ($b =~ /([aeiou])/)[0] } @_

~~~
dsabanin
You've pasted a broken Clojure example here.

~~~
prakashk
I did not paste the Clojure example from anywhere. I wrote it. It was not
intentional on my part to write broken code, but if it was, it actually nicely
illustrates my point.

------
espeed
Andrew mentioned _The Joy of Clojure_ ([http://www.amazon.com/The-Joy-Clojure-
Thinking-Way/dp/193518...](http://www.amazon.com/The-Joy-Clojure-Thinking-
Way/dp/1935182641)) and _Clojure Programming_ ([http://www.amazon.com/Clojure-
Programming-Chas-Emerick/dp/14...](http://www.amazon.com/Clojure-Programming-
Chas-Emerick/dp/1449394701/)). Both books are good, and each has its strong
points.

 _The Joy of Clojure_ goes into to Clojure philosophy and explains the "Why?"
of Clojure. _Clojure Programming_ is divided into five parts, and parts III
and IV provide a good overview of how to set up your environment and structure
projects.

But the best book for learning the language is _Programming Clojure_
([http://www.amazon.com/Programming-Clojure-Stuart-
Halloway/dp...](http://www.amazon.com/Programming-Clojure-Stuart-
Halloway/dp/1934356867/)) by Stu Halloway. Stu works alongside Rich and
understands Clojure at a deep level, but he's still in tune to the beginner's
mind and is able to clearly explain concepts and provide the context you need
for the ideas to resonate.

~~~
andrewvc
I disagree, I found joy to be a much better text for learning than halloway's
book. Halloway's book didn't have as good a flow from one section into the
next and felt more disjointed

~~~
cgag
I haven't read Halloway's, but I found the O'reilly book much more helpful for
learning Clojure than The Joy of Clojure. They're both great, but I'd
definitely read the O'Reilly book before Joy.

------
columbo
-slightly off topic-

I really like some of these languages. Clojure is something I've worked with
but haven't built a complete product from, but I'd like to make something
standalone.

I just wish there was a single website devoted to re-creating the terribly
boring "Employee Directory Website" app in each language of choice.

It would be even better if the creators of said language would go through the
time to make the example site so I could see how they imagine a CRUD layer
working, or sessions, or REST/XML data, or the sql connection.

For every "new" language it seems I can find a hundred examples of fibonacci
sequencing (or more recently everyone seems to enjoy creating 'twitter in 5
lines of code!') but almost no real "boring web stack" examples.

~~~
fshen
There are quite some interesting web apps implemented in clojure. Build web
app with clojure is where clojure shines. I've built a few, some are for the
company which pay me. One for myself, the source code
<https://github.com/shenfeng/rssminer>. You can have a look, It did the things
you mentioned

------
16s
Many of these presentations come across as proselytizing. It's an immediate
turn-off to some developers and most all managers. The proselytizer claims to
know or be able to understand things that others on the team cannot. It's
condescending. You wouldn't say to a co-worker... "I understand why we should
use X, you do not, so I'm going to enlighten you and explain this to you in a
way that you can understand and see the benefits of."

The best way to gain traction and to get others to use your favorite tools is
to write code and implement projects on time and under budget that are
reliable and easy to maintain. If you do that, then the tools that you use
will be in demand. Others will _want_ to use them and they will speak for
themselves.

------
th0ma5
Pretty nice intro / advocacy piece for Clojure. I have high hopes that once
we're flooded with more example code people will start to see the simplicity
of Clojure. Right now the reference is somewhat terse, but you can dig around
GitHub quite a bit which is nice. Also, it seems that the combination of
people working with contemporary problems and small and succinct generics that
you wind up making in Lisps, there could be a lot of great reusable code for
this language out there soon. I'm also curious about <http://www.collaj.net/>
... the Redfoot project for RDF / Python seems to remind me of this... that
we're not paying enough attention to the "Google / Paste / Execute" loop.

------
javajosh
This may seem superficial, but Clojure's usability is a problem. The source-
code itself is hurt by the same thing that makes it strong: homogeneity. Even
at a superficial level, skimming with the eye, closure code looks strange. It
is exactly the same problem that markup that is all divs has when compared to
markup that uses common top-level markup. It's hard for the eye to pick out
what's important, and what's going on. In addition, indentation rules are not
agreed upon and it's a bit stutter stop. (I actually think this is a worse
problem then the "inside out" problem).

Aha! I just had a really good idea! Let's call it "Clojure folding". It's like
code-folding only instead of hiding lines, you pull up all the code into one
line. Some of the internals may be elided - and revealed with a tooltip.

I also like the idea of coloring the entire content of the parens, so that you
can embed a large item and then clearly see that you are now back in the
containing list. Indentation doesn't do a good enough job, nor do rainbow
parens. Further, you'd get a good intuitive sense of place in the code if you
have a consistent series of colors. Emotionally, you'd know that if you're
typing read you're like 6 layers deep - and that's really deep, in the danger
zone, and you probably want to pull some stuff out into definitions.

Chris Granger, feel free to include these ideas in Light Table.

~~~
tylerhobbs
We have been using Clojure for a product for about 9 months now, and in my
experience, I have no trouble identifying what different blocks of code do. It
may depend on proper syntax highlighting, but I think one of the keys is that
there is so little boilerplate in Clojure that _all_ of the code is important.
You're not skimming over getters and setters, assignment of constructor
parameters to the object, or some of the other things your eyes tend to
automatically skip when reading, say, Java or Python. It tends to be pure
logic or pure data, with very little else in the way.

~~~
javajosh
The problem is that you don't have cues about what you're looking for.
Keywords and actual syntax give a lot of those cues.

------
eragnew
Clojure keeps looking more and more interesting. Noir, in particular, has
caught my eye. Anyone have a link to a high-quality Noir tutorial? (high-
quality in the sense of straightforward yet useful)

Nice article, BTW. Good intro for those not familiar with Clojure yet.

~~~
sailfast
I gather you've already seen these? <http://webnoir.org/tutorials> They got me
started, and then I went to the Hiccup docs
(<https://github.com/weavejester/hiccup/>) for more detailed information. I
have yet to find a more comprehensive walk-through but I'll post again if I
find one.

~~~
eragnew
Ah. Hiccup is new to me. Will have to play around with it. Thanks for posting
that.

Likewise, if I find a more comprehensive tutorial, will post as well.

------
ryanpers
Interesting article, but its only skin deep... The larger issues are down the
road, it's where the engineers and the sophomore programmers are separated.

------
it
I really like Clojure as a language, but the JVM implementation takes over a
second to start. This lack of responsiveness makes it a poor choice for many
small scripts that should run quickly. If not for this issue, I would probably
use Clojure on a regular basis.

~~~
sgt
As did java just a few years ago. Once it has been started once though, it's
quicker.

~~~
dedward
As does java - it's all the same jvm.

The VM is optimized for long-running applications, not brief
scripts............ bang those out in whatever.

~~~
sgt
Although you could argue the .NET CLR is also optimized for long-running
applications, because it's directly competing with Java. Why is the CLR so
much quicker?

For interests sake, I typed "java -version" on my new MacBook Pro now and it
took 0.9 seconds. Second time it took 0.11 seconds. It's still unacceptably
slow, in my opinion.

------
z92
What about speed. If one writes, for example, a video processing library in
Clojure will it run slower than if it had been written in pure Java?

~~~
masklinn
A clojure program written in "canonical" style will usually be slower than the
equivalent "canonical" java program (as long as canonical != enterprisey
canonical), if only because canonical Clojure uses immutable datastructures
and therefore spends quite a bit of time churning memory _but_ Clojure lets
you type-hint programs (to generate more type-tight bytecode, closer to what
statically typed Java would provide), use Java mutable types and alongside
compile-time metaprogramming that can be used to generate code which will
likely be as efficient as tight Java code:
[http://www.learningclojure.com/2010/09/clojure-faster-
than-m...](http://www.learningclojure.com/2010/09/clojure-faster-than-machine-
code.html)

A bigger drawback to Clojure, in my experience, is that error messages are
complete shit (most errors will yield stack traces to compiled bytecode, so
you get java traces with a layer of obfuscation in that they're tracing the
bytecode generated by clojure). The same issue exists when trying to improve
performances, you get performance counters for java bytecode and have to match
them to clojure code "by hand".

~~~
DennisP
You may know this, but Clojure's immutable data structures don't spend near as
much time churning memory as they would if they were implemented naively.
Change one element of a sequence, and in your new sequence all the unchanged
elements will reference the same memory locations they did before.

~~~
masklinn
Sure, but you'll still need to reallocate all the tree path leading to the
changed value, there's only so much immutable datastructures can share. And
this _does_ result in signifiant churn compared to an object/imperative system
where most of the manipulations mutate existing objects (with very little
allocations or deallocations comparatively).

------
cbp
I do consulting for small businesses around where I live (Mexico). And since
like 3 months ago I switched to clojure and I couldn't be happier. I used ruby
then python before. Now there is one minisupermarket doing billing and
inventories and backups and charging customers with clojure in Mexico and that
number is looking to grow!

------
gosub
<http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines>

------
jenius
This finally actually won me over. Starting the clojure book - let's make this
happen.

------
leke
To someone who is about to learn Java, would you recommend Clojure instead?

~~~
technomancy
Totally depends on why you want to learn Java.

~~~
leke
I'm looking to expand my knowledge range and open a few more doors to
different areas. I currently am fairly proficient with python, php, mysql,
dhtml. Java seemed like a natural progression especially since I'm interested
in mobile phone development, but I'm also interested in the strengths of the
JVM and Java's libraries.

~~~
technomancy
If you want to learn for the sake of expanding your knowledge range, Java is a
pretty bad choice; there's very little that's novel about Java. The two
advantages it has over Clojure right now are are 0) it's much easier to find
employment in and 1) Clojure isn't yet suitable for Android development.

~~~
swah
I used Clojure and now I'm using a little bit of Java (and reading Effective
Java) and I'm pretty glad I'm doing so: interfaces, generics, concurrency,
data structures, mutable vs immutable objects, etc etc: most I just ignored
when programming Clojure... and they are interesting to know IMO.

(I intend to return to Clojure/Python on the next project because Java really
makes CRUD style web programming a PITA).

------
mey
Needs a diagram "Number of parenthesis by language".

