 The closure language was created by Richie Key and was first released in 2007, since then the language has seen significant improvements and the current release as of summer 2014 is version 1.6. Before getting into how to use the language, we are first going to discuss what makes closure unique. The first thing to understand about closure is that it is a dialect of Lisp. Lisp, created back in the 1950s by John McCarthy, was the first language to introduce a host of ideas common in languages today, including first-class functions, garbage collection, and dynamic typing. The original Lisp language wasn't used for very long, but many imitators took its place. Sometime in the late 60s, some of these dialects of Lisp incorporated macros. A macro is a function that takes source code as input and returns source code as output. Before compilation, the macro invocations in your source code get replaced by the source code which they return. With macros, we can remove boilerplate repetition in our code. Now, some non-Lisp languages have their own version of macros, but none have the power of Lisp macros. The C language preprocessor, for example, has macros, but thanks to the complex nature of C syntax, macros and C are tricky to write, not very flexible, and can easily produce broken code. In contrast, Lisp syntax is extremely simple, making macros and Lisp easy to write, quite flexible, and unlikely to introduce mystifying errors. So, that's the first appealing thing about closure. Like other modern dialects of Lisp, closure has a powerful macro system unlike anything found in non-Lisp languages. What really makes closure compelling, however, and what sets closure apart from all other languages, is closure's unique approach to functional programming. In case you're not familiar, let's first explain what functional programming is. Functional programming is a style of programming in contrast to what's called imperative programming. The key distinction between functional and imperative programming is how they treat mutable state. Mutable state, in short, is any kind of data that may change. For example, if a variable can be reassigned to new values, that variable is mutable state. If an object's field can be reassigned to new values, that object is mutable state. If the elements of an array can be reassigned, that array is mutable state. Any piece of data which is allowed to change is mutable state. In imperative programming, we use mutable state whenever we find it convenient. But in functional programming, we avoid using mutable state as much as possible. The reason to do so is that if a function doesn't use any mutable state, it is then referentially transparent. When a function is referentially transparent, it always does the same work and returns the same value when invoked with the same set of arguments. Such functions are sometimes also called pure, in contrast to impure functions. An impure function might do different things when invoked with the same set of arguments because the function might rely upon mutable state outside the function, such as a global variable. Moreover, an impure function might modify mutable state somewhere, such as a global variable or a field of one of its arguments. The sum effect is that the caller of an impure function must be mindful of more than just what value the function returns because the function might do much more than just return of value. Meanwhile, the author of an impure function must be mindful of how the function's business might affect other parts of code. So this is the key virtue of functional programming. Without mutable state, a function is truly modular because it can be understood entirely in isolation without consideration of how it might affect or be affected by other functions. Now, this may sound great, right? But you're probably scratching your head wondering how we can ever get work done without mutable state. Programming without mutable state sounds impossible until you realize that we are still free to create new data. So instead of, say, modifying an existing object, we can create a new copy that is just like the original but with the modification. Likewise, instead of modifying an existing array, we can create a new copy of that array which is the same as the original but with the modification. For example, if you have the list 1, 2, 3 and want to modify the second element to be the value 7, we needn't modify the existing list but instead can create a copy that has the modification, so we end up with a new list 1, 7, 3. We still have the original unchanged list but now we also have a new separate list. So by making modified copies in this manner, we can avoid ever mutating any objects. An obvious objection, however, is that copying lists every time we want to modify them might be unreasonably expensive. If a list has 1 million elements, it would be enormously costly in memory usage and CPU time to copy all 1 million elements any time we want to make a simple change to the list. To solve this problem, Clojure has persistent collections. A persistent collection is a collection type where the instances are immutable but implemented in such a way that allows for efficiently creating modified copies. In brief, the common elements of the original and the copy are shared in memory and so needn't be copied. For example, if I append an element to a persistent list, the new list shares in memory all the elements of the original list and so those elements needn't be copied to create the new list. If we exclusively use persistent data structures, all of our data can be immutable yet still reasonably efficient. That solves one problem of functional programming but we still have one big sticking point, input and output. Our functional code endeavors to avoid dealing with any mutable state but the world outside of our program like files on disk, network resources, user interaction devices like keyboards and displays, all of that stuff is inherently mutable. If your program reads or writes files or draws on the screen, it is inherently dealing with mutable state. Other functional languages like Haskell and Scala solve this problem with a special data type called a monad. A monad type encapsulates state changes while appearing stateless to the rest of the program. Arguably the code inside a monad is not functionally pure but monads effectively allow us to sneak impure code into the context of pure code. Explaining exactly how monads work is infamously difficult. Fortunately for you though, closure doesn't have monads or any equivalent because unlike Haskell and Scala, closure doesn't try to enforce functional purity. Any closure function may do stateful work, i.e. any closure function may be impure. Just be clear that for your closure code to enjoy the benefits of functional programming, most functions in your closure code should be pure. In truth, functional programming is really about constraining the use of mutable state, not eliminating the use of mutable state entirely. We ultimately need to work with mutable state somewhere in our code for our programs to do anything useful. Rather than force a strict separation between pure code and impure code, closure simply leaves it up to the programmer to keep the proportion of impure code to pure code small. So a typical closure program is going to have some amount of mutable data. One major difficulty with mutable data is coordinating its use across multiple threads of execution. Threads of execution can easily mess each other up when they share mutable data because one thread might modify the data in a way that the other threads don't anticipate. To address this problem, closure provides what it calls reference types. A closure reference is like a mutable collection that stores just one element and the operations that access and replace the element of a reference ensure some kind of coordination across threads. We'll get into the details later, but the gist is that references allow us to synchronize threads without using locks, which are notoriously cumbersome and error-prone. Closure is intimately connected to Java. Not only does closure compile to Java bytecode so as to run on the JVM, every closure data type is defined in terms of Java classes. Effectively, code in either language can invoke code of the other. Invoking Java code from closure is especially convenient because closure has special syntax for doing so. In fact, closure makes invoking Java so convenient that closure standard library simply defers to the Java libraries for some core functionality. For example, reading and writing files in closure is done by simply using the existing Java file classes. Closure's creator Rich Hickey views traditional object-oriented programming with skepticism, and so despite closure's close connection to Java, the data types we create in closure have no notion of inheritance or encapsulation. The one part of object-oriented programming which Rich Hickey does like is polymorphism. So closure does include mechanisms for creating functions that vary their behavior based on the number and types of the arguments provided to a call.