2024-11-09 09:16:51 xentrac: Thanks 2024-11-09 09:17:02 Yeah I think Unix is partly to blame for this 2024-11-09 11:55:14 Unix is partly to blame for local file formats being overengineered binary formats with every second field compressed? 2024-11-09 11:55:50 I feel like Unix was kind of the point at which people tried to stop doing that 2024-11-09 12:45:27 No I mean to blame for networking protocols being quite text heavy 2024-11-09 12:46:06 oh, I guess that's possible 2024-11-09 12:46:21 And I blame UNIX for all this text-based file formats everywhere 2024-11-09 12:46:23 but SMTP and FTP predate Unix having support for TCP/IP 2024-11-09 12:46:36 (as does Telnet, but Telnet isn't text-based) 2024-11-09 12:46:49 Yeah lots of text has always been popular in computing, since the early days 2024-11-09 12:47:01 Because we want the computer to talk the same way as us 2024-11-09 12:47:39 Even if I can't pin the blame on UNIX, I think it's part of that movement, and it's something I don't like 2024-11-09 12:48:04 I guess when it comes to programming though I have mixed feelings, I don't have a good alternative, and arguably it makes more sense for human engineered programs 2024-11-09 12:48:14 you prefer the overengineered binary formats with every second field compressed? :) 2024-11-09 12:48:29 Thas right 2024-11-09 12:48:49 I prefer if they're not overengineered 2024-11-09 12:49:24 Too many binary formats have a lot of shit in them that was added to solve some imagined problem and never got used, or only gets used by some weird program nobody's touched since the 90's 2024-11-09 12:49:46 that can happen to non-binary formats too 2024-11-09 12:49:58 Yeah over-engineering can happen anywhere 2024-11-09 12:50:54 generally I prefer to reverse-engineer and debug file formats that are textual, but maybe that's a matter of habit 2024-11-09 12:51:18 it's usually easier to write code to read and write them too 2024-11-09 12:51:20 Every good ELF has a readelf 2024-11-09 12:51:46 You obviously need some way to 'dump' things from binary formats 2024-11-09 12:52:04 and they tend to suffer less from arbitrary limitations on things like integer sizes 2024-11-09 12:53:25 or string lengths 2024-11-09 12:53:30 on the other hand, they often suffer arbitrary limitations on things like allowed characters 2024-11-09 12:54:51 *sometimes* with textual formats you don't need a readelf 2024-11-09 12:56:23 My main point is a binary format is typically smaller than text format, easier to parse, faster to parse 2024-11-09 12:57:01 I would rather provide a text 'equivalent' and have a binary 'master' to work with, even in version control systems 2024-11-09 12:57:30 And the kinds of problems you encounter like limited encodings for integers etc are the same problems I'm used to dealing with in any native language already 2024-11-09 12:58:16 Maybe I'll write an article and put some more substantive writing down on this thought, at some point 2024-11-09 12:58:27 I've got a few ideas in different stages of execution 2024-11-09 12:58:43 my experience is that usually the binary formats are much more difficult to parse, but I'm not sure that's inherent 2024-11-09 12:58:54 Yeah I think it's over-engineering 2024-11-09 12:59:00 I mean, you could use something like Bencode for your binary format 2024-11-09 12:59:04 It's somewhat inherent, but good practice can avoid it 2024-11-09 12:59:15 Whatever problem you're on it's easy to overcomplicate it 2024-11-09 12:59:38 My argument is that choosing a binary format can allow you to do something *easier* than a text format, and it deserves more explanation than I can give right now 2024-11-09 12:59:53 I'm interested to read it 2024-11-09 13:00:18 it's certainly often true that binary formats are faster and smaller 2024-11-09 13:00:55 as you pointed out, though, often people use gzip or something on their text, so the "smaller" advantage goes away 2024-11-09 16:20:18 text formats can be difficult to parse, compare say YAML to MIDI