Hacker News Reader

Comment by labrador | Hacker News Reader

Anders Hejlsberg explains in the link below that for decades much of computer science was concerned with strict typing as a tool to ensure program correctness. As the consequences of incorrect code have declined - you're unlikely to crash the browser much less the machine with bad JavaScript - the opportunities to explore flexible and more expressive typing have increased. I know younger programmers who don't even bother to check for errors. This is shocking to me as an older programmer. I wonder if this is a factor for the decline in software quality Jonathan Blow talks about in his video. If so, we need to find a way to encourage programmers not to be lazy about errors. The Blue Screen of Death used to be all the encouragement I needed.

Typescript - Type System explained from Anders Hejlsberg - creator of Typescript

https://www.youtube.com/watch?v=AvV3GIDeLfo

View on HN

> I know younger programmers who don't even bother to check for errors

The older programmers of today were once young, and many of them didn't bother to check for errors back then.

They did if they were C/C++ programmers because everyone would know if they didn't when the screen went sad. Maybe Java programmers. I don't know, I never touched the stuff.

No, they didn't, they just ignored the errors and most of the time they got away with it.

That's what the Hello, World! error illustrates. The canonical "Hello, World!" in these languages actually ignores errors, and nobody cares. But it speaks to the general mindset behind C and C++ programmers.

"Eh, it's fine". Until it isn't.

You're joking right? There's zero, zilch, nada need to check the error return from a Hello, World program. Hello World is a standard way to show you can compile and run a program. If you can't do Hello World, you can't do anything else. It's a good joke though. I'll probably steal it.

When was the last time you've seen someone check the return value of printf?

And what is your program supposed to do when printf fails? Print an error?

Perhaps "return 1", at least. If writing to the console fails for some reason, when the entire purpose of the program is to write something to the console, the program shouldn't exit with a status of zero. Arguably a "correct" hello world in C is:

    #include <stdio.h>
    #include <string.h>

    #define HI "Hello, world\n"

    int main() {
        if (printf(HI) != strlen(HI)) {
            return 1;
        }
        return 0;
    }

(And I'm sure astute readers could even find fault with this implementation.)

Obviously this is tongue-in-cheek; I would never write code that checks the output of printf(), even if perhaps, in some abstract way, I "should". If we were to believe that the purpose of a "hello world" program was to teach about error handling, then maybe we should write "hello world" this way. But I'm also not sure that's its purpose.

Where is the Rust Hello World example on the manual teaching new generations to check for print errors?

I don't really understand this question. We're talking here about the canonical "Hello, World!" program in each language.

In C that program is written in K&R. In Rust (like several modern languages) that program is provided automatically as a placeholder when you start a new project.

The C program, as I explained, just presses on anyway if there's an error. For example if the standard output on your Unix terminal leads to the full device, that's ignored and the program exits with a success indication.

The Rust program, of course, will panic, and the program exits with a failure indication (if your standard error leads to somewhere the panic report will be sent there unless you've asked for panic to abort)

It's a difference of convention. The convention in Rust is that we should care whether things fail, and if we don't know what to do about them failing we should panic.

> I wonder if this is a factor for the decline in software quality Jonathan Blow talks about in his video.

Wouldn't hold my breath; I recall a tangent on programmers being "afraid of pointers". Depending on your favourite not-C-pointer way of managing memory, that's saying that use-after-free bugs are a sign of bad programmers, or shunning substructural/region/etc types for verifying that explicit memory management is correct.

> I recall a tangent on programmers being "afraid of pointers"

I've seen that too... It's pretty funny because in so many modern languages every reference is just a pointer we can't do arithmetic with.

I think when people say they are "afraid of pointers", they really mean they're afraid of manipulating pointers... that is, as you say, doing pointer math.

No one has stopped studying strict types, they are alive and well

No one said that. Obviously software that can bring down the entire machine is still being written, but by highly skilled specialists. Meanwhile we've grown an army of coding bootcamp programmers churning out all the software that is eating the world (™ Marc Andreessen)

That's because the value of them churning out that software, however bad, so far has been greater than the alternative (none of it existing). I'd imagine this will hit a breaking point however (maybe it already is) due to hardware not advancing as rapidly. But who knows, maybe we are on the verge of another breakthrough and don't even know it.

But once we hit the wall, things will shift.

Reply on news.ycombinator.com