Hacker News Reader

Comment by _bxg1 | Hacker News Reader

> Let’s all write parsers

And yet, at least for the Unix tools I've used, nobody did write an elaborate parser. Instead, they all ended up using newlines to represent a sequence. There were never really nested structures at all. That least-common-denominator format they were forced into ended up making input and output really easy to quickly understand.

Maybe the problem with Rest APIs is that JSON does too good of a job at making it easy to represent complex structures? Maybe we'd be better off using CSV as our data format for everything.

View on HN

Agreed. Thinking in arrays is very powerful. Simple.

Say Unix tools returned JSON. What good is that without a schema? Instead of a parser, let's all write schema transforms?

> And yet, at least for the Unix tools I've used, nobody did write an elaborate parser.

sed and awk are the elaborate parsers that are used in complex unix command line scripting.

I think what the OP is getting at is that the people writing the other command line tools didn't have to write that logic (and thankfully we can instead centralize it in a limited set of tools like sed and awk)

I may be mistaken, but I assumed that they meant that no parsing needed to be done between components, and that they just stream together, which is not really the case. You often have to use sed and awk (eleborate parsers) between different components to get the necessary portions of data from one component into the other...they don't just fit together like legos.

Yeah but sed and awk are amazing “sharp tools” for this sort of task: they have a learning curve, but 100 characters of awk can do some amazing stuff.

There's some truth to that, although there's still something to be said for a lack of recursive structure. Regular expressions can only match a flat pattern. Working with a JSON expression, even if you already have a JSON parser on hand, is often going to add more complexity than parsing a flat line of raw text using a regular expression.

What trade-offs make the most sense are highly dependent on the problem being addressed. If there were ever an instance where text being the universal input and output type made sense, it would be in a Unix environment. That being said, what percentage of shell scripts in the wild would you estimate contain at least one use of grep or a regular expression in general?

Also, tools like jq, xsv and xmlstarlet really solve this so-called “problem”: you just need an widely-supported serialization Formats and good tools to focus on the subset of structured data and pull it out into easily-manipulated text.

> Instead, they all ended up using newlines to represent a sequence.

The biggest mistake in the design of Linux is that they allow newlines in filenames. Seriously, what the heck?!

Reply on news.ycombinator.com