ADT through the looking glass – lenses, prisms and other optics in Scala
kubuszok.comI find the Monocle library does a good job of describing the motivation for type optics: 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-...
I 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)?
Lens 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.
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.
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.
Scala, 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.
Monocle 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)https://arxiv.org/abs/1809.00738 is really nice for general context. Plus can implement some of these generalizations from what is already here.
I 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?
Never 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.
I 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.
The 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.
What 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".
Takes a long time to parse because it the text has a lot of typos.
>> "Takes a long time to parse because it the text has a lot of typos."
Your comment has typos too :-)
Welp, you're right, that was hypocritical of me.
You comment has unbalanced parens! (;