Hacker News Reader

Comment by demondemidi | Hacker News Reader

There's a simpler answer: if you need something more sophisticated than CSV, then don't use CSV.

This attitude in young programmers kills me. It's the old "let's make one tool that does everything, and i (re)invented it!" attitude they get after a few years on the job.

View on HN

I am old too, but if anything I think that young programmers nowadays are not nearly as iconoclasts and rebels as they used to be. And I do miss that.

that's because of the cambrian explosion of what being a "programmer" means today. there's no time to learn all the history anymore. at the start of the PC era it was possible to understand every microprocessor architecture on the market and how to program them and programming languages for PC applications were sparse (assembly was pretty much the only viable choice although some profitable applications were written in Pascal). i may be off base here but i think 40 years ago the majority of programmers knew 80-90% of the history and you just can't do that today unless your career is "historian".

These days it’s massive challenge to stay on top of JavaScript and its frameworks. Never-mind anything else.

Isn't it the opposite?

Instead of make something completely new that does everything expand the well known old by some useful features?

My 0.02$: For something as deeply embedded and controversial as CSV this won’t work. I say this because I’ve been watching the battle since the 1990s. CSV has a lot of problems, but it is only an issue if you try to make it do too much. For a current example look at JSON. The original BNR grammar fit on the back of a business card. It has major issues too. Yet it hasn’t successfully been replaced or augmented without creating even worse problems, like compatibility. Putting lipstick on a pig, like this suggestion for CSV, just creates incompatibility and even more headaches.

No programmer I know _wants_ to use CSV. It’s often a requirement foisted on them by another team or entity that they just have to work around.

Right. And that other team should not use CSV. Adding multiple column headers isn't any more of a solution because it also requires that other team to fix their shit.

In other words it's a classic multi-agent coordination problem (aka network effects), and saying "why doesn't one side unilaterally start acting differently" is a well answered question by game theory.

I am commenting on the reasons why most programmers I've met get stuck with CSVs as a data format.

I am not commenting on some ill-fated attempt to add types to CSV columns.

Edit: removed a "not" in the wrong place.

I strongly disagree based on decades of experience scripting in linux and needing to manipulate tabular data. Maybe you just don't know a lot of programmers. CSV is _extremely_ useful, if you know when and how to apply it and don't push it out of it's wheelhouse.

> Maybe you just don't know a lot of programmers.

What a completely odd thing to say on a site like this, but alrighty.

Anyway, I'll be clear: I run a business that deals with CSVs and their oddities. I am acutely aware of how well they can work. This has nothing to do with the fact that most programmers I've met, given the choice, would prefer literally any other data format.

You've just met at least 2 programmers who have no problem with csv.

Small specs that don't define very much have a value. Least common denominators have a value.

It's a problem to use the basic solution in an enterprise problem, but it's also a problem to use the enterprise solution to trivial problems.

You're noting "2" when I just said "most". Doesn't need to be a measuring contest here.

I'm suggesting maybe you make an assumption about what most programmers you know think about a topic you probably never specifically polled every one of them on, and that whatever numbers went into "most" there are at least 2 to add in the other column.

You are expressing your view, I am expressing mine, that is all.

Reply on news.ycombinator.com