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

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.




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

Search: