

Thinking in Clojure for Java Programmers - swannodette
http://blog.factual.com/devblog/aaron/thinking-in-clojure-for-java-programmers-part-1-—-a-gentle-intro/

======
harlowja
There really should be a comparison to something other than java, it doesn't
seem fair.

~~~
dirtyvagabond
Fair point! Well, Google will show you plenty of results for, e.g. "clojure
vs. scala". What I was going for wasn't an unfair comparison, but rather a
kind of bridge for Java / JVM folks who might be interested in a more
functional way of life. My bad if I missed the mark. :-/

~~~
swannodette
I don't think it's an unfair comparison at all. Comparing Clojure and Scala
can only generate interest in a few small (though growing) communities.

You've done an excellent job of showing Clojure's benefits to a much, much
wider audience - programmers not familiar with functional programming. Also
it's compelling to hear that you're successfully using Clojure to efficiently
"script" larger Java codebases.

Kudos for writing such a hype-less, non-condescending, and educational
tutorial for Java/imperative programmers!

~~~
dirtyvagabond
Thanks swannodette, very kind of you! Yes, it's been cool to layer Clojure on
top of legacy Java and see what happens. Some want to sell Clojure as "a
better Java than Java"... I think that may be a little misguided. But, there
are certain situations where it rings true... at least IMHO

~~~
swannodette
I don't think Clojure's goal is to be "better Java". Rather, that for whatever
task you might consider Java, writing that task in Clojure should be:

    
    
      * easier to write
      * perform just as well
      * be concurrency safe
    

Clojure isn't there yet, but it's well on its way I think.

~~~
jshen
it's easier to have unsafe concurrency in clojure. It's certainly easier to
get it right by default than in java, but it's still very easy to introduce a
race condition or some such.

~~~
jshen
Typo, I meant easy not easier

------
peterlada
I love functional programming. At least the functional parts of Python.
However, Lisp seems better suited for computers than for humans.

Which is probably a side effect of having been created when 64kB was a decent
memory size.

~~~
InclinedPlane
Indeed. For example, retaining a method name like "defn" seems more than a
little suspect in an era of gigabyte memories, terabyte hard drives, and auto-
complete IDEs.

~~~
zephjc
'defn' is hardly old-school; Python uses 'def' to define functions. Now 'car'
and 'cdr' on the other hand...

This is far preferable to typing e.g. "public static void ..." all the time

~~~
InclinedPlane
defn harkens back to an era when using a computer meant using a teletype,
putting an extreme premium on terseness in naming. And it's just an example,
car, cdr, cons, etc. are just as bad. It's easy to memorize these but that
doesn't mean they are the best choices for readability, writability, etc.

I have a hard time believing that the best choice of name for all of these
operators just so happens to always be some 3 or 4 character string that's
almost but not quite a word and seems to have dropped some vowels.

As for "public static void ...", that's a disease of another sort, equally as
bad.

~~~
mikedouglas
`defn' is a mnemonic for "define function". `cons' is a mnemonic for
"construct".

`car', and `cdr' and replaced in clojure with `first' and `rest'.

Once you've spent ten minutes with the language, these names aren't going to
trip you up.

~~~
mahmud
People want to learn "new languages" without having to learn anything new.

~~~
gruseom
Well put. There's also a tradeoff between learning-curve and proficiency in
language design: many features that aid the one detract from the other. I
think this causes much of the noise in programming language discussions,
especially with Lisp.

