5 ms·

I've been waiting for a non-Clojure lisp to make some headway. Immutability is mostly a fad: look at how incredibly complicated Clojure's implementation is. It'

I've been waiting for a non-Clojure lisp to make some headway. Immutability is mostly a fad: look at how incredibly complicated Clojure's implementation is. It's not worth sacrificing elegance just to attract the true believers.

macintux 9y ago
Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it? The Erlang VM has immutability deeply baked in, and it just works(™).
- sillysaurus3 9y ago
  It's hard. http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...
- banachtarski 9y ago
  I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are making in the process.
  - ams6110 9y ago
    It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.
    - im_down_w_otp 9y ago
      Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.
      - ramchip 9y ago
        You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimization-efde8b20cba7 https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...
        im_down_w_otp 9y ago
        Yes, that. Thank you.
    - banachtarski 9y ago
      That's not true in a number of cases, and thankfully what you said isn't right or the BEAM would truly be a disaster.
- nostrademons 9y ago
  Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails. There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.
  - pjmlp 9y ago
    > C++ still rules the roost there, even though many of its practitioners hate its shortcomings. The solution has been to move it down the stack, as visible on all Apple, Google and Microsoft OSes, even on Qt. It is there, making full use of the hardware in all performance critical code, but then the actual GUI code gets written in something else.
s4vi0r 9y ago
Why/how is immutability a fad? Do you just mean in the context of LISPs? What elegance does having immutable by default data structures?
tree_of_item 9y ago
Clojure's implementation did not have to be so complicated, there are simpler implementations of persistent data structures. Immutability is obviously the more elegant option as far as I'm concerned: Hickey's The Value of Values[0] lays out the case quite well. [0]: https://www.youtube.com/watch?v=-6BsiVyC1kM https://www.youtube.com/watch?v=-6BsiVyC1kM
flavio81 9y ago
>I've been waiting for a non-Clojure lisp to make some headway. Immutability Common Lisp welcomes you, as awesome as ever since 1994. >Immutability is mostly a fad Inmutability is good. What i don't like is mandatory inmutability with no easy way to opt out.

macintux 9y ago

Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it? The Erlang VM has immutability deeply baked in, and it just works(™).

sillysaurus3 9y ago
It's hard. http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...
banachtarski 9y ago
I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are making in the process.
- ams6110 9y ago
  It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.
  - im_down_w_otp 9y ago
    Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.
    - ramchip 9y ago
      You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimization-efde8b20cba7 https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...
      - im_down_w_otp 9y ago
        Yes, that. Thank you.
  - banachtarski 9y ago
    That's not true in a number of cases, and thankfully what you said isn't right or the BEAM would truly be a disaster.
nostrademons 9y ago
Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails. There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.
- pjmlp 9y ago
  > C++ still rules the roost there, even though many of its practitioners hate its shortcomings. The solution has been to move it down the stack, as visible on all Apple, Google and Microsoft OSes, even on Qt. It is there, making full use of the hardware in all performance critical code, but then the actual GUI code gets written in something else.

s4vi0r 9y ago

Why/how is immutability a fad? Do you just mean in the context of LISPs? What elegance does having immutable by default data structures?

tree_of_item 9y ago

Clojure's implementation did not have to be so complicated, there are simpler implementations of persistent data structures. Immutability is obviously the more elegant option as far as I'm concerned: Hickey's The Value of Values[0] lays out the case quite well. [0]: https://www.youtube.com/watch?v=-6BsiVyC1kM https://www.youtube.com/watch?v=-6BsiVyC1kM

flavio81 9y ago

>I've been waiting for a non-Clojure lisp to make some headway. Immutability Common Lisp welcomes you, as awesome as ever since 1994. >Immutability is mostly a fad Inmutability is good. What i don't like is mandatory inmutability with no easy way to opt out.