The memory safety problem isn't bad coders

Re:The memory safety problem isn't bad coders by metalrain on Tuesday February 12, 2019 @12:49PM (#19145712)

As a python user I understand the need for better invariant checking, but should it be encoded in types, contracts or conventions?

[ Parent | on HN ]

Re:The memory safety problem isn't bad coders by zaphar on Tuesday February 12, 2019 @01:07PM (#19145892)

I vote for all three.

    * Types so I can prevent all the low hanging fruit.
    
    * Contracts so I can encode invariants that the types 
      can't always express.

    * Conventions so that everyone is talking the same 
      language and there is less confusion

[ Parent | on HN ]

Re:The memory safety problem isn't bad coders by rabidferret on Tuesday February 12, 2019 @01:05PM (#19145869)

My goal wasn't so much to promote any specific answer, just to rebute the argument that the solution to memory safety bugs is to have better C programmers

[ Parent | on HN ]

Re:The memory safety problem isn't bad coders by jschwartzi on Tuesday February 12, 2019 @01:41PM (#19146191)

Yes. Often the difference between a mediocre programmer and an excellent programmer is ability to use tooling effectively to understand how their program works and where it fails.

[ Parent | on HN ]

Re:The memory safety problem isn't bad coders by lmm on Tuesday February 12, 2019 @03:10PM (#19147040)

Types because they can be checked mechanically, simply enough that a programmer can understand the checking process and why it fails or succeeds, but are expressive enough (given some relatively cautious/widespread advances - HKT and some level of dependent typing) for every invariant I've ever needed.

[ Parent | on HN ]