Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like immutability too. It's just sometimes rather inconvenient.

I would agree with you if you could write something like

http://www.lihaoyi.com/roll/

in a pure immutable style and show me how it's better. You will start off with lots of `.copy`s, maybe transition into lenses and other optics, and soon you'll be on the bleeding edge of research and still not have a working game that's maybe high-school difficulty if written in a mutable style

Research is cool and immutability is cool but if I can get what I want only needing some highschool kid instead of a PL-PhD that's cool too



Ah, but that's a different claim. The claim in the article is "You can use mutability to model things that change with time.". Your claim here is "You can use mutability if it makes programming easier.".


How on earth are those things related? Because using mutability to model mutable things makes programming easier, while using mutability to model immutable things makes it harder. It's not rocket science...


My intention is to try to tease out the finer distinction between where immutability should be used and where mutability should be used, because I'm personally very interested in the tradeoffs.

I'm genuinely sorry if my comment touched a raw nerve. As I said, I think it's an excellent article.

One thing I got wrong in my original comment: use mutability where performance means you can't get away without it, but also where code complexity means you can't get away without it. (My personal view is that there are many cases of the former but few of the latter, but that's an argument for another day.)


You didn't touch a nerve, I'm just being snarky because it's the internet and if I don't the internet police will arrest me.

"code complexity means you can't get away with it" seems very common. Five nested `.copy` calls is probably "too much". Lenses, in most of the incantations I've seen so far, are probably "too much". I'd love to see your solution for making

    a.copy(b = a.b.copy(c = a.b.c.copy(d = a.b.c.d.copy(e = 1))))
As easy as

    a.b.c.d.e = 1
Closest I've seen is QuickLens, which is promising. Still pretty new and experimental, but definitely something I could see myself using:

    modify(a)(_.b.c.d.e).setTo(1)
Still slightly clunky, but less clunky than the other implementations I've seen e.g. in Monocle


The apparent impossibility of a simple lens syntax is one place where Scala is letting me down. I hugely appreciate all the work that's going into things like Dotty, but I wish people were equally as enthusiastic about basic language usability improvements.

One of the most important things a language can do, IMO, is make basic operations easily expressible. Lensing is one of those things.


This [1] part of an interview with Rich Hickey is great on this topic.

[1]: https://youtu.be/wASCH_gPnDw?t=37m13s




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: