Chas Emerick

Good find. FYI, I never released my propagator implementation; it was part of a closed-source commercial project years ago (using probably pre-1.0 Clojure, if memory serves).

Arjun Shastry wrote:Thanks Chas.
Like c++ and other languages, does clojure has any one standard body responsible for its specification,libraries?

The organization around Clojure roughly follows that around Python, Ruby, and other languages that are not the result of a single company's efforts. The reference implementation is guided by Rich Hickey (its creator), with the bulk of the work done by him and Clojure/core, which he heads. Contributions (patches, documentation, etc.) also come from the community via a patch process.

The libraries are almost entirely community-driven; thus, each one is managed by its author, usually with the help of 1-1,000 other contributors from the community.

At this point in time, I think it's taken as a given that standards bodies are generally not an ideal way to develop new languages. Perhaps after some extended period of real-world use, a language might be submitted to a standards body (here I'm thinking of C#), but I wouldn't bet on that being commonplace, either.

Dan King wrote:I've been learning/using Clojure for a few months now. While I'm comfortable with it, I still find myself trying to address problems as I would using Java, Ruby or Groovy only to later ask, what's the "Clojure way?" I'd appreciate suggestions on books and/or presentation that can help me with adjusting to the paradigm shift. Thanks.

Well, we do what we can in the book, but I wouldn't be too concerned about your falling back to prior habits just a month or two into learning/using Clojure. These things take time; I'm guessing that it took many months for you to really understand the "Java way" or the "Ruby way". Just keep reading, programming, and looking at well-written Clojure projects for hints at good form.

A great resource for this is the community around 4clojure, which often shares solutions to the problems there. Just remember that shorter isn't necessarily better; sometimes, it's fun to golf your way to a shorter solution, but too much concision can be too clever for its own good. :-)

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Interesting thought! I implemented propagators some years ago (sometime soon after seeing Alexy Radul speak at a Lisp conference at MIT ~2009?). My implementation was mostly a direct port, but I used Clojure's agents to maintain propagator state.

If you use Clojure's transactional memory, then you'll end up using refs for propagators (refs are the only reference type that directly participates in transactions). In terms of tracking the changes to each ref, watches (see add-watch) will do the job. Note, however, that watches will be notified only once for a change in a ref's value in a transaction; the ref's in-transaction value may have changed multiple times, but those "events" don't escape into the world outside of the transaction.

Good luck! By all means, post to the main Clojure mailing list with a link to your implementation. :-)

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Arjun,

Clojure provides stellar tools for consuming, transforming, and emitting XML.

clojure.xml is a core namespace that defines the most common way XML is represented in Clojure (essentially, each element is a map with three slots, for its tag, attributes and content).

Enlive (by Christophe Grand) is a library that allows you to functionally transform XML and HTML. It's billed as a templating engine, but really is an excellent generalized tool for any kind of XML transformations you need to do; we talk about Enlive in the web chapter of the book. Enlive is built on top of clojure.zip — an implementation of Huet's functional zippers — which is generally useful in terms of efficiently and concisely traversing and modifying immutable data structures.

Writing web services is one of the most common popular use cases for Clojure. The book guides you through writing one using Ring and Compojure, although there are higher-level libraries and frameworks that you might find useful as well, including Noir and Bishop (the latter of which is a very promising Clojure implementation of webmachine, a great foundation to build upon if you are aiming to write properly compliant HTTP web services).

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Palak Mathur wrote:Chas/Sean,

My current job includes creating integration solutions for our client using ESB concept. We are using proprietary products from a company. We are planning to do away with the products as license is coming to an end and develop our own solution. We had something like Spring Integration framework in mind. Does Clojure has any library that we can consider? We are currently analyzing the current libraries/framework that can support this thing.

You can certainly use Clojure in a Spring (or JEE 6 or similar) application, if that's the underlying architecture you plan on pursuing.

There isn't a Clojure analogue of Spring, largely because the dependency injection (DI) pattern that underlies Spring is fundamentally boilerplate that exists to work around limitations in Java. In the 'Design Patterns' chapter, we talk some about achieving the same objectives as DI in Clojure, but without the complexities of managed beans, containers, and so on.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Especially if you are familiar with the JVM, then I think Clojure is an excellent first Lisp.

If you'd like to stray into other flavours, then Racket is an excellent choice (and Dr. Racket is an excellent dev environment). Alternatively, Gambit Scheme might be attractive insofar as clojure-scheme compiles down to Gambit (and thereby to C). I don't think learning these will help you learn Clojure; but, they do do certain things differently that will nevertheless be useful to you in helping you think through various kinds of problems.

Ari King wrote:Chas, thanks for the insight and various perspectives. It was very helpful.

Sean, thanks for the macro example. Do you also happen to have an example demonstrating Clojure's DSL capabilities via macros?

Korma and Enlive are two libraries that provide what can be described as DSLs. Of course, that being the case, neither library's source is particularly small or easy to understand. Though, if you do the work to understand either (Enlive is particularly well-constructed IMO; I've not browsed around Korma's source enough to say either way), you'll be the better for it.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Jan Goyvaerts wrote:AHA ! NOW we're getting somewhere. :-)

Does that imply Clojure is more adequate for maths and statistics ? Compared to Java that is. Because *that* is something I can sell to IT managers.

In my branch Fortran is still much appreciated by the academics who're writing algorithms. Would it beat Fortran on the JVM for example ?

Is there an efficient Fortran on the JVM? I know of Fortress, but that's obviously only inspired by Fortran.

Yes, anyone that often reaches for Matlab or Mathematica or R to do statistical/maths stuff, but would like to be in a JVM environment, will likely find the Clojure/Incanter combo to be pretty compelling. Using Java for anything that these tools are used for would be straight up insane. (Not that it hasn't been done.)

However, are there any domains where Java is "more adequate" than essentially any other widely-used JVM language? Clojure will outpace Java in maths and stats work, web development, thick client dev (using either Swing via seesaw or JavaFx, infrastructure automation, "big data" stuff (e.g. driving hadoop with cascalog), and so on.

(FYI, I run a yearly 'State of Clojure' survey every year; some here — and some of your bosses ;-) — may find last year's results interesting.)

Anyway, this is the point I was trying to make earlier; any hesitation around using Clojure or Scala or JRuby, et al. is related to social and organizational factors, not whether these languages are worlds better than Java or not. For my part, I'll use any of them instead of Java; I know that my business will outrun any competitors and not have to absorb any opportunity costs due to my tech stack.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

Jan Goyvaerts wrote:Are there engineering applications of Clojure ? My company works about optimization in engineering with lots of maths involved.

Indeed; check out Incanter, "a Clojure-based, R-like platform for statistical computing and graphics". There's scads of people using Incanter for absurdly interesting things; though, as you can imagine, most don't make much noise about it, given the industries they work in (finance, engineering, etc.).

There's also Clojuratica, a Clojure front-end to Mathematica, although it doesn't look like it's been maintained as of late.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

I personally still use clojure.test almost exclusively, although I've now started using test.generative in conjunction with it, which provides for the generation of data for input to tests that match whatever criteria you set. (This can be thought of as the Clojure equivalent to QuickCheck and ScalaCheck, for Haskell and Scala respectively.)

As Sean said, there is Midje and Lazytest and Expectations, all of which take different tacks at testing in general, and a couple of different shots at test watching and such. I'm afraid I can't recommend one or the other of these, as I've not used them; however, their pedigree (i.e. coming from former [current?] Ruby programmers) means that they're likely to support the kinds of TDD workflows you'd expect.

I think Clojure's REPL is the best playground for testing for my money. Having programmed in Python for years prior (and Scala after that), I was very comfortable with interactive shells and interpreters, but a proper REPL gives you a great deal of power to test and experiment with code, IMO far more than any particular testing methodology or framework. The REPL is so important, we devote a whole chapter to "REPL-Oriented Programming" in the book, and the first chapter (available free online) introduces the Clojure language by way of understanding how the REPL works from top to bottom (since, once you understand the REPL, you largely understand how the language itself works).

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

95% of all of the programming you're likely to do in Clojure is going to be working with functions and data.

On the margins, you'll likely find some repetitive code or boilerplate that you'll want to eliminate from your main sources; in such circumstances, wrapping up that code into a macro that you can stuff off into an auxilary namespace will clarify the flow of the main narrative of your program. These macros aren't defining DSLs by any stretch — really, they're just straightforward code templates that happen to be part-and-parcel of the language itself.

Finally, there may be occasions where you really do want to introduce a particular notation (a.k.a. a DSL). And then, you will find the full power of macros to be a lifesaver. One thing I'd like to emphasize is that, the macros you build in this context should simply be sugar for core functionality implemented (and available!) as functions. Since one of the tradeoffs of macros that they cannot readily be composed as easily as functions, you always want to have your macros' functionality available via regular functions (perhaps at a lower level of abstraction if necessary).

All that said, you shouldn't avoid macros; rather, it's best to use them judiciously. For some other perspective on them, you might want to watch talks by Christophe Grand (one of my fine coauthors) and Michael Fogus.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

I would second Palak's suggestion; Mark Volkmann's mega-article on Clojure is a great read, and excellent introduction and reference.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

chris webster wrote:What's the situation with tools to support debugging?

You've mentioned the relative ease with which code can be generated in Clojure, but how easy is it to inspect and step through this generated code at runtime?

Any JVM debugger can be used with Clojure code, as line numbers and filenames are included in the bytecode generated by Clojure by default. For example, you can set breakpoints in Clojure source files in Eclipse + Counterclockwise, and when execution pauses at the breakpoint, you can step into, over, and out of function and method calls, inspect locals, etc. The same goes for IntelliJ's Clojure support, and other debugger tools like JSwat.

One wart there is that Counterclockwise does not yet provide presenters for the Eclipse debugger UI to show Clojure collections pleasantly; so, if you have a map argument in a function that execution is paused at, the value shown in the debugger's inspector is Clojure's map implementation class, not an e.g. browsable tree representation of the map's entries. This item is fairly high on the TODO list for Counterclockwise.

Note that this presenter issue is an area where Emacs + SLIME currently does very, very well.

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)

You're calling the square function slightly wrong (you're passing a vector containing a number, and not a number; watch the brackets), but I actually get a different error than you (java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to java.lang.Number).

It sounds like your TryClj session might be hosed, or the site was having issues at the time? Maybe try again.

FWIW, here's a session copy/pasted from TryClj:

Clojure> (defn square [x] (* x x)) #'sandbox25629/square Clojure> (square 5) 25 Clojure> (square [5]) java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to java.lang.Number

--
(coauthor of Clojure Programming from O'Reilly; creator of Clojure Atlas)