11–20 of 68 posts
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
Or on second look the sibling comment is probably right and it’s about immutability maybe.
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
Lenses are an embedded dsl for doing this via syntax that reads similar to to the mutable variant. Additionally it allows to compose many of such transformations.
Was hoping this was data lenses, like cambria from ink&switch https://www.inkandswitch.com/cambria/ Not sure how "A Lens allows to access or replace deeply nested parts of complicated objects." is any different from writing a function to do the same? Julia curious, very little experience
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
This is equivalent to that for people who are irrationally terrified of mutability, and are willing to abandon performance.
Your comment reads like the response of someone who is struggling to understand a concept.
Was hoping this was data lenses, like cambria from ink&switch https://www.inkandswitch.com/cambria/ Not sure how "A Lens allows to access or replace deeply nested parts of complicated objects." is any different from writing a function to do the same? Julia curious, very little experience
For example in Lombok, the @Data annotation will create a getter and a setter for every private member, and @Getter and @Setter will do the individual methods respectively.
Annotating a class will do every private member, or you can annotate a specific member.
A lens is a shortcut to making a getter/setter for something several elements deep, where instead of calling:
`parentObject.getChild().setChildAttribute()` you can call: `parentObject.setChildAttributeViaLens()`
and not need to write multiple functions in both classes, or even use multiple annotations.
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
One way to think of the goal of functional paradigm is to allow extreme modularity (reuse) with minimal boilerplate [1]. The belief is minimal boilerplace + maximum reuse (not in ad-hoc ways, but using the strict structure of higher-order patterns) leads to easily maintainable bug-free code -- especially in rapidly evolving codebases -- for the one-time cost of understanding these higher-order abstractions. This is why people keep harping on pieces that "compose well". The emphasis on immutability is merely a means to achieve that goal, and lenses are part of the solution to allow great ergonomics (composability) along with immutability. For the general idea, look at this illustrative blog post [2] which rewrites the same small code block ten times -- making it more modular and terse each time.
[1] https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...
[2] https://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Wa...
Once the language is expressive enough to compose pieces well and write extremely modular code, the next bit that people get excited about is smart compilers that can: transform this to efficient low-level implementations (eg. by fusing accesses), enforce round-trip consistency between get & set lenses (or complain about flaws), etc.
Earlier quoted context omitted.
This is equivalent to that for people who are irrationally terrified of mutability, and are willing to abandon performance.
It's a similar idea to map() but for more complex objects than arrays. When people use "map" in Javascript (or most any other language that supports it) do they do so because "they are terrified of mutability, and are willing to abandon performance?" Your comment reads like the response of someone who is struggling to understand a concept.
And, if it wasn't obvious, it's only the `set` half where lenses suck for performance.
I have to admit I don’t really understand the point of doing this instead of just obj.a = 2 or whatever.
As a dilettante at programming language design, I have my own toy language. It uses exclusively immutable data structures (C++ "immer"). I present it to the programmer as simple value semantics. `obj.foo[5].bar.a = 2` works and sets `obj` to a new structure where the path through `foo`, `bar`, to `a` has all been rewritten. Since I put it in as a language feature, users don't have to learn about lenses. Why isn't this technique more common in programming language design? Is it so offensive that the syntax `obj.a = 2` ends up rebinding `obj` itself? The rule in my language is that assignment rebinds the leftmost "base" of a chain of `.` field and `[]` array index accesses on the LHS. I'm ignorant of the theory or practical consideration that might lead a competent designer not to implement it this way.