[tgv]

It's a fun take, but a hyperbole nonetheless. hello.c is supposed to be run from a terminal and write back to it: there's always space to write. It's not meant to be part of a shell script, so the error status is irrelevant.

It does show that we take such examples a bit too literally: our feeble minds don't consider what's missing, until it's too late. That's a didactic problem. It only matters to certain kinds of software, and when we teach many people to program, most of them won't go beyond a few small programs. But perhaps the "second programming course" should focus a bit less on OOP and introduce error handling.

[hnlmorg]

It depends on whether you want your Hello World programs to reflect an actual program or just be an approximation.

I’d argue there is little benefit in the latter. Particularly these days where the Hello World of most imperative languages look vaguely similar. Maybe back when LISP, FORTRAN and ALGOL were common it was more useful showing a representation of the kind of syntax one should expect. But that isn’t the case any more.

Plus given the risk of bugs becoming production issues or, worse, security vulnerabilities and the ease and prevalence of which developers now copy and paste code, I think there is now a greater responsibility for examples to make fewer assumptions. Even if that example is just Hello World.

[dmurray]

> It depends on whether you want your Hello World programs to reflect an actual program or just be an approximation. I’d argue there is little benefit in the latter.

There's a huge benefit in having a program that verifies you have set up the programming environment successfully and can build and execute your programs. Far more than the didactic benefit of any "Hello World" program.

Handling terminal output is just an extra nice-to-have at that point, and one convenient way to verify your tools are working. Correct error handling is definitely out of scope.

[hnlmorg]

Interesting take but I see two problems with that:

1. if you're testing your development environment then handling errors appropriately is even more important. The last thing you want to find out is that your development environment doesn't work because of some edge case that wasn't tested.

2. if your code is just to test the development environment then ship that test code with the development environment rather than publish it on your home page as a practical example of your languages code.

What you're describing is effectively a behavioral test, not a Hello World example.

[knorker]

> a hyperbole

It's not, though.

This helloworld is not safe to use as part of something bigger. Like:

    echo header > gen.txt && ./helloworld >> gen.txt && ./upload_to_prod gen.txt

That will upload a partial file to prod, if there's any write error.

> It's not meant to be part of a shell script

You don't know that. And brittle pieces like this is absolutely not an uncommon source of bugs.

[tgv]

> You don't know that

The first piece of C code in introduction section was meant as production software? I've checked it: that section mentions typing "a.out" in the the UNIX shell to see what happens.

[knorker]

Sorry, I'm not following. Introduction section of what?

[tgv]

The C programming language by Kernighan and Ritchie, the very source of hello world.

[knorker]

Lots of example code leaves out error handling alltogether. Not sure what your point is.

[moring]

If you don't know how the program is going to be used, how do you know that it is doing the right thing? Is "Hello world" actually the expected output?

Also, what makes the status code handling special compared to, say, - assuming the english language is the preferred language instead of asking the OS for the user's preference - assuming that the output has to be ASCII (or compatible) instead of something like UTF-16

There seems to be a weird obsession with the program's status code over anything else in this whole comment section, and it seems to me that the only reason for that is that back in the stone age of computing, the status code was the only thing that got standardized, while locale and encoding didn't, so properly supporting the latter is hard and therefore assumed to be less important.

[knorker]

> Is "Hello world" actually the expected output?

Isn't that the definition of helloworld?

> Also, what makes the status code handling special compared to, say, - assuming the english language is the preferred language instead of asking the OS for the user's preference - assuming that the output has to be ASCII (or compatible) instead of something like UTF-16

True. But by any definition printing nothing is a failure. If failing to print anything isn't a failure, what is?

> There seems to be a weird obsession with the program's status code over anything else in this whole comment section

It's because it's the only structured way to indicate success. And "not printing" is clearly a failure of "print 'hello world'".

> supporting the latter is hard and therefore assumed to be less important.

No, but printing nothing is clearly a failure. Printing the wrong language is not obviously a failure of helloworld, and absolutely not something helloworld can know on its own.

helloworld can know it failed to print what it intended to print. It cannot confirm that its intentions are correct, even in principle.

It cannot know whether some Lennartware has decided that anything built before yesterday (e.g. LANG envs and friends) can be ignored, and that in Lennart land all programs should write a request for the language to the blockchain, and wait for a reply transaction before printing anything.

Just because you can come up with examples of errors helloworld cannot check, doesn't mean that it should not do error handling for the things that it can.

`tar` cannot check that the user actually intended the particular file format flavor that it implements, but it can know that failing to write it should cause it to report an error.