[Lewisham]

This basically looks like Kotlin, except it explicitly compiles down to Java.

I'm not sure how I feel about this. Pre-Kotlin, I would have thought "hey, neat", but now it seems like we're on the verge of a number of half-supported half-hearted attempts at being Java.next, each with their own pros and cons. I wish that IDEA and Eclipse could have worked together on this.

[squidsoup]

It's a pity everyone gets so worked up over trivial things like parens - Clojure is a beautiful language that absolutely deserves to be the next big language on the JVM. Yes, it offers a different programming paradigm from Java, but perhaps to make any genuine headway in the future we need a clean break from Object Orientation and it's muddled conflation of identity and state.

[bunderbunder]

Trust that I, a programmer who cut his teeth on LISP, offer this brutal truth in a spirit of compassion:

LISP is the second-oldest HLL there is. As a syntax and a way of structuring code, S-expressions have been around since before the vast majority of software developers were born. Despite what one might be read to believe in reading the self-promoting protestations of Paul Graham, it has never gained much traction outside a few ivory tower settings. If it were going to take the world by storm, it should have done so by now.

The syntax is a major stumbling block for the vast majority of programmers, including a number of very smart people. This is not because of some failing on the part of said programmers. It is a simple by-product of the fact that its primary design goal was not to be a language in which humans can conveniently arrange and express their thoughts. It just wasn't; this was an era where coding in machine language was still common, and where the things language designers could dream up were severely limited by the rudimentary parser and compiler technology of the time.

As time passed and technology permitted, almost all the world came to settle on a certain principle in language design: Things that behave differently should look different. This is not trivial. It is a principle that is guided by the fact that human brains are designed to distinguish things by shape first and foremost. Parsing is more difficult and time-consuming, and so languages that minimize the amount of parsing that humans must perform will be easier for humans to use. There is but one remaining community which holds out against this simple truth: LISPers.

With modern technology we have a new crop of languages, ML and its descendants such as Scala, which adopt and expand on the principles that made LISP stand out so many decades ago. And they have the added advantage of being designed such that different things look different, and so people tend to have an easier time using them. And we see rapid adoption of these languages, and popular opinion agreeing that they are Good and have much to offer. Thus the key thing which makes LISP great finally sees vindication in the world at large, and the idea that LISP championed, the idea that processes are primarily composed of verbs rather than nouns, becomes transcendent.

And yet, there are still so many LISPers who continue to hold out, and refuse to accept this victory, because it is a victory that lacks S-expressions and their trademark parentheses.

And yet, they think it is everyone else who is irrationally hung up on syntax.

[hello_moto]

Are you absolutely sure that Clojure can fit all problem domains? Clojure might be great for MapReduce type of programming. Does it fit a typical Accounting, CRM, Claim management (those kind of business-y app) software projects?

[moomin]

Actually, I really am sure Clojure will fit in all of those problem domains. Indeed, I'm pretty sure that if you experienced a well-written Clojure accounting app, you'd wonder why people bothered with Java.

[CarlSmotricz]

The parentheses are only one hurdle that Clojure makes you jump over, though. The other is Functional Programming.

I read an article here or on Proggit a few weeks ago by a (semi-professional?) game programmer who reviewed his own attempts at writing a real-time arcade-type game (PacMan?) in a functional language. Yes, he got the thing working and it even performed decently but he was irritated that if he really stuck with the paradigm of not having alterable state, some small changes to his app's functionality would entail changes in all kinds of places in the source.

Happily, Clojure gives you explicitly alterable state and a bucketload of mechanisms for working with those. But still, after months of practice I still struggle to get my head wrapped around FP. Typical business software programmers (as I picture them) might have similar troubles.

[hello_moto]

Would like to see the code if you have the example. Would be a very interesting case-study as to why Functional fits such problem domain as opposed to OOP because this would open a new perspective.

Please share more. I'm interested. (Let me know if you can only share your experience via private channels).

[moomin]

Sadly, I can't share any code, but here's my basic observations: First, calling a standard Java object from Clojure is extremely painless. It's a bit more complex if you're dealing with listeners, but in general terms a java object is a java object without very much getting in the way. This means that all of your favourite GUI libraries are usable without modification.

Second, as Carl pointed out, Clojure does have state, it's just tightly controlled. So tightly controlled that multi-threaded programming is much easier. There's some things that I'd like on top of what it does, but it's very powerful and useful.

Thirdly, I'm not denying that thinking functionally takes a while, but as you develop the skill, it's amazing how many things actually look pretty stateless. I've met actuaries who use F# for all of their calculations. Equally, converting game state to a 3d scene graph is a pretty stateless process (although I've yet to meet anyone who's actually getting paid to do functional game programming).

Hope that is interesting. Will be glad to share more.

[Roybatty]

Even though Kotlin is still essentially vaporware for those outside Jetbrains, we know that it'll have at least decent (if not great) IDE support right off the bat when the alpha/beta is released.

I think that Kotlin could be the Java successor that Scala never will be.

[theshadow]

Please please please baby jesus let me have a dollar every time someone says 'Language X, not language Y is the java successor'

[Roybatty]

The difference is that we won't have an Emacs/Vim plugin for years and years after it's initial release. Plus, it's not a dynamically typed language and not Scala

[eropple]

IIRC, JetBrains will also be providing an Eclipse plugin (though turning it over to the community after initial dev).