Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monocle: Optics Library for Scala

optics.dev

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Monocle: Optics Library for Scala

#31

Post by lmm »

usrusr wrote: post #26
dkarl wrote: post #16

Earlier quoted context omitted.

The problem most programmers would be familiar with is making an update inside a deeply nested immutable data structure. For example, suppose you want to update a user's billing address, and you have an immutable data structure that looks like this: user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } } The structure is immutable, so you can't make the update in pla…

Does it offer creating a mutable view on top of the immutable structure that can be used to accumulate a whole set of changes to later be materialized into a copy with the changes? (or to be used directly, at whatever cost would be required) That's something I've been wondering why it's not more of an established thing. It would basically be docker, but for in-memory reference graphs instead of filesystems.

You can compose together a bunch of edit operations (an edit command, if you like) and apply them at once at the end, is that what you mean?

Re: Monocle: Optics Library for Scala

#32

Post by lmm »

henning wrote: post #7

So behind the scenes, every one of those statements will make a whole new user object with a whole new address object so that it remains immutable? And whether that will actually have any real-world performance impact is I guess entirely situational. Still, what happens if you do that with a big object graph? Also, the original strong need for immutable data in the first place is safety under concurrency and parallel…

> So behind the scenes, every one of those statements will make a whole new user object with a whole new address object so that it remains immutable?

Not a "whole new" one since it will use shared references to the parts that didn't change (which is valid since they're immutable). And in principle the VM could even recognise that the new object is replacing the old one so it can be edited in place.

> Still, what happens if you do that with a big object graph?

I've literally never seen it cause a real-world performance problem, even if it theoretically could.

> Also, the original strong need for immutable data in the first place is safety under concurrency and parallelism?

Partly that, but honestly mostly development sanity and maintainability. You can iterate a lot faster on immutable-first codebases, because it takes much less test coverage etc. to have the same level of confidence in your code.

Re: Monocle: Optics Library for Scala

#33

Post by lmm »

mhitza wrote: post #24

Does the LSP provide clear autocomplete on what properties can be accessed on the bound _ ? Asking as someone that doesn't use Scala at all, but has seen the hit-and-miss of some FP language LSPs.

IntelliJ or the older Scala-IDE for Eclipse certainly does, so I'd be very disappointed if the LSP impl (which the Scala maintainers have been pushing as the official IDE replacement these days) didn't.

Re: Monocle: Optics Library for Scala

#34

Post by valenterry »

mhitza wrote: post #24

Does the LSP provide clear autocomplete on what properties can be accessed on the bound _ ? Asking as someone that doesn't use Scala at all, but has seen the hit-and-miss of some FP language LSPs.

Yes it does, otherwise the code would actually not compile.

Re: Monocle: Optics Library for Scala

#35

Post by valenterry »

henning wrote: post #7

So behind the scenes, every one of those statements will make a whole new user object with a whole new address object so that it remains immutable? And whether that will actually have any real-world performance impact is I guess entirely situational. Still, what happens if you do that with a big object graph? Also, the original strong need for immutable data in the first place is safety under concurrency and parallel…

Your question is a bit like someone asking "so what does the garbage collector actually do? Does it X or Y? What impact does it have?"

And the answer is: no need to care about it. Unless you need to really optimize for high performance (not necessary in 99% of the cases, otherwise you'd use a different language from the beginning anyways).

> Also, the original strong need for immutable data in the first place is safety under concurrency and parallelism?

One of the reasons is that you really can just completely stop thinking about it. Just like you can stop thinking of (de)allocations. Except for some edge-cases when performance matters a lot.

Re: Monocle: Optics Library for Scala

#36

Post by dpratt »

itronitron wrote: post #20

This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.

Imagine my disappointment when I spent the time to set up a Cassandra instance and it did not immediately materialize a demigod woman who knew the answers to everything but was cursed to have no one believe her.

Re: Monocle: Optics Library for Scala

#37

Post by dkarl »

itronitron wrote: post #20

This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.

Virtually everything in computer science is a metaphor. A computer was a human being before it was a machine. A block of memory, an array of values, an index into a structure, most of the vocabulary we use every day is built out of metaphors.

Re: Monocle: Optics Library for Scala

#38

Post by kqr »

solid_fuel wrote: post #3

I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?

Aside from making it convenient to build getters and setters for nested data, optics also have conditional accessors and collection accessors as building blocks.

Conditional accessors have since become a popular language feature with e.g. the elvis operator ?. in C#. Optics make it possible to innovate on features like that in library code rather than as language features.

Something I've yet to see made into a language feature that is common in optics libraries are iterating accessors. E.g. to reset all counters we can, with optics, say something like (in Haskell syntax, since that is what I know)

    stats.each.count .= 0
and that sets the count to zero for all objects in the stats array. If not all stats objects have a count (some might be of a gauge type, for example) we can compose in a conditional accessor that resolves the count field only if it is not null:

    stats.each.count._Just .= 0
In the above statement, nothing is language syntax --it's all library functions and operators. But it still combines really well on the page. Once one knows optics, one rarely has to think very hard about how to do any get or update operation, even when the data types become complicated.

Re: Monocle: Optics Library for Scala

#39

Post by wiml »

ldjkfkdsjnv wrote: post #6

Every scala code base I have worked on, that wasnt written by small team of experts, turned into a huge pile of crap. A small squad of people that treat the language like a religion create an impenetrable masterpiece

You're going to have that problem with any codebase written by people who don't particularly know the language. Typescript written by PHP programmers, Python written by Java programmers, you'll quickly get a huge impenetrable pile of crap.

You can optimize your codebase to be modified by an ever rotating group of people who don't fully understand it, or by a smaller group of people who do. Both are legitimate choices in specific contexts. But if you take a codebase written one way and try to maintain it the other way, your productivity will tank.

Re: Monocle: Optics Library for Scala

#40

Post by afandian »

dkarl wrote: post #16
solid_fuel wrote: post #3

I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?

The problem most programmers would be familiar with is making an update inside a deeply nested immutable data structure. For example, suppose you want to update a user's billing address, and you have an immutable data structure that looks like this: user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } } The structure is immutable, so you can't make the update in pla…

Is this much different from Clojure’s `update-in` ? You just express a path as a sequence of keys / indexes, and a function to apply, and let the persistent data structure get updated.

It's very neat. But depends on a type system built for this kind of use.

https://clojuredocs.org/clojure.core/update-in

Post reply on HN