The Clojure team has always done a nice job expressing the rationale for specific language features, and these rationales often lean towards solving problems that system designers historically faced.
Oftentimes, I think folks think of modern languages in regard to their syntax, tooling, ergonomics, etc; however, to me, the more interesting benefit in adopting a modern language is in how its inbuilt features address design problems that earlier generation languages exposed.
For a real world example of what I'm talking about, you can google "clojure expression problem" and find compelling articles about how Clojure solves this with protocols.
Providing a toolkit for attacking categories of problems inherently gets people focused on the fact that these problems exist in the first place when they may not even recognize them otherwise, and regardless of the choice of language, it leads to better design oriented thinking in the context of larger and more complex systems.
Strictly speaking the expression problem is only defined for _static_ type systems because its concerned with _static_ type safety and extensions without recompilation.
There are several motivations for protocols:
Avoid the 'expression problem' by allowing independent extension of the set of types, protocols, and implementations of protocols on types, by different parties
I agree that it's a concern in static type systems, but the same issue rears its head when defining methods which operate on specific types of strongly typed data, so no, it's not always trivial, nor is it a problem exclusive to statically typed languages, and if it was, there wouldn't be a need to introduce a new abstraction for which addressing the problem is a key goal.
I've got some experience with functional languages, and a good amount with functional features in OO languages. Started learning Clojure this week, and was pleasantly surprised with how quickly I could get working projects up and running. Less upfront learning curve than Elixir, which was unexpected.
1) default immutability (same simple data structures used in every library -> ecosystem composes better)
2) portable code across multiple host platforms (jvm, node, browser)
3) metaprogramming
IMO, in 2007, immutability on the JVM was a competitive value prop, but in 2021+ it is nothing special. It is the combination of the three things which is a competitive value prop today. Metaprogramming in particular is a mostly unexplored frontier, because it is very hard to do well, and very easy to do badly. Default immutability is kind of a necessary starting point to do metaprogramming well.
Can you elaborate on this? What do you think has changed in that time to make it "nothing special"?
The doto macro was a relief back in the days when Java APIs insisted on being designed around stateful setters and getters rather than the builder pattern, it allowed you to operate on such unfortunately designed objects in single logical blocks and simulating it all being an expression.
Proxy allowed you to instantiate anonymous inner classes implementing only the methods of an interface that you needed, the rest you could omit; in Java you have to put them all, empty, which necessitated that you use an IDE to generate them, and back then IDEs were not as nice as today.
Those two alone made interacting with contemporary Java libraries so much easier.
It also was convenient to go from Java collections to Clojure collections and vice versa.
-- Guy Steele
I've worked in multiple Clojure shops and it has always been amazing.
All the core code and business logic etc. (kernel) is implemented functionally, and the interface with the outside world (shell) is implemented imperatively.
Clojure being a horrible language is a really hot take and it being based on hearsay makes your coomment look like it's not in good faith.
I do not know where your views are coming from, sounds like 2nd hand experience rather than 1st one.
When I compare Clojure to another functional language I know well, Haskell, one of the things I really feel it lacks is proper pattern matching and currying; yes there are libraries that you can use, but it’s just not idiomatic to do in Clojure. I would not, however, assert that it’s an imperative language.
Could you care to elaborate on what exactly you find is lacking in Clojure?
[1] https://clojuredocs.org/clojure.core/let#example-542692c7c02...
(let [a 10
a (+ a a)
a (+ a a a)]
a)
(let [a 10]
(let [a (+ a a)]
(let [a (+ a a a)]
a)))
(+ (+ 10 10) (+ 10 10) (+ 10 10))
And this is different to the imperative style, because in imperative you can do:
int a = 10;
a = ++a + ++a;
(let [a 10
a (+ (inc a) (inc a))]
a)
This is the difference between the variable substitution evaluation semantic of lambda calculus and the imperative semantics.
(let [a (take 5 (range))]
(let [{:keys [b c d] :or {d 10 b 20 c 30}} {:c 50 :d 100}]
(let [[e f g & h] ["a" "b" "c" "d" "e"]]
(let [_ (println "I was here!")]
(let [foo 12]
(let [bar (+ foo 100)]
[a b c d e f g h foo bar]))))))
The difference is that when you say `(let [a 10])` the variable `a` is a constant now, you can effectively replace all occurrence of it within the scope by `10`, and you can do this at compile time.
That's why people say the symbol `a` is bound to the value 10, and not the variable `a` points to the value 10.
Effectively you cannot change `a` within the scope anymore, all use of `a` in that scope will be equal, and so within that scope you can change their ordering freely.
What I think is confusing you here is that `let` gives you syntax sugar so all the scopes are flattened, but each new binding pair is actually inside a nested scope, and so `a` is still immutable. In this case, it matters almost never, but as I showed, it still can, because in an imperative language you could still try to mutate the variable even in the same expression, and that is impossible to do in Clojure.
Can you point me to something that demonstrates this? I've both decompiled this form and traced its compilation:
(defn foo [a]
(let [b a
b (+ b a)]
b))
(let [a 1
a (+ (inc a) (inc a))
_ (println a)
a (+ a a)]
a)
((fn[a]
((fn[a]
((fn[_]
((fn[a]
a)))
(println a))
(+ a a))
(+ (inc a) (inc a))))
1)
And like I said previously, you can reduce it with variable substitution, which gets rid completely of all the variables, at compile time, and the evaluation will give the same result:
(do
(println (+ (inc 1) (inc 1)))
(+ (+ (inc 1) (inc 1))
(+ (inc 1) (inc 1))))
((fn[_]
((fn[]
(+ (+ (inc 1) (inc 1))
(+ (inc 1) (inc 1))))))
(println (+ (inc 1) (inc 1))))
So here what happens you reduce that function into a do-block (which is Clojure's imperative form):
(do
(println (+ (inc 1) (inc 1)))
((fn[]
(+ (+ (inc 1) (inc 1))
(+ (inc 1) (inc 1))))))
(do
(println (+ (inc 1) (inc 1)))
(+ (+ (inc 1) (inc 1))
(+ (inc 1) (inc 1))))
(do
(println (+ 2 2))
(+ (+ 2 2)
(+ 2 2)))
(do
(println 4)
(+ 4
4))
(do
(println 4)
8)
Ok, and this last bit is very important, this is what people mean when they say that in functional programming the order of execution doesn't matter. The side-effects must still be sequenced in their correct order, but all the computation can happen in arbitrary order, because the computation doesn't rely on a sequence of instructions like it does in the imperative programming paradigm, instead it relies on this "reduction" process I described which as you see you are free to reduce each part in whatever order you want, you'll always end up with the same thing in the end.
(let [a 10
a (+ (let [a 20] a) a)]
a)
Let me try and better explain myself. For me, the qualification here is that the form exhibit semantics that are compatible with functional programming, and can be evaluated using a lambda calculus computational model. Those semantics are in turn incompatible with the imperative ones, since it prevents you from doing some things that imperative semantics would allow, as I demonstrated with my prior example.
The let form does dictate a series of expressions to be executed sequentially from top to bottom, but the binding of their result to a name is done functionally, not imperatively.
This still models a data-flow, and the fact it lets you shadow prior names doesn't change the functional nature of it.
The form simply expresses a composition of functions and how their inputs/outputs connects.
That means it doesn't actually require any separate mutable memory location, even if the Clojure implementation for it might use some.
That's inherently the conceptual model of a functional computation, and it is not that of an imperative one.
(let [a 1
b 2
a (+ a b)]
a)
1 2
\ \
(+, , )
\
3
If you look at the multitree, at each level of the multitree, you are free to evaluate the nodes in any order, but if there is an input/output dependency, then you must guarantee that ordering.
At the end of the day, we could argue forever that we just have different taxonomies. I consider imperative programming the computational model where you give instructions in sequence which dictates mutations on memory locations.
I consider functional programming the computational model where you declare a composition of expressions that can be reduced using variable substitutions.
With this in mind, let qualifies as a functional construct, because it defines such a composition and can be reduced through substitution.
Now in practice, the Clojure let form reduces over this sequentially both left to right on a per-form basis, and top/down between each pair of bindings. And since Clojure allows you to mix imperative anywhere, you can have a println in it and know that it'll run after all that came before, and before all that comes after. But semantically it is still functional. And that's why you can't modify the bindings, because they do not conceptually represent memory locations which you can mutate.
The declarative nature is that you're declaring that you want `a` to mean 10 within some scope. That's why you say "let `a` be 10 in current scope", that's your intention here, for `a` to be 10.
After you've declared that, it holds true no matter what.
Where as in the imperative style you say: put 10 at place `a`. This is variable assignment, there's a place which is refered too as `a` and inside that place you can set values and change them at will.
At any point you can instruct the language to change what value is at place `a`, there are no restrictions to the instructions you can give.
It's a bit of a oversimplification to claim that imperative programming is distinguished from declarative programming by assuming a lack of ordering in the latter.
Functional programming is not prevented from expressing order, rather it is less able to express random accidental order at the operational semantics level.
At the end of the day, it's very much about the computational model, imperative is based on Turing model, and Functional on the lambda calculus. Because the latter doesn't depend on a global mutable running state, it is said to be declarative, in the sense that what you see is what you get, you don't need to keep track of what the memory currently has to proceed to the next step.
That said, you're right that Clojure supports some forms of imperative programming as well, but let isn't one, your parent commenter pointing to Atom was more on point. That's what you'd need to do to get back a more imperative `let`:
(let [a (atom 10)
a (+ (swap! a inc) (swap! a inc))]
a)
The println in the example is imperative, as it has side-effects, but a let block having an ordering of bindings is not inherently imperative. You can replace any let block with a set of nested functions:
(let [foo 12
bar (+ foo 100)]
[foo bar])
((fn [foo]
((fn [bar]
[foo bar])
(+ foo 100)))
12)
Language is hard.
But passing contexts I can see. There is a not uncommon pattern that one can use of keeping a large map with state in it.
However it's completely compatible with pure functional programming.
There's nothing "imperative" (as commonly understood) in 98% of Clojure code out in the wild.
"Contexts" or "context updates" are also very rare, unless required by a non-Clojure JVM or JS library.
Can discuss further if you reference a specific open-source code example with "context" or "imperative style".
But, since we all make opinions from others, let me provide you a balance of opinions by giving you mine.
I'm a senior engineer and I currently use Clojure professionally. I find it to be a lovely, fun and productive language, my favorite one to date actually. I have prior professional experience with C++, C#, ActionScript 3, JavaScript, Scala, Kotlin and Java. And of all of those, Clojure is my favourite to work with.
The "context' pattern you may have heard of, I believe I know what it refers too, and it is not an imperative pattern at all, let me explain.
There's often a case where a piece of functionality will be implemented by multiple functions composed together. For example, an API handling a request will delegate to sub-functions which could in turn call down to more sub-functions.
In that scenario, it can happen that the sub-functions need data about the context of the call to the parent function, or they need data generated by the prior sub-functions that were called. In my example, lets say the request object to the API dictates various options and has the request details, and each options is relevant to different sub-functions, maybe one needs the username, where the other needs the cart-id both of which were passed on the request, but maybe the other function also needs the user-permissions which was obtained from the prior sub-function.
Ok, so say:
someAPI({username: "foo", cart-id: 123}) {
permissions = get-permissions(username);
retrieve-cart-items(username, permissions);Now as you have more and more of these forming a coherent whole, in Clojure there is a pattern where people will say, all this initial data and the data generated by the intermediate steps becomes the "context" data for the operation as a whole.
(defn some-api [context]
(-> get-permissions
retrieve-cart-items
:cart-items))
{:username "foo",
:cart-id 123}
{:username "foo",
:cart-id 123,
:permissions [:can-view-cart]}
{:username "foo",
:cart-id 123,
:permissions [:can-view-cart]
:cart-items [:pen, :paper]}
And generally in Clojure you'd use the destructuring syntax to indicate what in the context map you depend on:
(defn get-permissions
[{:keys [username]:as context}]
...)
But, this is still fully functional, because none of the functions share a mutable reference to a shared context, they take an immutable context as input and return a new immutable context as output which will just happen to also include all the key/values of the context they received.
Sometimes people also pass in dependencies using this context pattern, which is a form of dependency injection through parametrization, but you combine all dependencies into one parameter object.
I guess they could make it work in any language but judging by the description clojure is indeed a great fit, due to the macro capabilities, flexibility and solid runtime via JVM.