Clojure for Java Programmers Part 1 - Rich Hickey

> So that's how I view Lisp macros - creating code on the fly and executing it. This is an incorrect assumption. In compiled Lisps[0], macros are a compile-time construct, which manipulate the data structures that represent your code[1]. All manipulation occurs at compile-time. In interpreted Lisps, macro evaluation is temporally intertwined with program execution, but the two phases are logically distinct. [0]: Compilation time in a Lisp is not necessarily similar to compilation in other languages. Working at a REPL does not imply that interpretation is happening. Clojure is an example of a Lisp that is exclusively compiled. Even when sending individual expressions to the REPL, they are compiled before being evaluated. [1]: From a reply elsewhere in this thread: ▶ this video See this video for an overview of the core of Clojure. The link starts with an overview of Clojure's data types and data structures (skipping the intro for the reasons behind Clojure). This leads directly into the evaluation model, which is based on the data structures of Clojure. Watch through ~1h:30m to get a feel for what macros are used for in Clojure's core. This gives a very good overview of the evaluation model for macros; this is generally applicable to Lisp macros outside of Clojure as well, though there are nuances to different dialects. I recommend that you start at the linked time, but if you want to jump straight to the evaluation model, you can jump to ~47m.

From a Clojure perspective, here are a few things to think about and explore to help understand where the power and value of macros lie. 1. Clojure does not have all of its various conditionals as language built-ins. There is a single conditional construct built in to the language, if. The rest are all defined in terms of if. Function arguments are eagerly evaluated in Clojure. How do you write a short-circuiting function in Clojure? (when predicate consequent) as a function must evaluate both the predicate and the consequent. If consequent is slow to calculate then your whole when expression is as slow as consequent, even if predicate is false and we do not need consequent. when is a Clojure macro based on the if special form. 2. core.async is a mere library.[0] This implements CSP (same idea as Go's channels) and async programming (the sort of stuff that needs compiler support in other languages such as C# or Go) as a library. If Rich Hickey didn't write core.async, you could build this control flow yourself for async programming. In fact, you can create arbitrary control flow mechanisms using macros. Common Lisp's entire object system can be implemented in macros. 3. The only special forms in Clojure are def, if, fn, let, loop, recur, do, new, ., throw, try, set!, quote, and var. The rest of what you would consider the core of Clojure consists of functions and macros. Much of the control flow functionality is implemented in macros.[1] The core of macros is that they allow

> I'm explaining why Lisp is hard to learn. It is not hard to learn in general, there are too many counterexamples of people of all sorts and skills learning it without these issues you are having, learning it as their first, learning it later in their careers... (CL is big , I'll give you that, but each piece can be chewed one at a time and does not seem to be individually that difficult.) So I can hypothesize why it's hard to learn for you . My first guess is still that you aren't meeting Lisp in its own terms and are trying to make Lisp fit your mental model of some other language and its ecosystem. This isn't going to work, and the failure mode (if I'm right) has nothing to do with Lisp but with biases in general heuristics of learning. You don't need to "unlearn" the way you're used to doing things, but you do need to separate yourself from it for a bit until you actually grasp the Lisp (and its ecosystem's) way(s) and can then see the connections, tenuous and non-existent as some may be. I'll risk raising some of those connections below, but really, things need to be understood on their own terms first or you wind up with misconceptions. (I've seen it multiple times with Java/Python programmers getting confused at the other's "import" statement.) > strange terminology It's not Lisp's fault that it's old. Being old means it will have terminology that may be alien to what we have today with nothing today being a perfect fit, or alternatively sometimes it expresses mostly

Lisp has only one rule called the Operational Form: (operator arg1 arg2 arg3 ...) The Operational Form is just a list denoted by parentheses. The operation or 'function' comes first, followed by its arguments or operands, e.g. (+ 1 2 3) => 6 The + symbol resolves to the plus function and is passed in the arguments 1, 2 and 3. Nested forms are evaluated inside-out: (+ 5 (- 10 6)) => 9 Traditionally, Lisp only has one data literal: `(linked lists)`, but Clojure adds `[square brackets for vectors]` and `{:curly brackets}` for hash maps. The colon denotes a keyword, which is a symbol which only ever resolves to itself and is commonly used for labeling things, e.g. keys in a map. Notice how the operational form is just a list with some symbols and data literals. In Lisp, the syntax for writing data structures and the syntax for writing code is the same syntax . And since a function operates on data and produces new data, what if a function could operate on code and produce new code , since code is just data? We call such a function a macro (and I don't mean Excel macros). Macros run at "compile-time" (technically 'read time') and the code output is executed at "run-time" (or during 'evaluation'). The benefit of macros is that if your language is missing a feature, you can add it. You can see this in practice by looking at the source code for the `and` and `or` logic functions in Clojure, which are typically built-ins, but in Clojure they are just macros bootstrapped on top of the

Same here, I never understood Java interfaces, abstract classes, and a ton of other "features" but picking up Clojure was a breeze. I don't understand why complicating thing that supposed to be simple helps you by any mean. On the top of that, I have seen several cases when Java programmers tipped over in their own code because of the complexity that they thought they understand, except there was a particular case when it was doing something else then expected. Reasoning about Clojure (LISP) code is always easy because if you follow best practices you have small functions with very little context to understand. On the top of these, I see the ratio of LOC 50:1 (worst case even higher) for Java : Clojure code that does the same thing. Usually people get triggered and say why does it matter, but in reality less code is better for everybody. Easier to understand, less chance of errors, etc. Correctness was long time lost for majority of Java developers, just put out a survey and you can see it for yourself. It is also pretty common practice not to handle exceptions well and just let a DNS not found error explode as an IOexception and good luck tracking down what caused it (literary happened to me). I understand that the average Java dev does not see any value in LISP (Clojure) but it silly to expect that the average of any group is going to lead the scientific advancement of any field including computer science. One tendency that you can see if you are walking around with open ey

Indeed. Rich Hickey's 2-part presentation on "Clojure for Java Programmers" was a really slick presentation of a Lisp. (Focusing on the 'code is data' aspect from the beginning (at least once he starts talking about the language specifics themselves, he does spend a while motivating dynamic languages) rather than talking a lot about just higher order functions and macros and so on. He goes over the evaluation model and its difference from a Java/C++ model, he shows how to interop with Java... It's just a great talk.) Part 1: ▶ this video Part 2: link Slides: link