Will Clojure be popular among Java programmers?

[Rogerio Kioshi]

Do you think Clojure will be popular among Java programmers?

[Mohamed Sanaulla]

I had seen the syntax once- and was afraid after seeing the number of brackets Dont know how other java programmers feel.

[Hauke Ingmar Schmidt]

Well, at least on my keyboard layout the round brackets are much better to produce than angled or curly ones. But I agree, promoting a reduced syntax as positive and then presenting this as the alternative is a bit weird.

[Hussein Baghdadi]

Syntax familiarity comes with time, no matter of language you are using.
There isn't any thing magical about Ruby, Java or Scala syntax. It is all about time and habit

[Amit Rathore]

One of the most common misgiving among programmers who see Clojure for the first time is the syntax. The trick is to understand why the syntax is the way it is, and then to evaluate the cost-benefit yourself.

The reason Clojure syntax looks like that is because it is processed differently by the runtime. Typically, most languages interpreters or compilers read the source code, then convert it into executable byte-code or machine code. There is no programmer control once this conversion process begins, and any code that was written in the source file is what runs.

Why should things even be any different, one might ask. Consider this: Clojure processes the code differently. It first reads the code and converts them into a data-structure. This data-structure is then evaluated to "run" the program. The neat trick, however, is that the programmer has control over this data-structure. The programmer can transform it into anything she wishes. This allows for incredible meta-programming capabilities, far beyond what even dynamic languages such as python or ruby can offer.

This programmatic manipulation of the code by the code itself, is what the famous LISP macro system is all about. It is directly dependent on the syntax, since the syntax is essentially the AST itself. If one desires this level of power, and it is often needed in systems of non-trivial complexity, then a LISP is perfect. When combined with all the features of Clojure (multicore concurrency, JVM-support, functional paradigm, etc.) it is an amazing language for modern software development.

Hopefully, all this balances out the syntax-issue.

[Igor Mechnikov]

This question makes sense if I accept that different programming languages may be better suited for different individual temperaments.
Is there a particular type of individual who might prefer Clojure?

[Amit Rathore]

I do believe Clojure is more suitable to those programmers that want to (or need to) build dynamic systems.

Dynamic systems are those that need to adapt to changing requirements constantly, both at design (development time) as well as during run-time. For example, at Runa, our system is mostly written in Clojure (about 90%) and is composed of a family of DSLs for various pieces. It allows even our customers to completely re-wire things according to their own business rules. We allow this extreme level of customizability for two reasons: 1. every merchant is different, and 2. we ourselves don't know what and how the system will *really* be used in the field.

This way, we build the core concepts, and allow our customers to essentially wire things together as they please. Our support staff speaks this DSL, and can help customers as needed. We also have a DSL which allows us to debug and get more diagnostics out of the system. And none of the DSL changes needs us to restart anything - it all just works at run-time.

So to answer your question, it's less a question of temperament, and more about the requirements and demand for flexibility. However, Java programmers that are interested in other JVM-based languages such as JRuby, jython, and Groovy will find the transition easier. However, I know a lot of folks who have gone straight from Java to Clojure, and some who went to Scala first, and then to Clojure.

[Hauke Ingmar Schmidt]

Hej,

thank you.

While I agree that there is no magic in any syntax and you have to get used to any given syntax, there are decisions made when designing it. It may be that an opening bracket without ambiguity can replace one of "function"/"procedure"/"begin"/"while"/"do"/"for"/..., given the context. That does not automatically mean that the one-symbol-solution is superior to the "verbose" variant. It is a compromise, based on the goal of the syntax design.

Clearly the Lisp/Clojure design tends to be more machine-friendly (for the reasons you said, maybe it is even a necessity) while other languages try to be more human-friendly; SQL or Cobol are on the other end, Ruby is said to be designed as an all-purpose-language with no concessions to the machine (but even there you can't just read the code).

The way Clojure deals with dynamic code / code as data is one way to do it. Complex system can be (and are) built with different approaches too. So I guess when you decided to use Java (which is a compromise language, no doubt) I think it is not that easy to switch - you gain a lot, but you loose a lot of things that may have been the very reasons why you choose Java in the first place.

P.S.: Not to nitpick, but the XML sample in the free chapter (pp.9) where you derive the Clojure syntax from XML, is not well-formed XML, the attributes need to be quoted.

[Mohamed Sanaulla]

Thanks a lot Amit, that was quite a detailed explanation.
Agree that syntax issues can be resolved much easily

[Huahai Yang]

As a Java programmer since 1997 (with prior experience in Pascal, C, Assembly and various scripting languages), I recently successfully transformed myself into a Clojure programmer, and I am not going back. So it is certainly possible for a Java programmer to love Clojure . During my transformation process, syntax was not the main obstacle since the Clojure syntax is actually a lot more regular and predictable than Java. The main problem for me was to learn the functional way of thinking. Unfortunately, reading books and reading other people's code won't help too much here, the only way to learn functional programming is to write functional code yourself. It is like learning math. What I did was to do exercises on 4clojure.com and avoided the use of loop. I also got myself very familiar with the core sequence functions of Clojure core, and read the source code of those functions. After a while, functional way of thinking becomes natural to me.

[Sean Corfield]

Mohamed Sanaulla wrote:I had seen the syntax once- and was afraid after seeing the number of brackets Dont know how other java programmers feel.

I'll respond with the answer I gave to this concern in the Clojure for teams thread:

Sean Corfield wrote:This seems to be a common push back but I think it's mostly perception. A function call in Java has a pair of parentheses, a function call in Clojure/Lisp has a pair of parentheses. A code block in Java has braces, in Clojure/Lisp it has parentheses (and it could be argued let has both () and [] but that's only one extra set of delimiters - and you don't have any of the other Java punctuation in Clojure/Lisp). A conditional in Java typically has () and two {} as well as internal () for function calls, a conditional in Clojure has just the enclosing () - any internal () are due to function calls that would also be present in Java. Arithmetic is where you see extra parentheses in Clojure/Lisp because operators are just regular function calls (but even there, any parentheses in Java for grouping do not cause additional parentheses in Clojure/Lisp).

In reality, once you get working with Clojure regularly, the parentheses pretty much become invisible (assuming you use an editor that auto-balances them for you, such as the CounterClockWise plugin for Eclipse).