I use csv because less technically capable people will be able to open it in Excel. Also I can make an CSV very simply without downloading any libraries which is useful on the airgapped systems I work with. Excel actually recognizes a header for CSVs: just start the file with SEP=, (linebreak). This works with Excel, haven't tested anything else. It is useful, because my country uses the comma as a decimal separator and because of this ; is the default separator in Excel. So I just prepend SEP=, to my CSVs and the magically work in Excel without any need to change any settings.
Hi there. It was really awesome, how the original video made suddenly over 200K views and got over 5000 thumbs up with a 85% like rate, and almost 1000 comments. But it got flooded with so many comments like "if Excel doesn't support it, it's no alternative", and CSV-forever comments, it kind of got annoying ;-) It was also hard to filter out the comments of really interested people, and thus giving them proper answers. There was also one person stating, that he got bored with all these "Stop using X" videos on RU-vid and I thought about that, and eventually kind of agreed. So this is why I reuploaded this slightly modified version.
@@stenwayI can see why you did it. But maybe say something in the description about this. There's some bot channels going around stealing and reposting content (though they're usually kinda sneaky). When I had deja vu, my reaction was to check that your channel isn't one of those, I have a feeling someone else would've jumped the gun and reported it.
Thank you. This is very inspiring for me. I was working on microservices and looking for a way to load 'initial data' for ephemeral instances to run tests. CSV was kind of obtuse and failing me. I think something like a TblsDocument is what I was looking for.
Looked at WSL and SML, the python packages hasn't been updated in 3 years and the docs are horrible, hell nah not trusting that to be maintained in my codebase.
Csv is indeed ass. One of my responsabilities is maintaining a library for importing Jobdata into our system. Most of the time, this comes from .csv... because thats what the production system produces, and I can't change that. We have a lot of the issues you describe. You want to use the library in the US or UK? Thats a comma. You want to use it in the EU? Make sure you set the "Semi-colon deliminator feature flag". Make sure the lib can work out what newline char you are using.. because sooner or later, someone will edit the .csv on a Mac and try to load that. I just outright refuse to support most of the stuff you describe. No you can't have the delimiator inside the values. No you can't use quotes. ASCII only. If you want anything else, use Xml or OPC UA
if you're going to use SML, why not just use XML? It already does everything you want and its already been standardized and is in common use. I don't see a reason to reinvent the wheel. Perhaps a video on alternatives that are already like SML, like XML. I'm sure there are other hierarchical data transfer formats. Yes. that is the official name - data-transfer format.
More standards, yay. JSON is fine. Many languages can read JSON without any external dependencies, the support is just very good everywhere, people know it. And the encoding and CRLF issue is non-existent outside of windows, just avoid windows or set everything to UTF-8 with LF linebreaks. That's what Mac, Linux and the whole web (pretty much everybody else) uses. Microsoft will at some point support it, it's starting to get ridiculous anyways. If the file are *only written or read by machines* go with JSON or something more efficient like protobuf. If the file are *sometimes written or read by humans* go with JSON. If the file are *often written or read by humans*, I suggest TOML.
csv is so simple, its easy to inspect and write your own i/o operations given no library support. most the time if I'm using csv its built for use in my own projects so the exact syntax is known up front. outside of that i would probably paste the data into a google sheet share the link with my team so data can be viewed and edited collaboratively. If it was some other form of data being distributed its opened in microsoft excel and saved to a few respective formats. then if its going into a server DB such as SQL then its being read in from CSV and directly into a given DB format which typically are proprietary anyways... I really don't see the problem using CSV, if your aware of the short comings you simply navigate around them. I hear the complaints from office staff having uploading issues from bad CSV files into a server. but its really just their lack of knowledge of the CSV requirement, thats something you attack at a procedure level to better inform your clients and staff to deal with.
If people used fucking commas in a CSV most problems would be solved. I don't want anything but COMMAS in a COMMA separated file for God's sake! This is the stupider specification ever!
yes, CSV format is chaotic, its encoding is not clear and sometimes it allow a literal line break characters in a value, and make a logical line become two lines, make its parser more difficult to write.
every format always will depend on some ruleset and breaking the rules will end in failure, but all the possible changes are simple handled with defining a foo or class that has interchangable values for the different variables. defining another "default" set off rules is just makeing it worse like microsofts iteration on csv´s i personaly find it a easy enough base that can be adapted to individual needs with little effort. If you realy would want an ideal format it would be in some binary form and that would defeat the readability, adding additional char´s btw is bloating the filesize every extra space will still be for padding will still be char while adding non additional information
