Hacker News Reader

Comment by mbostock | Hacker News Reader

Your suggestion requires a fixed-depth hierarchy (such as three levels in your example), and then it requires a lot of redundancy. Here, I want to eliminate the redundancy not primarily for performance reasons, but to make it easier to edit the data by hand, for example to cut-and-paste some lines to move them around within the tree without having to change the leading values.

To get a sense of what I mean, see this editor which lets you interactively construct a treemap: https://beta.observablehq.com/@mbostock/treemap-o-matic

View on HN

Something that I've used in the past: store the hierarchical data as a breadcrumb-like string in an ordinary column. This means the parsing is just ordinary csv parsing, followed by a relatively trivial extra step to parse the breadcrumb columns. You also retain the ability to describe arbitrary depth hierarchies:

    country,value
    World/Asia/China, 1409517397
    World/Asia/India,  1339180127
    World/Asia/Indonesia, 263991379

An added benefit of this approach is that you can have hierarchies in multiple columns. For example:

    datetime, source_account, destination_account, amount
    2016-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 134.2
    2017-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 72.2
    2016-07-01, Assets/ProjectFunding, Assets/Capital/Other, 5.0
    2016-07-01, Assets/ProjectFunding, Expenses/Development, 4.7
    2017-07-01, Assets/ProjectFunding, Expenses/Development, 1.6
    2017-07-01, Assets/Cash, Expenses/OPEX, 0.96
    2018-07-01, Assets/Cash, Expenses/OPEX, 1.62

That has the meta-problem of only allowing two different levels of hierarchies. For one more, you'd have to introduce a new separator.

I feel like the fixpoint of this function is going back to only one separator, or something, but I am not seeing the reasoning clearly.

I'm not arguing against the CST format, but I don't think redundancy is necessarily bad or hard to work with.

It can be good because each line is now an independent idea and doesn't require the indentation context, the items can be sorted or moved easily.

As for hard to work with... a lot of editors have multi-cursor support these days, which makes editing these things in bulk pretty straight forward for smaller sizes and then there's always sed and awk. ;)

Given all that, CST seems like it might be cool for building some quick trees like the given UIs you present.

I'd probably keep to to rows for longer storage though.

CSV is just a serialisation format like JSON or XML. CST appears to put the emphasis on readability (not a bad thing!).

I've taken to using XSV to pretty-print CSV data in bug reports or feature requests for coworkers who give me CSV or spreadsheets to work with. The data doesn't need to go any further, it's already been processed, it just needs to be clearer to understand than raw CSV/JSON/XML:

https://github.com/BurntSushi/xsv

(link has examples of pretty-printed CSV)

Reply on news.ycombinator.com