I'm not sure if focusing on syntax and succinctness is such a great approach though. When I've discussed Clojure with colleagues familiar with Java, they've been more interested in the concurrency support via immutable data structures and reference types, which really sets Clojure apart from other Lisps. I think it's a much more compelling sell that way, since Java programmers seem to be attached to Java's syntax and static typing, but are aware of how difficult it is to write correct concurrent code. YMMV of course.
I agree. A good way to sell Clojure to an experienced Java programmer is to ask him has he ever serialized data to a string for passing it around in a program, and why. Then when he explains how the semantics for all the composite Java types except for string suck, tell him that every type in Clojure just works right, like string does in Java.
Why would anyone do that? We use immutable collections, immutable value objects, unmodifiable views and deep/shallow copies, but never serializing data to a string just for passing it around. I think most experienced Java developers would go for the type-safe alternatives.
> I'm not sure if focusing on syntax and succinctness is such a great approach though.
Depends on the audience I'd guess, considering bug-proneness is an almost direct function of LOC (at equivalent skill levels) it can be a pretty interesting note.
Though I'd agree that concurrency prowess should be higher on the list, especially in SOA companies.
Sure, i's an interesting note, I just don't think one should lead with it. For instance even as someone who's a fan of Clojure, my immediate reaction to the example with Map<String, String> was to think "that's not really equivalent since the Java example is more typesafe". I just think it might invite unnecessary digression, especially since Java programmers have been hearing about more concise dynamic languages for years.
It's definitely hard to sell a new tool based on an intermediate advantage (less LoC) alone. You have to sell the whole package (of experience).
When Rails came out, it offers more than just RAD for building web but it also offers integration with the 2 most commonly tasks in building web-application: DB migration and Automated Testing. That strikes to the heart of any type of applications be it enterprise or one-man-show.
Ruby community can't sell Ruby because of its syntax alone by saying that it looks like English (keep in mind that Ruby was invented somewhere in the mid 90's era and didn't exactly known until Rails).
We're seeing the same trend here: promise of concurrency. I also would point out "leiningen" as a build/packaging tools as part of the selling point: there are some portion of Java developers that would swear by Maven (including me, despite its quirkiness/complexity) as the killer app/framework/tool for Java. Leiningen fills that gap for these individuals.
Comments
This example is missing the corresponding Clojure code, which is important for Java interop:
I'm not sure if focusing on syntax and succinctness is such a great approach though. When I've discussed Clojure with colleagues familiar with Java, they've been more interested in the concurrency support via immutable data structures and reference types, which really sets Clojure apart from other Lisps. I think it's a much more compelling sell that way, since Java programmers seem to be attached to Java's syntax and static typing, but are aware of how difficult it is to write correct concurrent code. YMMV of course.I agree. A good way to sell Clojure to an experienced Java programmer is to ask him has he ever serialized data to a string for passing it around in a program, and why. Then when he explains how the semantics for all the composite Java types except for string suck, tell him that every type in Clojure just works right, like string does in Java.
Why would anyone do that? We use immutable collections, immutable value objects, unmodifiable views and deep/shallow copies, but never serializing data to a string just for passing it around. I think most experienced Java developers would go for the type-safe alternatives.
Could you explain what you mean, for someone who does not know much about java?
Mmm, all the verbosity of java with all the headaches of sh...
> I'm not sure if focusing on syntax and succinctness is such a great approach though.
Depends on the audience I'd guess, considering bug-proneness is an almost direct function of LOC (at equivalent skill levels) it can be a pretty interesting note.
Though I'd agree that concurrency prowess should be higher on the list, especially in SOA companies.
Sure, i's an interesting note, I just don't think one should lead with it. For instance even as someone who's a fan of Clojure, my immediate reaction to the example with Map<String, String> was to think "that's not really equivalent since the Java example is more typesafe". I just think it might invite unnecessary digression, especially since Java programmers have been hearing about more concise dynamic languages for years.
It's definitely hard to sell a new tool based on an intermediate advantage (less LoC) alone. You have to sell the whole package (of experience).
When Rails came out, it offers more than just RAD for building web but it also offers integration with the 2 most commonly tasks in building web-application: DB migration and Automated Testing. That strikes to the heart of any type of applications be it enterprise or one-man-show.
Ruby community can't sell Ruby because of its syntax alone by saying that it looks like English (keep in mind that Ruby was invented somewhere in the mid 90's era and didn't exactly known until Rails).
We're seeing the same trend here: promise of concurrency. I also would point out "leiningen" as a build/packaging tools as part of the selling point: there are some portion of Java developers that would swear by Maven (including me, despite its quirkiness/complexity) as the killer app/framework/tool for Java. Leiningen fills that gap for these individuals.