5 ms·

Funnily, you're complaining about csv formatting, guess you never worked with ACH formatting. It's cobol fixed length files. I implemented parsing/creation for

Funnily, you're complaining about csv formatting, guess you never worked with ACH formatting. It's cobol fixed length files. I implemented parsing/creation for this file format at two different companies. Hired on at one company, first day, my manager said, "hey, you have experience with ACH right? we have this project...". That's when you learn to start leaving stuff off your resume.

nvahalik 9y ago
NACHA cha cha cha!!
- labster 9y ago
  You can't spell Atlach-Nacha without ACH.
bct 9y ago
You can do a lot worse than ACH. It's hard to read, but it's simple and pretty well-defined. What _really_ sucks is one-off fixed-width formats that aren't well defined, or that change suddenly (oh, you thought that field would always be populated? lol no.)
- HillRat 9y ago
  Yeah, ACH is surprisingly not-unpleasant, at least relative to nightmares like X12 EDI with its implicit looping constructs and billions of companion guides that supercede random parts of the base spec.
  - sixdimensional 9y ago
    X12 EDI, been there earned the badge, both on the generating and receiving sides. 837, 834, 835 and others in health care - fun! Positional format, with situational meaning... really it is a fascinating format.
    - pg_is_a_butt 9y ago
      i wrote the X12 EDI stuff for a major clearwater distributor... also wrote the ACH stuff that dumped someone a file and their job was to upload it via SFTP to the bank. so many badges.
    - 20after4 9y ago
      Don't you mean nightmare format?
      - eric_h 9y ago
        Nightmares can be fascinating
- tonyedgecombe 9y ago
  Years ago I worked with a product that parsed line printer data, it was a nightmare trying to get every piece of optional data into the reports.
- oddsignals 9y ago
  What _really really_ sucks is well-defined, reasonable, meticulously documented formats where all in-the-wild implementations stray from the spec in different ways :-/
  - deleted 9y ago
    [deleted]
paulie_a 9y ago
Previously I had no experience with ACH but my current project is essentially reverse engineering a very proprietary version of NACHA and another file that is 400 fields long. Honestly the current parser does work but I can only assume due to some black magic or other voodoo.
dmlittle 9y ago
Every time someone complains about file formats I bring up a similar story. It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor...
- DaiPlusPlus 9y ago
  > It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor... Depending on the business-application, fixed-width formats are fantastic because they allow for genuine O(1) random-access to records without needing to precompute an index first. Writing parsers for fixed-width formats is also much simpler, for example, because it eliminates ambiguity around null-terminators vs length-prefix in text/string/array data - for resource-constrained environments it's great because you can guarantee you won't need to dynamically-allocate buffers. I feel the only real arguments against fixed-width records are concerned with wasted space - which are mitigated if your system lets you compress them somehow - because they'll typically compress very, very well.
  - krylon 9y ago
    > I feel the only real arguments against fixed-width records are concerned with wasted space Sometimes, fields can turn out to be too short. I have received a few letters from business with my last name truncated, because somebody way back when decided eight or nine characters are definitely enough for a surname.
- marktangotango 9y ago
  Ha! I wrote an editor for fixed length files, it lets you map to a cobol copybook, or create the layout manually. I never released it. Anyone interested?
  - wolfgang42 9y ago

nvahalik 9y ago

NACHA cha cha cha!!

labster 9y ago
You can't spell Atlach-Nacha without ACH.

bct 9y ago

You can do a lot worse than ACH. It's hard to read, but it's simple and pretty well-defined. What _really_ sucks is one-off fixed-width formats that aren't well defined, or that change suddenly (oh, you thought that field would always be populated? lol no.)

HillRat 9y ago
Yeah, ACH is surprisingly not-unpleasant, at least relative to nightmares like X12 EDI with its implicit looping constructs and billions of companion guides that supercede random parts of the base spec.
- sixdimensional 9y ago
  X12 EDI, been there earned the badge, both on the generating and receiving sides. 837, 834, 835 and others in health care - fun! Positional format, with situational meaning... really it is a fascinating format.
  - pg_is_a_butt 9y ago
    i wrote the X12 EDI stuff for a major clearwater distributor... also wrote the ACH stuff that dumped someone a file and their job was to upload it via SFTP to the bank. so many badges.
  - 20after4 9y ago
    Don't you mean nightmare format?
    - eric_h 9y ago
      Nightmares can be fascinating
tonyedgecombe 9y ago
Years ago I worked with a product that parsed line printer data, it was a nightmare trying to get every piece of optional data into the reports.
oddsignals 9y ago
What _really really_ sucks is well-defined, reasonable, meticulously documented formats where all in-the-wild implementations stray from the spec in different ways :-/
- deleted 9y ago
  [deleted]

paulie_a 9y ago

Previously I had no experience with ACH but my current project is essentially reverse engineering a very proprietary version of NACHA and another file that is 400 fields long. Honestly the current parser does work but I can only assume due to some black magic or other voodoo.

dmlittle 9y ago

Every time someone complains about file formats I bring up a similar story. It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor...

DaiPlusPlus 9y ago
> It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor... Depending on the business-application, fixed-width formats are fantastic because they allow for genuine O(1) random-access to records without needing to precompute an index first. Writing parsers for fixed-width formats is also much simpler, for example, because it eliminates ambiguity around null-terminators vs length-prefix in text/string/array data - for resource-constrained environments it's great because you can guarantee you won't need to dynamically-allocate buffers. I feel the only real arguments against fixed-width records are concerned with wasted space - which are mitigated if your system lets you compress them somehow - because they'll typically compress very, very well.
- krylon 9y ago
  > I feel the only real arguments against fixed-width records are concerned with wasted space Sometimes, fields can turn out to be too short. I have received a few letters from business with my last name truncated, because somebody way back when decided eight or nine characters are definitely enough for a surname.
marktangotango 9y ago
Ha! I wrote an editor for fixed length files, it lets you map to a cobol copybook, or create the layout manually. I never released it. Anyone interested?
- wolfgang42 9y ago