Say you want to do obj.child.foo[3].bar += 2 but without mutation, but instead all the data is immutable and you need to do a deep copy along the path.
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.
Yes lenses are pairs of functions that allow bidirectional data transformations. One function acts like a getter and one function acts like a setter. The signatures of the functions are designed to compose nicely.
This allows to compose complex transformations from a few simple building blocks.
In the end it is really just function composition but in a very concise and powerful way.
In your cambria example the lens is defined as yaml. So this yaml needs to be parsed and interpreted and the applied to the target data. The rules that are allowed to be used in the yaml format must be defined somewhere.
With pure functional lenses the same kind of transformation rules can be defined just by function composition of similar elemental rules that are itself only pairs of functions.
> So this yaml needs to be parsed and interpreted and the applied to the target data. The rules that are allowed to be used in the yaml format must be defined somewhere.
I wasn't trying to get into the specific technology. The Julia still needs to be parse, and while Yaml has them separate, CUE does not (which is where I write things like this and have building blocks for lenses [1], in the conceptual sense)
In the conceptual sense, or at least an example of one, lenses are about moving data between versions of a schema. It sounds like what you are describing is capable of this as well? (likely among many other things both are capable of)
Yes functional lenses are very good at transforming between between schematas.
You can think of it as an functional programming based embedded domain specific language for transforming immutable data structures into each other. Sure there are other ways to do it but its like generalized map/filter/reduce class of functions vs doing the same imperatively by hand or in other ways
With lenses its possible to create component interfaces that make local and global state interchangeable. Even for focus, selection, scrollposition components use local state by default but that can replaced by a lense into a global state.
This make stuff like synching two scroll positions or selectiom ranges super easy and allows for consistent manual focus management across components.
But what’s the benefit of this approach? It seems needlessly expensive, both in terms of computational overhead (walking up and down the state tree) and how much more code it requires.
I guess you gain persistence of your entire app’s state (which makes time travel debugging easier) but that’s all I can think of.
In my experience when applying this architecture to react or svelte, the performance is quiet good, often better than classic alternative approaches (redux, many local useState)
But the main benefit is not only the persistence of the app state, but composable globally consistent state.
With most state management solutions at some point you hit a wall where communicating state changes between far away components is really difficult. You need to manually manage eventlistener lifecycles, route events through the application and convert events into state changes and state changes into events, while not causing cycles or unstable feedback loops or race conditions.
With lenses the state tree is composed declaratively and locally. each component does not need to care if the parent state is locally constructed or coming from further away.
/edit:
Actually using this approach you are not forced to have a single global state but instead each component can simply decide to embed its child components state into its own state or not.
If all components decide to embed their children state you get a single global state. But if all components decide to not embed their children state you get only local state with no communication. But the unified Interface gives you the choice.
This is very detailed introduction and documetation of a lense-based architecture in react. [2]
At the first glance it looks kind of overwhelming but it contains lots of examples.
This is a case study of many rather complex components. [3] The codinsteade is rather quick and dirty hacked together and at the first glance not really readable but thats kind of the point: even complex components can simply be composed locally from many small parts of requiring some global controller managing the state and keeping it consistent.
In every language there are sharp edges or dirty corners that are just annoying once you hit them. JavaScript and Php are full of inconsistencies, Ruby and Python are nice and the surface but once you dive into meta programming, OOP and mutability complex code bases are just impossible to trust/reason about their correctness. Rust, C++, C#, F#, Java... I could go on.
In my opinion Elixir just hits the sweet spot of good design. After multiple years using it there comes nothing to my mind that I find ugly or annoying.
Sure there are other languages that are quiet nice on paper but often they lack the ecosystem to let you just build production ready stuff.
The Elixir ecosystem is also not that large, but large enough for quickly building a web app or composing useful automation pipelines.
Are these kind of projects actually build manually inside of minecraft block by block or is there some verilog/vhdl to minecraft-level compiler toolchains used?
It’s been awhile since I’ve played Minecraft, but when I built large redstone projects before, I built out each circuit manually and then used mods to copy/paste it within the game.
Shameless plug: If you are interested in Fourier Transform and signal processing you might enjoy my somewhat artistic 3D visualisation of the fourier transform as well as the fractional fourier transform [1]
(Fractional fourier transform on the top face of the cube)
And for short time fourier transform showing how a filter kernel is shiftes across the signal. [2]
If I might also plug ‘the Atlas of Fourier Transforms’. If your interested in understanding building intuition of symmetry and phase in fourier space, the book illustrates many structures.
How do you compute the fractional FT? My guess is by interpolating the DFT matrix (via matrix logarithm & exponential) -- is that right, or do you use some other method?
Yes the simplest way to think of it is to exponentiate the dft matrix to an exponent between 0 and 1 (1 being the classic dft).
But then the runtime complexity is O(n^2) (vector multiplied with precomputed matrix) or O(n^3) opposed to the O(n log n) of fast fourier transform.
There are tricks to do a fast fractional fourier transform by multiplying and convolving with a chirp signal. My implementation is in rust [1] compiled to web assembly, but it is based on the matlab of [2] who gladly answered all my mails asking many questions despite already being retired.
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.