Given that maps are the defacto data structure in Clojure, it's pie in the sky dreaming if you think you can always or readily avoid nesting or transformations.

You said "map" but are talking about "tree". There are other ways maps can compose, e.g. graph, which do not lead to deep nesting and transformations.

> You said "map" but are talking about "tree".

In essence yes, the maps I see being bandied about in clj tend to have tree structures.

Haven't seen much/any use of graphs in clj code. Deep nesting has become almost idiomatic at this point from my POV.

Could you provide example/pointer to clj code using a graph in lieu or in addition to a map?

A tree is a type of graph. Also, if your graph has cycles you could end up with infinite levels of nesting. Trees are simpler by definition.

I think that the distinction that dustingetz was trying to make is related to the fact that trees are graphs. Many applications naively nest data in tree structures with links from nodes to other nodes that are implied by the data. Maps are powerful enough to represent arbitrary graphs, so if you don't take advantage of this you end up with a lot of duplicated data in tree format. Then you need to do a bunch of tree traversals to link the data to itself at query time.

graphs are more general! we could argue which is simpler. Graphs store data in normal form. Trees are denormalized.

How do you avoid having complicated, nested data structures in your software if your business is complicated?

One answer to this is to have your raw "source" data stored as flat as possible (Datascript, RDF, ...). Then you generate nested structures (you could call these "views") as much as you want from this data. That way, you don't have to write to nested data, because that's the pain point imo.

If you control the source, that's fine. I get externally generated documents containing an annoying mishmash of XML representing metadata and XML representing rendering logic. Sometimes the same stuff even represents both of these things.

I take them apart to something flatter as early as possible, but the complexity is nevertheless unavoidable.

(changing the upstream representation would involve changing an entire industry as well as a standard)

By simplifying your business :) although that's not always realistic.