Data Representation in Clojure - Prismatic engineering practices

I’ve just found this gem on Prismatic/plumatic’s github Data Representation in Clojure.

I’m wondering what are your thoughts about the advice presented there and if any of that would be worth updating taking the changes in Clojure in the past few years into account (especially Spec).

Here are some of my favorites (emphasize mine):

  • tuples, which in our experience are rarely the right choice
  • hash-map’s memory usage: up to ~10x contents
  • Regardless, if your data is shared across many namespaces , or serialized and stored or shared across process boundaries , you should probably have a concrete schema to refer back to
  • For operating on your data, plain old functions are the simplest and typically best option.
    • recommended to use safe-get, use docstrings and schemas to document your code, and organize your namespace into clear public and private sections.
  • If you do need polymorphism , however, ordinary functions are usually not a great choice
    • A single instance? check or case on :type isn’t the end of the world, and sometimes is the simplest and cleanest solution – but once these conditionals start appearing in multiple places, there’s a good chance you’re doing it wrong.
  • multimethods - if you need exotic polymorphism (not dispatching on the type of the first argument)
    • In our experience, this is a pretty rare occurrence.
6 Likes

This aligns a lot with what I do, even though I use Spec instead of Schema.

1 Like