5 ms·

Clojure 1.0 Released

139 points by drewr 17y ago

jcromartie 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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?
dhimes 17y ago
I'm excited. I will be using this to learn LISP.
- mahmud 17y ago
  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 17y ago
    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.
    - deleted 17y ago
      [deleted]
    - mahmud 17y ago
      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.
cstejerean 17y ago
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.
AndrewO 17y ago
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 17y ago
  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.
- jimbokun 17y ago
  "What do the more seasoned Java-ers (Javites? Java-ists?) think will remain most relevant from Java-the-language and the existing environment?" If you can package your code up in a jar file, in a way that the "API" you want to export is easily callable from Java, then you can deploy to pretty much any platform and every other language on the JVM will be able to interact with your library. Beyond that, learn to read Javadoc well enough so that you can download an arbitrary jar file and call the classes and methods that you need from the language of your choice. That should take you a pretty far. "Java-ers (Javites? Java-ists?)" We prefer "cubicle dwelling code monkeys." Or just "Blubbers."
- michaelneale 17y ago
  I think there is plenty of evidence that you don't need to touch java the language now. However, if you need to interop with existing libraries or between languages (not specifically java language) then it is probably worthwhile at least understanding how interfaces work in java (and most languages would allow you to define them in their own language) - as that is often used at the edges of systems (and its also pretty simple).
jgrant27 17y ago
It's ironic that this was posted as the same day as this --> http://news.ycombinator.com/item?id=591897 http://news.ycombinator.com/item?id=591897 Would be interesting to see how a version in Clojure compares.
- albertcardona 17y ago
  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.
deleted 17y ago
[deleted]
TweedHeads 17y ago
Hmm, not my style...
aurora72 17y ago
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 17y ago
  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
jksmith 17y ago
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 17y ago
  "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.

139 points by drewr 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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?

dhimes 17y ago

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

mahmud 17y ago
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 17y ago
  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.
  - deleted 17y ago
    [deleted]
  - mahmud 17y ago
    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.

cstejerean 17y ago

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.

AndrewO 17y ago

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 17y ago
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.
jimbokun 17y ago
"What do the more seasoned Java-ers (Javites? Java-ists?) think will remain most relevant from Java-the-language and the existing environment?" If you can package your code up in a jar file, in a way that the "API" you want to export is easily callable from Java, then you can deploy to pretty much any platform and every other language on the JVM will be able to interact with your library. Beyond that, learn to read Javadoc well enough so that you can download an arbitrary jar file and call the classes and methods that you need from the language of your choice. That should take you a pretty far. "Java-ers (Javites? Java-ists?)" We prefer "cubicle dwelling code monkeys." Or just "Blubbers."
michaelneale 17y ago
I think there is plenty of evidence that you don't need to touch java the language now. However, if you need to interop with existing libraries or between languages (not specifically java language) then it is probably worthwhile at least understanding how interfaces work in java (and most languages would allow you to define them in their own language) - as that is often used at the edges of systems (and its also pretty simple).

jgrant27 17y ago

It's ironic that this was posted as the same day as this --> http://news.ycombinator.com/item?id=591897 http://news.ycombinator.com/item?id=591897 Would be interesting to see how a version in Clojure compares.

albertcardona 17y ago
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.

deleted 17y ago

[deleted]

TweedHeads 17y ago

Hmm, not my style...

aurora72 17y ago

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 17y ago
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

jksmith 17y ago

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 17y ago
"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.