> A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you.
Yes, but a large complicated well maintained and widely used library is not necessarily preferable to a small not so complicated library that does exactly what you need and nothing else. And that goes for formats too.
Recently I was involved in a project where order numbers had to be sent from one system to another. Some colleagues insisted that we baked them into a large xml document and then used libraries to both create the documents as well as parse them. In this case the economic thing to do was to write them each separated by EOL. Even the code we would have written ourselves would have been larger if we’d used the XML solution, not to talk about everything needed to include in builds and deploys.
There's an important difference between using something because it's popular, and using something because it's a standard designed for your problem. For something simple like just sending some numbers across the wire XML is massive overkill (as an aside, there's actually very little XML is a good solution to). CSV, TSV, JSON arrays, one of dozens of serialization formats, or even just a simple EOL separated value like you proposed are all both standardized and very simple solutions to the problem. On the other hand, had they proposed inventing some new binary serialization protocol and using that to transmit the numbers, that would be even worse than using XML.
You should always pick the simplest solution to the problem that meets all your requirements, but when considering solutions you should favor standards compliant solutions. A common example is date formats. Lots of places roll their own date format string when sending dates, but using ISO-8601 will save you (and your clients) so many headaches in the long run.
Honestly for your example, not knowing all the details I can't say for sure if a EOL separated value is a good solution, but based on just the description I probably would have gone with a CSV, or possibly a JSON array. I definitely would not have used XML (dear god, why would anyone pick XML in this day and age?), although if they were concerned about needing to add more data down the line I could maybe see an argument for something a bit more involved than a CSV.
Yes, but a large complicated well maintained and widely used library is not necessarily preferable to a small not so complicated library that does exactly what you need and nothing else. And that goes for formats too.
Recently I was involved in a project where order numbers had to be sent from one system to another. Some colleagues insisted that we baked them into a large xml document and then used libraries to both create the documents as well as parse them. In this case the economic thing to do was to write them each separated by EOL. Even the code we would have written ourselves would have been larger if we’d used the XML solution, not to talk about everything needed to include in builds and deploys.