Looks pretty neat! Though I do wonder whether creating two new entirely separate libraries ptr-poker and jsonifier is really necessary. There already is the store-core package which seems to do about the same as ptr-poker, and it might be possible to optimize aeson using jsonifier’s approach.
I don’t see anything bad in having more packages. It lets the authors of different solutions continue research in different directions. It drives competition raising the overall quality of the ecosystem. It provides separation of concerns, better focus on the problem and provides more space for the author to experiment without having to approve any decision. It makes the author responsible for maintenance of his code, instead of maintainers of the package which he would have PR’ed to. Finally it lets the author collect the reputational benefits in the community for his work.
Concerning “store-core”, as you may notice in the type definitions, the abstractions are not the same and they don’t exactly fit the requirements of the presented approach.
Concerning “aeson”. It can be updated to utilise the benefits of “jsonifier” by depending on it and replacing its Encoding abstraction with it. No need to bundle “jsonifier” as part of “aeson” for that. Also not everyone agrees with the design of “aeson” with its typeclass centrism, myself including. I believe that “aeson” lacks in flexibility and its typeclass layer introduces a redundant complication to the otherwise straightforward problem of composing with functions. E.g., here’s a take on that problem from the author of the Elm language. So “jsonifier” approaches that problem as well, serving the needs of people sharing that vision. In fact, the design of “jsonifier” is quite similar to that of Elm’s JSON encoding lib.
Looks pretty neat! Though I do wonder whether creating two new entirely separate libraries ptr-poker and jsonifier is really necessary. There already is the store-core package which seems to do about the same as ptr-poker, and it might be possible to optimize aeson using jsonifier’s approach.
I don’t see anything bad in having more packages. It lets the authors of different solutions continue research in different directions. It drives competition raising the overall quality of the ecosystem. It provides separation of concerns, better focus on the problem and provides more space for the author to experiment without having to approve any decision. It makes the author responsible for maintenance of his code, instead of maintainers of the package which he would have PR’ed to. Finally it lets the author collect the reputational benefits in the community for his work.
Concerning “store-core”, as you may notice in the type definitions, the abstractions are not the same and they don’t exactly fit the requirements of the presented approach.
Concerning “aeson”. It can be updated to utilise the benefits of “jsonifier” by depending on it and replacing its
Encodingabstraction with it. No need to bundle “jsonifier” as part of “aeson” for that. Also not everyone agrees with the design of “aeson” with its typeclass centrism, myself including. I believe that “aeson” lacks in flexibility and its typeclass layer introduces a redundant complication to the otherwise straightforward problem of composing with functions. E.g., here’s a take on that problem from the author of the Elm language. So “jsonifier” approaches that problem as well, serving the needs of people sharing that vision. In fact, the design of “jsonifier” is quite similar to that of Elm’s JSON encoding lib.There’s also https://github.com/andyfriesen/buffer-builder-aeson – how do they compare?
I’ve updated the benchmarks to include “buffer-builder”. It’s not very different from “aeson”.