Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.
CSV is a very bad example. Yes, it is easy to throw together a simple regex to parse simple RFC4180 CSV strings, but Excel is its own black box with a huge number of hacks.
For example, en-US excel will automagically parse TRUE and "TRUE" to be the logical value TRUE. The way to get Excel to see a literal string TRUE is to make a formula ="TRUE". Many CSV writers implement this hack specifically assuming files will be read back in Excel. So now your parser, if you're trying to process data like Excel, has to do the same.
So then you discover that this is actually localized! If you set your UI language to French (France), Excel will treat VRAI and FAUX as booleans while TRUE and FALSE are treated as literal strings.
What you thought was a simple CSV parser now has to handle localization as well. So that CSV parser library can roll its own dodgy localization support, use a tried and true solution, or just choose not to support the feature. Each choice has its own drawbacks
> Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve
CSV, which isn't even a standard and the closest thing to a standard is a description of the breadth of different behaviors seen under the name at a particular point in time with some notes about their relative frequencies and respective practical issues, does, in fact, evolve.
Alright, fair, but then again what if you're building something more complex, where CSV-parsing is just 1% of what it does? Do you implement every single non-standard library functionality you need?
