ADT through the looking glass – lenses, prisms and other optics in Scala
1–10 of 17 posts
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#2Takes a long time to parse because it the text has a lot of typos.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#3https://arxiv.org/abs/1809.00738 is really nice for general context. Plus can implement some of these generalizations from what is already here.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#4I 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?
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#5I 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)?
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#6I 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.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#7I 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)?
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.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#8I 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?
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.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#9I 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.
Re: ADT through the looking glass – lenses, prisms and other optics in Scala
#10I 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?
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.