Skip to content

Comment on Why Do We Keep Building Tightly Coupled Software?parent

Comments

> It's easy to share state. I am not yet sold on the idea that all shared state is evil (since I think there are problems that are easier to deal with when using shared memory)

There absolutely are problems that are easier to deal with using shared memory. Clojure takes a middle ground here, and recognizes that shared state is sometimes necessary, but is often overused, mainly because the language makes it easier to make something mutable than immutable.

Just as you mention about Erlang, "With a process, you have to think about where you draw the 'error boundaries'", in Clojure you can paraphrase that as 'With refs, you have to think about where you use shared state'.

To create a local, immutable variable, you would write

    (let [x 42] ...)
If you wanted to make that mutable, it would be
    (let [x (ref 42)]...)
You have to explicitly say the variable is mutable. This change in defaults alone goes a long way in making Clojure a more correct and loosely coupled language.

Indeed. Shared state is absolutely necessary sometimes, it's just not a good default.

Exactly what you said about Clojure applies to OCaml as well, except the syntax in that case is

   let x = 42 in ...
and
   let x = ref 42 in ...
AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.