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?
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.
"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."
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).
Wouldn't you need to know the system programming language to make full use of your platform? It's hard to be write good Unix software without knowing C, for example. I don't know about others, but I need to visualize the cost of each language construct and be aware of more things than exposed by the language itself.
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.
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.
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?
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.
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!
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
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.
"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.
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.
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.
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.
I've been on #clojure and asked stupid questions more than a few times. I've always gotten very well thought-out answers, and everyone has always been friendly.
i totally don't agree with that. Clojure enforces a much more functional style "by default" than any other lisp i know of (not that i am a vet lisper).
I for once understood lisp with clojure and scheme 1 year ago. Now i can do Common lisp, but playing with clojure was much more enlightening. If you ask me why, i'd say that it's a mix between good timing (i had been reading about lisp since a lot of time) and the fact that it's motivating to learn on a new platform with access to a ton of libraries.
My advice though : Don't start with common lisp. Most of the ressources for learning it are really unclear (PCL included)
Start with Scheme (lots of good newbie-oriented ressources), and then switch to clojure once you grasped the basics.
Good point. However, using a guide such as Programming Clojure from the Pragmatic Bookshelf is a pretty quick way to try out some of the 'Lispy' concepts. I'm literally beginning the book so cannot comment further but it seems an accessible way to begin.
You would be missing on classics of the field: Norvig's PAIP, PG's On Lisp, Quinnec's Lisp in Small Pieces, and, of course, SICP.
Lisp is a language best "learned" furiously, through different dialects, implementations, extensions and library packages, and of course, thorough own implementation.
Clojure hasn't undergone the same vetting other dialects have gone thorough. Reading Common Lisp the Language (2nd Ed.) you will truly see what it takes to add a feature to a language and what it takes to remove it. 20+ people had to convince each other why something was worth keeping :-) And from there read the specs for ISLisp, EuLisp and and LeLisp. Schemes implementations have been a treasure trove of pure human genius: one implementation, T, has been responsible for so much it merits a year of your life just to read the associated literature and follow the heritage of this beautiful language.
Clojure has Rich Hickey's video, but none of it is, yet, time tested. A fine Lisp, no doubt, just not one for active learning.
Appreciate the comment, this is why I come here :).
I've been meaning to- and will, read PG's On Lisp. I saw the benefit in starting with Clojure being: the setup (basically nothing if you have a JVM installed) and the fact that applications created can be deployed in a JVM container- making it possible you any projects you'd like to host.
Your comment has inspired me to look into some of the schemes at least at the same time. Thanks.
Save this paper and read it a year or two into your Lisp hacking:
www.dreamsongs.com/Files/HOPL2-Uncut.pdf
Once you know your Lisp, that paper will immerse you into the culture and history you need to become a bona fide Smug Lisp Weenie.
Lisp is not just a language, it's an ongoing and animated debate. Get your feet wet, get emacs and Slime, play around with all the dialects and implementations it supports, hack the good hack, send patches, ask for help, start a company, and welcome to the community! :-)
On Lisp is a must, it is just a really brilliant book that delves into what Graham argues (and I accept) is the most distinct and powerful feature of Lisp, macros.
I can see evidence that Clojure contributors have read it too, just the other day there was an example of an anaphoric macro posted on the mailing list. Very cool.
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.
What do the more seasoned Java-ers (Javites? Java-ists?) think will remain most relevant from Java-the-language and the existing environment?