order.getLineItem(2).getQuantity();
(get-in order [:lineitems 2 :quantity] 1)
The first is simple enough, but it's essentially a DSL. No code that doesn't know about that API can work with those objects. If I want to guard against null objects I have to re-do that sort of work over and over again.
Contrast with the latter, where the get-in function just treats the subject as a nested associative structure. It can handle the null checking, and it doesn't care what my keys look like.
I have to admit, the first line looks like better code in my eyes. The only "advantage" of the second one is that it "handles" null checking. Which really means that I still need to handle what happens when order is null, versus, the non existence of line items, or the non existence of quantity.
The only real advantage I see from the second line version is that I can write that code and run a partially completed program, that for example doesn't have a notion of orders at all -- and the program can still run. But I guess this just boils down to preferences.
When I briefly used Clojure, I was very impressed with clojure.set. (Probably the "relational algebra" Hickey mentioned in the interview, with operators like project, rename, join, etc. Stuff that anyone who knows SQL will be familiar with. A good example of what such abstractness buys you.)
