Adapting your example to a component of a real project I'm working on:

    JsonParser<Customer> customerP
      = productP
      . field("customer", productP
        . field("name", stringP),
        . field("address", productP
          . field("street", stringP)
          . field("zipCode", stringP)
          . field("town", stringP)
          . map(uncurry3(street -> zipCode -> town ->
              new Address(street, zipCode, town))))
        . map(uncurry2(name -> address ->
            new Customer(name, address))));

This is a parser, not a serializer, but hopefully it's clear how this approach can be applied in the other direction. (I still have the analogous code on a branch somewhere, but the parsing logic needed a cleanup more, and sooner.)

Some of the uncurried function stuff can be cleaned up with dedicated wrappers for `BiFunction` and whatnot. And of course, the address parser could be extracted out if we want to unit test it separately.

I don't find the code I give above to be any worse than the code you gave (for that matter, I don't have the same "yuck" reaction to the C# example, either). I much prefer not needing extra data types that only serve to configure analogous translation code.

We can keep going back and forth, addressing the concerns we have about each other's approach, but it ultimately comes down to preference.