7 ms·
ADT through the looking glass – lenses, prisms and other optics in Scala
- redfast00 8y agoTakes a long time to parse because it the text has a lot of typos.
- bad_user 8y ago>> "Takes a long time to parse because it the text has a lot of typos." Your comment has typos too :-)
- DonHopkins 8y agoYou comment has unbalanced parens! (;
- redfast00 8y agoWelp, you're right, that was hypocritical of me.
- Cobord 8y agohttps://arxiv.org/abs/1809.00738 https://arxiv.org/abs/1809.00738 is really nice for general context. Plus can implement some of these generalizations from what is already here.
- sk5t 8y agoI like working in Scala quite a bit, but always wince at the "instead of using threading primitives consider this 10x more exotic immutable approach" lead-in. Does anyone here really work that way?
- kodablah 8y agoI do, and immutability of a data type has more benefits than just concurrency. Copy-on-write immutable data structures gives the developer confidence when they pass it around. However, I sometimes still leverage mutable structures in self-contained internal situations due to performance and ergonomics.
- threeseed 8y agoNever sure why people talk about concurrency as the number one reason to use immutable structures. The main reason is that your code is less buggy and easier to read and understand as your code base gets larger. You never have to worry if that variable is being modified somewhere else in your codebase because it simply isn’t.
- bad_user 8y agoThe dangers of mutability in the context of concurrency are well known and people would do well to read "Java Concurrency in Practice", a book that recommends for all classes to be defined as immutable (with final fields to get the JMM benefits), unless you have really good reasons for not doing it. Not sure what threading primitives you're talking of, but it depends. In general Scala has very sane abstractions for dealing with concurrency.
- cheriot 8y agoWhat matters is the complexity of the systems built out of these things. Threading primitives are simpler to understand in isolation, but lead to non-deterministic behavior. I've only used optics in a couple small situations, but even if I find some big downside, I'll still be open to "exotic immutable approaches".
- lasagnaphil 8y agoI mainly program in low-level imperative languages (mostly C/C++), and occasionally dabbled in some functional languages (like Ocaml and Elm). But I don’t really understand why you would need such a convoluted system to get/mutate some values in a data structure in Scala. Doesn’t Scala allow mutability throughout its language already (unlike Haskell)?
- whateveracct 8y agoLens doesn't give you mutability. It gives you operations that look like mutations but are still operations on immutable data structures. And that is where the value lies.
- sk5t 8y agoScala, like, enables and encourages immutability, while making regular Java stuff and practices also entirely available (excepting a few Java varargs situations that perplex Scala's notion of arity). This article is, sort of, related to ideas on avoiding mutability anyway.
- papaf 8y agoBut I don’t really understand why you would need such a convoluted system to get/mutate some values in a data structure in Scala. It allows you to work with deep data structures in a safe immutable way. Scala is a nice language for working with data, the standard library, techniques such as lenses and ecosystems such as Spark all contribute to this.
- cheriot 8y agoI find the Monocle library does a good job of describing the motivation for type optics: http://julien-truffaut.github.io/Monocle/ http://julien-truffaut.github.io/Monocle/ Where I've used this in real code is via circe-optics (json parsing). An example: https://stackoverflow.com/questions/36724068/how-to-parse-a-json-scala-without-case-classes https://stackoverflow.com/questions/36724068/how-to-parse-a-...
- emarx 8y agoMonocle also ships with the macro annotation monocle.macros.Lenses that cuts out even more of the boilerplate and works with intellij's autocomplete import monocle.macros.Lenses @Lenses case class Foo(bar: Int) val x = Foo(1) assert(Foo.bar.get(x) == 1)