[anonymous_sorry]

The complaint is less whether it would work, and more a question of taste. Obviously taste can be a personal thing. My opinions are my own and not those of the BBC, etc.

You have a small C program that processes this data in memory, and dumps it to stdout in tabular text format.

Rather than simplify by stripping out the problematic bit (the text output), you suggest adding a large, cutting-edge, hard to inspect and verify piece of technology that transforms that text through uncountable floating point operations back into differently-formatted UTF8.

It might even work consistently (without you ever having 100% confidence it won't hallucinate at precisely the wrong moment).

You can certainly see it being justified for one-off tasks that aren't worth automating.

But to shove such byzantine inefficiency and complexity into an engineered system (rather than just modify the original program to give the format you want) offends my engineering sensibilities.

Maybe I'm just getting old!

[verdverm]

If you can modify the original program, then that is by far the best way to go. More often than not, you cannot change the program, and in relation to the broader applicability, most unstructured content is not produced by programs.

[Too]

> More often than not, you cannot change the program

I’d challenge that. Try working with your upstream. It’s easier than ever nowadays to submit issues and PRs on GitHub.

Building layers upon layers, just work around minor issues in a tool is not wise.

[verdverm]

Unfortunately, in my experience it is required more often than not. I have two open issues with up streams that I'm trying to not work around. They haven't even replied let alone consider changes or support contributions. These aren't small projects either. You'd be surprised how many solo maintained projects won't even entertain

Anyway, I do try, but in my experience, if it happens, it's not over night and your going to have to maintain a work around for an amount of time

[anonymous_sorry]

Yes, makes sense. Although this was originally a post about output of common command-line tools. Some of these are built on C libraries that you can just use directly. They are usually open source.