11–20 of 70 posts
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
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…
The only thing that really matters here is how deep the graph is. Any unchanged object can just be reused as-is.
I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?
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…
What you get out if it is (a) safety, (b) understandability, which are wonderful properties to have as long as the end result is performing adequately. Implementing concurrent tree or graph traversals under conventional mutation is painful; the Java collection libraries simply throw a ConcurrentModificationException. The equivalent code for readonly traversals of immutable data structures is simplicity itself. You also get versioning and undo's for free.
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
Every code base I have worked on, that wasnt written by small team of experts, turned into a huge pile of crap…
I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?
user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } }
You can think of this as the equivalent of a setter for immutable data structures.
This is an artificial example, because the cost of making a deep copy of this user structure is probably not that bad, and the boilerplate to make an efficient update is not all that bad, either. You would use an optics library when 1) you need efficient updates and 2) it's worth investing a little effort to hide the boilerplate.
Optics also let you concisely express access into a deeply nested structure, the getter paired with the setter. In my experience, updates are the motivation for setting up optics, and concise access is a nice thing you get as a bonus.
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
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
And with the arrival of virtual threads in the JVM there are new concurrency libraries e.g. Ox [1] and Gears [2] which remove the need to use FP concepts like monads. Which have been the major source of much of the complexity.
For all its problems it is a seriously under-rated platform especially Scala.js which IMHO is far better and simpler than Typescript.
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…
There are many techniques like this within Scala that would never be feasible if it wasn't for the fact that the JVM is ridiculously fast. You could write the worst code imaginable and in many cases would still have better performance than Python, Javascript etc.