3 ms·

> A function that can error out should not have the same signature as one that will never return an error. Functions that never fail are pretty rare compared t

> A function that can error out should not have the same signature as one that will never return an error. Functions that never fail are pretty rare compared to ones that do. It's easier to just assume that all functions can fail. Mentally it's a much simpler model.

lanstin 5y ago
This post is the saddest thing I have ever read in computing. So much power comes about (on the CPU, in the call stack) by being able to assume that things proceed with mathematical tractable properties, as computable functions, plain old general recursion. Distributed things, sure, you have to have protocols and so one to regain the determinism, and even then perfection is no longer achievable, but within your big FSM of CPU/memory/disk, it's all pre-calculated in some platonic ideal of computable, recursively enumerable Platonic world of simplicity and knowability about which we can reason.
- wvenable 5y ago
  One errant cosmic particle and all determinism goes out the door as well. The story of computing is not one of mathematics, it's of people and it's of change. Software is about codifying decisions and without perfect knowledge of the universe those decisions are always going to be wrong in some way. And that's even without introducing the infallibility of programmers. Errors are simply part of the process.
  - lanstin 5y ago
    ECC and it should be a few cosmic rays :0) but I wouldn't try to write code to work with random bit changes, but implement distributed protocols that can handle a bit of hostility in the data center. Although when the people calling your libraries are bad enough in your call chain, I have found it worth changing the opaque void * from a pointer to a hash value that you look up in an "allocated" structures hash and can return an error rather than dereferencing when they call stuff 5 minutes after calling "de-alloc." (To stop complaints from people calling de-alloc, then calling "do-something" then crashing then blaming my code because I de-ref the opaque pointer.
- gpderetta 5y ago
  Pragmatically, shit happens.

lanstin 5y ago

This post is the saddest thing I have ever read in computing. So much power comes about (on the CPU, in the call stack) by being able to assume that things proceed with mathematical tractable properties, as computable functions, plain old general recursion. Distributed things, sure, you have to have protocols and so one to regain the determinism, and even then perfection is no longer achievable, but within your big FSM of CPU/memory/disk, it's all pre-calculated in some platonic ideal of computable, recursively enumerable Platonic world of simplicity and knowability about which we can reason.

wvenable 5y ago
One errant cosmic particle and all determinism goes out the door as well. The story of computing is not one of mathematics, it's of people and it's of change. Software is about codifying decisions and without perfect knowledge of the universe those decisions are always going to be wrong in some way. And that's even without introducing the infallibility of programmers. Errors are simply part of the process.
- lanstin 5y ago
  ECC and it should be a few cosmic rays :0) but I wouldn't try to write code to work with random bit changes, but implement distributed protocols that can handle a bit of hostility in the data center. Although when the people calling your libraries are bad enough in your call chain, I have found it worth changing the opaque void * from a pointer to a hash value that you look up in an "allocated" structures hash and can return an error rather than dereferencing when they call stuff 5 minutes after calling "de-alloc." (To stop complaints from people calling de-alloc, then calling "do-something" then crashing then blaming my code because I de-ref the opaque pointer.
gpderetta 5y ago
Pragmatically, shit happens.