

Clojure 1.0 Released - drewr
http://groups.google.com/group/clojure/msg/bcbdad671327d2f5

======
AndrewO
Between Clojure and Scala (and JRuby and Groovy), it seems like there's a lot
of potential for people to start using Java-the-platform without having
heavily used Java-the-language (I know I'm in that situation). I think there's
an opportunity for a book or blog-series that would get people familiar with
the good and/or necessary legacy aspects of the ecosystem.

What do the more seasoned Java-ers (Javites? Java-ists?) think will remain
most relevant from Java-the-language and the existing environment?

~~~
rmaccloy
It varies; you'll want to know quite a bit of Java for Scala and Groovy but
less so for Clojure, in my opinion. Clojure has a quite distinct flavor and
you see things like ring being used instead of servlets directly in compojure,
etc. It'll be interesting to see how much of the standard Java toolkit gets
reinvented due to distaste for the Java-ness of some of the stack (which isn't
necessarily a bad thing.)

Practically speaking, I think you'll need to be at least a competent Java
programmer for the next few years if you don't plan on reimplementing a lot of
bits that are in the extended Java stack.

------
jcromartie
Is it just me or was this really _fast_? It seems like the Clojure team got a
huge boost from choosing the JVM as a starting point here.

~~~
arohner
Yes, it was fast. I believe 18 months between first public release and 1.0.

Though rhickey said he worked on Clojure for a year+ before the first public
release, and before Clojure he worked on two projects trying to integrate
Common Lisp and Java (call Java from CL and vice versa). He said the
difficulty of those projects lead him to write clojure.

~~~
shaunxcode
Which is funny because (as I recall) the initial developer of java itself
started the project after getting frustrated with how difficult it was to
implement macro expansion for c. It seems things have finally come full circle
yielding the best of both worlds.

~~~
mahmud
I thought they wanted to program set-top boxes but weren't sure of the final
hardware implementation so they abstracted away the VM and runtime, initially
with an eye towards an smalltalk implementation but ended up greenspuning
something new called Oak?

------
cstejerean
This is excellent news and I think it was a great idea to try and have 1.0
ready before Stuart's book is released. Now that Clojure is at 1.0 I also feel
less guilty about trying to use Clojure for work.

------
jksmith
There's something that bothers me about Clojure, and anything else that runs
on top of the jvm and encourages heavy use of java libraries. It's similar to
the thoughtful post in the "It's about the Libraries" thread regarding Clojure
not being a completely coherent system because it is not a Lisp system. Same
could be said for Scala.

For one, if the libraries are what's important, then just keep on with java.
For another, so what if we get to use all these features, like coherent
concurrency and stm? It seems to me that the use of one shitball java library
could negate any value that Clojure brings to the table. So is it really the
case that while java library interop is fully realized with Clojure, and this
is a major selling point, for mission critical software we should not use java
libraries that haven't been thoroughly scrutinized? I believe it is the case
that there are libraries that are acceptable for use with more java, but their
use will be discouraged if Clojure is thrown into the mix. Clojure just hasn't
been around long enough to have to deal with these issues yet.

In a similar vein, this is something that has always bothered me about Ada.
Why even have a version of Spark Ada that runs on windows, or any other OS
that itself is not written in Spark Ada?

I wonder if Wirth was at all driven by this issue, because he always seemed to
include a machine as part of the language he was developing at the time.

So is it the case that any advances to Lisp like Clojure require that we just
accept these less coherent systems just to get some work done, even though it
really would be preferable to have all the libraries you need on something
like a Genera with concurrency and stm realized, even though we don't want to
admit it? I'd like somebody to set me right on this point.

~~~
weavejester
"For one, if the libraries are what's important, then just keep on with java."

Java has a very restrictive and inflexible syntax. I'd rather have macros,
first class functions, and all the other benefits of a Lisp, as well as being
able to access Java libraries.

"It seems to me that the use of one shitball java library could negate any
value that Clojure brings to the table."

You mean you could use a Java library that uses threads and has locking bugs?

Sure, that's a possibility, but I can't think of a language that doesn't have
this problem. Even if the language itself is safe, there's usually a FFI.

"I believe it is the case that there are libraries that are acceptable for use
with more java, but their use will be discouraged if Clojure is thrown into
the mix."

Why do you believe this is the case? If a Java library suffers from race
conditions in Clojure, it'll suffer from race conditions in Java as well.

------
aurora72
I had plans porting one of my applications which used XML as the DB and did
heavy XPath processing, to LISP just to see how it worked but had concerns on
the GUI part. It looks like The Clojure innovation will ease which can be
summarized as: "GUI programming using Lisp" I welcome the Java-the-platform!

~~~
mahmud
With XML storage, XPath and GUI programming, I very much doubt you will be
seeing any much clojure/lisp goodness but will most likely hammer out XML in
the same way it's hammered out in every language: slowly and painfully :-P

------
dhimes
I'm excited. I will be using this to learn LISP.

~~~
mahmud
And that would be a BIG mistake. Your clojure-using peers will be
knowledgeable engineers with things to do and products to ship and very little
time to help you. There is also _zero_ academic literature to hold your hand.
With a new programming language, you are often forced to reach out to your own
past experience for a repertoire of programming techniques. You will learn the
syntax of clojure, sure, but you will be writing whatever languages you know
now in a fully parenthesized prefix syntax.

A better question to ask would be "what language motivated Rich Hickey to
create Clojure"; pick a more stable Lisp, learn the ropes, and come back to
kickass on the JVM in a few months.

~~~
tfincannon
I see no reason to spend a lot of time learning Common Lisp at this point. The
Clojure community is helpful, because everyone is so excited to have a Lisp
they can really use. Stuart Halloway's book is a good enough introduction to
Lisp concepts that one could go on to the more academic books to learn more.
The book consistently takes pains to show idiomatic Clojure--a good first step
away from the Java/C/C++ mindset. The core syntax of Clojure has been stable
for several months now, and the implementation itself has been stable for much
longer.

Learning Scheme just to read SICP (for instance) isn't necessary either. Since
Clojure is a Lisp-1, it works well for the exercises in a Scheme-based book.

~~~
mahmud
I will not argue the merits of CL since I would be biased, but Scheme? Clojure
is no scheme. It can barely do tail recursion cleanly without resorting to a
keyword (recur?)

Scheme, along with Mozart/OZ are the perfect candidates for delivering
programming skills without platform obstruction. Admittedly, it would take an
_specific_ implementation Scheme, a large and feature-rich one, to properly
introduce someone to the real powers of Lisp.

Go thorough a series of complete Lisp systems, say MIT Scheme and CMUCL, and
see what a complete Lisp system looks like.

------
jgrant27
It's ironic that this was posted as the same day as this -->
<http://news.ycombinator.com/item?id=591897>

Would be interesting to see how a version in Clojure compares.

~~~
albertcardona
Clojure leverages concurrent execution like no other language I've seen. It's
dead easy to parallalelize a program (sometimes just adding a single letter
'p' to some function names, like "map" -> "pmap") and always correct, working
with transactional memory. That alone is an outstanding achievement.

------
TweedHeads
Hmm, not my style...

