Zig: software should be perfect [video] • Hacker News Board

Re: Zig: software should be perfect [video]

#131

Post by wvenable » Sun, Nov 11, 2018, 5:52 PM UTC

lazulicurio wrote: post #122

wvenable wrote: post #79

Earlier quoted context omitted.

> It's too easy to call functions without being aware of the set of possible errors. But that's entirely fine! Programmers are far too obsessed with exactly which functions trigger which errors when it absolutely doesn't matter. All you need to know is what errors you can handle and where in the code you can handle them . If there is a network exception and can recover and retry it at the start of the operation, it l…

This [1] article by Raymond Chen is one of my favorite on exceptions. I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I find reasoning about exceptions significantly increases my cognitive load. Error handling is a place where a little more verbosity is okay because it keeps my focus on the local context rather than having to consider the entire call stack. I basically agree wi…

That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors.

The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong.

Re: Zig: software should be perfect [video]

#132

Post by platz » Sun, Nov 11, 2018, 7:21 PM UTC

coldtea wrote: post #118

gameswithgo wrote: post #110

Earlier quoted context omitted.

Yeah there are a lot of interesting things you can do if you design languages around an editor. Like complete, recursive type inference, so you don't have to annotate types on function signatures, but the editor can display them, which is very useful, or showing what exception can be thrown even if the language doesn't make it explicit. This works out great when the editor is available on the platform you need and wo…

That's all very true, and it's sad that we haven't explored this space more. It's a nice in-between something like a Smalltalk image-environment-IDE / Lisp Machine and a dumb IDE/editor that starts from source code and has to parse into AST into its own...

https://twitter.com/TeaDrivenDev/status/1054177017351024641

Re: Zig: software should be perfect [video]

#133

Post by lazulicurio » Sun, Nov 11, 2018, 7:29 PM UTC

wvenable wrote: post #131

lazulicurio wrote: post #122

Earlier quoted context omitted.

This [1] article by Raymond Chen is one of my favorite on exceptions. I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I find reasoning about exceptions significantly increases my cognitive load. Error handling is a place where a little more verbosity is okay because it keeps my focus on the local context rather than having to consider the entire call stack. I basically agree wi…

That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors. The idea that error states are perfectly knowable everywhere in t…

> Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions

This is only true if your application has no state or invariants that could possibly be invalidated in the face of exceptions. For instance, what would be your solution to the 'NotifyIcon' example given in the linked article?

> The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong

This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.

Re: Zig: software should be perfect [video]

#134

Post by gameswithgo » Sun, Nov 11, 2018, 7:55 PM UTC

electrograv wrote: post #121

imtringued wrote: post #119

Earlier quoted context omitted.

Perfect is the enemy of good. By reducing the possibility of null dereference exceptions from 100% to 10% you have reduced the cognitive burden by 90%. Removing the bypass would result in a 100% reduction in cognitive burden, only 10% more than the second best solution. However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those…

> However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those 10% fall under. While I agree there are rare cases where .unwrap() is the right thing to do, I actually disagree here that it’s anywhere close to 10%: If you want to write a function that accepts only non-null values in Rust, you simply write it as such! In fact, this…

Yeah I think unwrap is best used when experimenting/prototyping, but it can be very very useful there. Imagine trying to get started using Vulkan or Opengl without it. Big mess. But in production code you might want to lint it as a strong warning or error.

Re: Zig: software should be perfect [video]

#135

Post by majewsky » Sun, Nov 11, 2018, 8:05 PM UTC

electrograv wrote: post #121

imtringued wrote: post #119

Earlier quoted context omitted.

Perfect is the enemy of good. By reducing the possibility of null dereference exceptions from 100% to 10% you have reduced the cognitive burden by 90%. Removing the bypass would result in a 100% reduction in cognitive burden, only 10% more than the second best solution. However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those…

> However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those 10% fall under. While I agree there are rare cases where .unwrap() is the right thing to do, I actually disagree here that it’s anywhere close to 10%: If you want to write a function that accepts only non-null values in Rust, you simply write it as such! In fact, this…

> but certainly Rust could benefit from some syntax sugar here at least

It's a tough balance. Rust could benefit from more sugaring, but on the other hand, Rust already has quite a lot of syntax at this point.

Re: Zig: software should be perfect [video]

#136

Post by wvenable » Sun, Nov 11, 2018, 9:06 PM UTC

lazulicurio wrote: post #133

wvenable wrote: post #131

Earlier quoted context omitted.

That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors. The idea that error states are perfectly knowable everywhere in t…

> Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions This is only true if your application has no state or invariants that could possibly be invalidated in the face of exceptions. For instance, what would be your solution to the 'NotifyIcon' example given in the linked article? > The idea that error states are perfectly knowable everywhere in the…

> For instance, what would be your solution to the 'NotifyIcon' example given in the linked article?

The notify icon code is poorly structured to begin with. Simply creating a NotifyIcon object adds it to the UI? That's an awful design. If there was an add to UI step then it would be a non-issue; the half-constructed NotifyIcon object would never get added to the UI. This issue is not magically resolved by having to explicitly handle every error; you can make the same mistake with twice as much code.

> This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.

I'm not talking about changing behavior, I'm talking about changing implementation. Behavior is part of the contract. But being able to safely change implementation is the fundamental principle of abstraction and is the basis for polyphorphism. If a method today does a calculation using a database but tomorrow is refactored to use a webservice -- as long as the contract/behavior is unchanged -- then the rest of the code shouldn't have to know about it.

Re: Zig: software should be perfect [video]

#137

Post by IanCal » Mon, Nov 12, 2018, 5:16 PM UTC

wvenable wrote: post #130

IanCal wrote: post #92

Earlier quoted context omitted.

> All you need to know is what errors you can handle and where in the code you can handle them. Surely also what errors can occur. Can the network using library throw disk IO errors? Permissions errors? Maybe it handles all the network errors internally to the library and I don't need to deal with those at all.

How do you handle those other errors though? If there is a disk I/O error, you're basically done. Permission errors, same thing. You report, abort, maybe retry. You don't really need to know in the specific what kinds of errors can occur. If it's possible to recover from an exceptional situation, it's only useful to know if that situation is possible so you can avoid writing code you don't need to. But there wouldn't…

Well it depends on what I'm doing and why the errors might be thrown right? Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? Whether I retry on network errors can depend on what the error is - if the end service is responding saying my call is invalid for certain reasons there can be a good case to just die immediately rather than slowly backing off trying repeatedly in vain.

The flip side of this is I shouldn't need to worry about exceptions that cannot be thrown. When you say all you need to know is what you can handle and where, that list must be a subset of the possible list of things that can be thrown. There's no point worrying about whether I should be retrying something due to network faults if it never uses the network to begin with.

Re: Zig: software should be perfect [video]

#138

Post by dj-wonk » Mon, Nov 12, 2018, 7:12 PM UTC

avip wrote: post #21

It is actually a nice informative video, but the title is as dumb as dumbness itself. Software should not be perfect. It should be useful. In places where perfection increases usefulness (s.a autopilot), go ahead make it perfect. In most cases, striving for "perfection" is a profound misallocation of resources.

I'll put it this way: "perfection" is too overloaded of a word to be particularly useful in this context.

I prefer to say it this way: I want software to adhere to a contract. That implies that we want people that use the software to understand that contract. To be more precise, I'd say that:

(1) a good contract defines the scope of correct behavior.

(2) a contract may (or may not) give some bounds (or constraints) about what happens outside of the scope of correct behavior

Re: Zig: software should be perfect [video]

#139

Post by dj-wonk » Mon, Nov 12, 2018, 7:39 PM UTC

vortico wrote: post #71

avip wrote: post #21

It is actually a nice informative video, but the title is as dumb as dumbness itself. Software should not be perfect. It should be useful. In places where perfection increases usefulness (s.a autopilot), go ahead make it perfect. In most cases, striving for "perfection" is a profound misallocation of resources.

Yes, it gives the impression that the author thinks memory allocation errors are the only type of bug. Obviously there are thousands more, so it's kind of odd.

Well said. There are many kinds of behavior that may be considered "out of specification" or not adhering to a contract. Here are just four:

* https://en.wikipedia.org/wiki/Undefined_behavior

* https://en.wikipedia.org/wiki/Timing_attack

* https://en.wikipedia.org/wiki/Thread_safety

* https://en.wikipedia.org/wiki/Privilege_escalation

Some of these probably don't come to everyone's minds right away. Please share your favorites.

The behavior(s) that a particular language guarantees is a design question. Once those guarantees are specified, we can objectively evaluate a particular language in terms of how well it does according to its own standards.

Re: Zig: software should be perfect [video]

#140

Post by wvenable » Mon, Nov 12, 2018, 9:23 PM UTC

IanCal wrote: post #137

wvenable wrote: post #130

Earlier quoted context omitted.

How do you handle those other errors though? If there is a disk I/O error, you're basically done. Permission errors, same thing. You report, abort, maybe retry. You don't really need to know in the specific what kinds of errors can occur. If it's possible to recover from an exceptional situation, it's only useful to know if that situation is possible so you can avoid writing code you don't need to. But there wouldn't…

Well it depends on what I'm doing and why the errors might be thrown right? Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? Whether I retry on network errors can depend on what the error is - if the end service is responding saying my call is invalid for certain reasons there can be a good case to just die immediately rather than slowly b…

I think of this way; there are broad categories of exceptions that you can handle and specific exceptions. But those exceptions are significantly smaller than the set of all possible exceptions my code (and the framework code) can trigger. I shouldn't have to worry about every possible exception, just ones I can handle. Checked exceptions/errors means you have to deal with the minutiae.

For your example if retrying network, I prefer to simply have a "ShouldRetry" property/interface on the exception itself since the triggering code has the best knowledge of how it should be handled. No need to know every possible network exception and sort them into retry or not retry.

> Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)?

My favorite error handling is when you can just put a single handler at the event-loop of a UI based project. On exception you just show them the message and continue running. The stack unwinding code ensures the application maintains correct state and that the operation is unwound. If the user clicked "save" and a failure occurred they get the message and can retry if they want.