Did you propose/implement/release something better than printf?
> I'm time and time again amused how anti intellectual and outright hostile to technological progress the programming profession is. programmers, out of all of them.
Perfect is the enemy of good. Some people talk about getting work done, some people get the actual work done and move on.
This is what the article is about? Things much better that printf are a dime a dozed and available since 20 years.
>Some people talk about getting work done,
Like this article does? While you busy arguing that you could do the same thing, but much worse?
In my experience, people with this motto generally produce code which frustrates the whole team.
Being a perfectionist is toxic in its own way, though.
There needs to be a balance. I think that balance is to think and plan a few steps ahead (not too much, as it's counter productive) before hitting the keyboard. I know this sounds a bit like a "d'oh, of course" but it really—and unfortunately—isn't something that people practice; they just think they do.
How hard was that to implement? Seriously no reason it couldn't have been part of C89. Why wasn't it? Because the compiler writers and the C++ standards committee have no personal use for it. It took 40 years of waiting and five years to get it just barely past the standards committee. If you think no one would strenuously oppose a feature like embed you'd be wrong.
Those guys also have no interest in printf type functions. And improving printf would be a lot more work than implementing #embed.
ld -r -b binary -o foo_txt.o foo.txt
extern const char _binary_foo_txt_start[]; extern const char _binary_foo_txt_end[]; extern const void *_binary_foo_txt_size;
So you need to write your own declarations (it doesn't generate a header file).
_binary_foo_txt_size is weird and has to be used as: (size_t)&_binary_foo_txt_size
Or use (size_t)(_binary_foo_txt_end - _binary_foo_txt_start) instead.
These people's "actual work" often ends up causing endless streams of security vulnerabilities and bugs too.
Most of the same people you are referring to don't seem to believe that security vulnerabilities exist or are important enough to care about for some reason, but in the real world these are very important issues.
On the other hand, we have people that apparently wouldn't make a program if they are not guaranteed (by another human being) that it will be safe.
If those people generating bugs and vulnerabilities would had to sit tight waiting for someone to make a safe language to do anything, today the world would be 40 years or more behind.
(safe languages that, sarcastically, were created using all those unsafe tools and insfrastructure)
Also in this real world a trillion of printf are being output right now, and will be for a long long time. Is the world falling apart?
You can also list all the printf CVEs but... how many println! are being output?
Sure, but we're talking about printf here. printf is manifestly mediocre.
I guess 'perfect is the enemy of mediocre' doesn't have quite the same ring.