CSVs Are Kinda Bad. DSVs Are Kinda Good

Original Article ↗ Hacker News Discussion ↗

CSV’s ubiquity as a plain‑text tabular format is contrasted with its many edge cases, inconsistent “dialects” and Excel-related quirks, prompting some developers to explore alternatives like delimiter-separated values (DSV) using ASCII control characters. Commenters argue that while such schemes can simplify parsing by avoiding quoting rules, they sacrifice human readability and tooling support, so in practice the more effective improvements are enforcing RFC 4180–style CSV, using TSV on the command line, or switching to well-supported structured or binary formats like JSON, NDJSON, Parquet or SQLite when possible.

Role and Limits of CSV

  • Many see CSV as an “ancient, lowest-common-denominator” text format that persists because it’s simple, human-inspectable, and widely supported.
  • Others stress that CSV itself is “kinda great” when used per RFC 4180; the real problem is ad‑hoc dialects and badly tested exporters/importers.
  • Several note that non-technical users equate “CSV” with “whatever Excel does,” which drives inconsistent, often broken files.

DSV / ASCII Control-Character Delimiters

  • The proposed DSV idea (using ASCII control characters like 30/31 as field/record delimiters) avoids quoting and newline edge cases.
  • Supporters like that it’s efficient to parse, solves many CSV escaping issues, and builds on long-existing ASCII concepts.
  • Critics say it sacrifices the main CSV benefit (human readability/editability in generic tools) without offering enough in return.
  • Others note practical issues: these characters do appear in some real-world “CSV” containing binary/non-plain-text data; you still need an escape strategy.

Standards, Dialects, and Pragmatism

  • One camp argues strongly for enforcing RFC 4180 and rejecting broken CSV to reduce chaos and improve interoperability.
  • Another camp counters that “broken” is a sliding scale; power asymmetries mean small suppliers must accept whatever large partners send.
  • RFC 4180 itself advises being liberal in what you accept; there’s debate over whether that helps standardization or entrenches sloppiness.

Alternatives and Tooling

  • For data you control and don’t need to edit by hand, people recommend Parquet, SQLite files, JSON/NDJSON, or other structured/binary formats.
  • TSV is popular for command-line work; seen as simpler and safer than CSV, though still fragile if tabs appear in data.
  • Some suggest augmenting CSV with a standardized metadata header (delimiter, encoding, locale, etc.).
  • Tooling quality matters: libraries like pandas, xsv, zsv, and LibreOffice Calc are praised for handling messy CSV better than Excel or naive parsers.
  • Several conclude that any format needs clear escaping rules and that “just pick another delimiter” does not by itself solve the deeper interchange problems.