Project Cambria: Translate your data with lenses

This is really great stuff, as usual from Ink & Switch.

One initial thought that I'd offer is that in a simple running system, these 'lenses' are arranged into a series[1] that can take a datastructure from an origin 'base' version all the way through to the latest-known representation. This may be more familiar to most developers as an analogy to database migration scripts, as mentioned in the post.

When a new lens is created, the developers may want to distribute it to a subset of users, ensure that it works correctly, and potentially adjust it based on feedback before issuing the final lens to the application's population[2].

If this is the intended release workflow, then the arrangement of lenses becomes a graph or chain rather than a simple series. There may be times where it's necessary to backtrack briefly.

It's possible (although hacky, I will admit) to create an NPM JavaScript module that has another version of itself as a dependency.

I mention that because this provides a way to distribute some code -- a lens, for example -- alongside a dependency graph using an ecosystem that is relatively well-evolved (in terms of release management, client upgrade support, etc) for versioned code distribution.

[1] It's nice the that analogy with light passing through a series of lenses fits

[2] Think of an optician testing your eyesight and asking questions about various sample lenses

For those interested, the code for the library behind the project is available at https://github.com/inkandswitch/cambria

I just have to say, it's my name, it's my name! A cool sciency thing has my name! (I'm not sciency at all. Social worker by training, policy and budget wonk as my one-and-only non-human/non-canine love).

I really want to use lenses. The idea of a definition that allows lossless translation from one data representation to another is so elegant. But I wonder if it's a mathematical ideal that doesn't match up with real world problems? I thought to apply the concept of a lens in my problem domain, converting engineering files to machine readable config files, but the reality is the process is more like combining multiple inputs to form an output, which may not contain all of the input data. So I'm left applying some tricks (including unnecessary data in the output/input) to make the process act like a lens. And it's pretty error prone.

Are there applications for lenses that really allow lossless translation in both directions? Or am I misunderstanding the concept in some fundamental way?

As I was reading, I was reminded of schema-migration definitions which some ORMs/DB tools give you (I currently use Knexjs). There might be a useful intuitive correlation there [edit: I see jka and the post already pointed that out]. Of course in the context that I&S is discussing, the migration is at “runtime” (so to speak) because we’re dealing with systems that can’t do all-at-once migrations. Like intrepidhero commented, I’m curious to know if declarative lenses will be sufficient for the task, but I’m glad that’s what they explored. I’ll be reading this post again more closely in the future.

This is one of the reasons I bought Muse. I watched some videos of them exploring ideas on how to build. The attention to detail is next level.

Their software is insane and I imagine part of this is about taking Muse to the web (at least a viewer).

Stoked!

Haskell taking over the world

Is this XSLT for JSON?

“Database columns would be renamed simultaneously in clients and servers” databases should support aliasing column names.

Using YAML as a data transformation language? What could possibly go wrong?