Hacker News Reader

Comment by userbinator | Hacker News Reader

Personally, I think all the talk of "language safety" is overhyped. Bugs like heartbleed occur because of programmers not reasoning correctly about their code. In particular, is it really that hard to know how large some block of memory is, and not access beyond it? It's such a ridiculously simple concept, but I feel like all the high-level languages with their automatically expanding data structures have only made this problem worse, by trying to hide this behind many layers of complexity (as evidenced by this article.)

In my opinion, if you are writing code that is performing array indexing, and are even the slightest bit uncertain about the size of the array, then you should not keep going, but stop and think a bit more about what it's doing. Language safety is not a replacement for true understanding.

View on HN

> is it really that hard to know how large some block of memory is, and not access beyond it?

For one given block, maybe not. The problem is that in a language like C, the fallible human must get every single one correct, otherwise it's a bug waiting to promote to a security flaw. Not only must you get array indexing right, but also pointer dereferencing right, avoid dangling pointers, be mindful of the interaction of aliasing and mutation, etc. This is a lot for a person to never mess up. This is also the reason why projects like Rust exist: they start with the premise that humans will fail and provide tools that prevent the common mistakes.

> In my opinion, if you are writing code that is performing array indexing, and are even the slightest bit uncertain about the size of the array, then you should not keep going, but stop and think a bit more about what it's doing. Language safety is not a replacement for true understanding.

What if you are very sure that your code is correct, but five months later someone modifies code elsewhere in the program that aliases to this array and reallocs() it?

Not only must you get array indexing right, but also pointer dereferencing right, avoid dangling pointers, be mindful of the interaction of aliasing and mutation, etc.

All those things are just part of the logic of the program, which must be correct in any case. Even in safer languages, you still have to write correct code, and if you believe that humans can't reliably get simple things like array sizes correct, how would they do any better with the more subtle kinds of logic errors?

What if you are very sure that your code is correct, but five months later someone modifies code elsewhere in the program that aliases to this array and reallocs() it?

It depends on the specific case but I would tend to believe that someone is not modifying the code correctly (e.g. failing to update the associated size), because they have not understood it.

The mentality of "bugs are normal, and we should restrict languages as much as possible because people might do the wrong things otherwise" is what irks me the most, because proliferating the assumption that perfect code can never be written leads to a self-fulfilling prophecy.

All those things don't need to be correct in any case. The fact that Heartbleed existed for so long shows that the program worked just fine with the broken code.

Heck, bugs in general are usually code that works in some cases, but not every case. Having a type system to catch all that throws out a ton of classes of bugs.

Humans are humorously bad at reasoning about large software systems written by a large number of people. Even if all the code you personally write is locally safe, it's very very difficult to guarantee that the interaction of it with all other components written by other people is itself safe.

That's why formal methods ( type systems, model checkers, ... ) are extremely important, the only to reason about programs in the large is to prove properties of the system that are machine-checkable and remove the need for manual proofs that admit error.

If people are humorously bad at reasoning about large software systems, why would they be any better at reasoning about large type systems?

Because type systems, at least in the ML tradition, reduce down to systems of logic that we already know how to prove properties about. We can prove progress and preservation of a type system, and we even have systems to mechanically check those proofs.

> is it really that hard to know how large some block of memory is, and not access beyond it

Considering that developers have been making this error pretty much every single day for the past 40 years, I'm gonna go with 'yes'.

Here's how I think of it: there are things humans are better at and things computers are better at, and whenever possible we should let the computers do things they are better at. One thing computers are better at is keeping precise track of a bunch of minutia threaded through a bunch of different contexts. Array indices are precisely that sort of minutia, and we should let compilers (or interpreters) take care of it for us to the extent possible.

The problem is programmers are humans and humans make errors (lot's of them.) Any model that relies on humans being perfect is fundamentally flawed. It's why all software has bugs. And sometimes those bugs endanger the whole internet or crash your car. The higher quality your team is, the higher quality their tools and automated tests the fewer bugs you will have. The more complex your code the harder for humans to understand and the more bugs you will have. It's a tradeoff, and I'm personally not certain on which sidebof the tradeoff this code is. Since most of the nastiness is on the library side, probably it's a good thing.

I don't like this spin on humans as imperfect compared to the perfect computers.

Of course humans will make more mistakes, when the immense complexity of the business logic models they deal with surpasses what even the most advanced computer can process today.

Plus, computers also make mistakes. They fail in arbitrary ways, and may produce an arbitrarily wrong result when you least expect it (say, if they overheat).

Sure there are hardware errors too. But in the context of this discussion getting the compiler to check for bugs at compile time vs having runtime failures leads to less buggy software. The more you can push that burden onto your tools, which are far more perfect than human beings, the better.

I think a distinction between "perfect" and "imperfect" can easily be made, in this case.

Computers are great at executing algorithms, and never learning from their experiences. Humans are great at learning from their experiences, but pretty hit-or-miss when it comes to following algorithms. It is probably exactly that learn-ability that trips us humans up: we can learn new and beneficial things, but the flip side is that we can learn the wrong things. Clearly, we need both of these traits (predictability, learn-ability), and should probably delegate the tasks according to each others strengths.

Of course, there is nothing fundamentally different between computers and humans (modulo some philosophical assumptions); in principle, we could implement very complex artificial neural networks, to the point that computers being deterministic might be as much of a useless distinction as considering sociological phenomena as deterministic - fine in a deterministic universe, but a pretty useless perspective for all practical purposes given the immense set of variables. We then gain learn-ability, or AI, but we also lose predictability. So we would probably still delegate the task of compiling programs to a very deterministic program over an incredibly advanced AI that, while sometimes having some good and creative insights when it comes to generating output code, sometimes also learns the wrong stuff and gives us just flat-out wrong output.

Yeah, Real Programmers don't need safety.

http://en.wikipedia.org/wiki/Real_Programmer

Spare us the hyperbole and the misrepresentation, please.

userbinator makes a very valid and legitimate point: regardless of what safety features a programming language may or may not offer, it's still critical for the programmer to understand exactly what's actually happening.

You can't have true safety through tools alone. Operator knowledge is just as critical as whatever safety features the tool may offer.

Given layers upon layers of abstraction, it's often impractical for the programmer to understand exactly what's actually happening. Indeed, that's the entire premise for the existence of more safe languages, which (hope to) eliminate entire classes of bugs.

"true safety" like "true Scotsman"?

Realistically, you get "better safety". Operator knowledge gets you better safety. Better languages get you better safety. Better libraries get you better safety. Better testing gets you better safety. Often, each of these has diminishing returns, but that just means that the best outcome is one where don't over-focus one at the expense of others.

Reply on news.ycombinator.com