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.
Zig: software should be perfect [video]
21–30 of 141 posts
Re: Zig: software should be perfect [video]
#22Definitely nice to have tools (compiler warnings, static analyzers) that can keep you from hurting yourself. Of course many projects don’t use them, for various reasons. I wonder: is turning on full compiler warnings, then fixing them - is it making my software better, or just satisfying some type of neuroticism?
There are stupid warnings about nothing to fix, at least in gcc. It's not making the software better.
One warning I recently disabled on $workproject is -Wtrigraphs.
Re: Zig: software should be perfect [video]
#23The definition of 'perfect software' used in the talk is 'it gives you the correct output for every input in the input domain'. To that end no funny business like hidden allocations or hidden control flow should happen behind your back, because an out of memory error or some exception your code does not deal with explicitly would not be a correct output according to that definition. Of course you do not need that level of control for most projects.
Re: Zig: software should be perfect [video]
#24There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nesting.
Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs.
Re: Zig: software should be perfect [video]
#25Javascript (programming language) and Browser (runtime environment) is a perfect piece of combination. With JS, you have many choices of implementation. With Browser, runtime error doesn't crash user's device.
Browsers are far from perfect but their sandboxes are getting pretty good. I think you typoed WebAssembly though?
Re: Zig: software should be perfect [video]
#26There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
> Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs.
Out of curiosity, have you compared this to Rust’s backtrace mechanism? I’d be interested in the perf difference, if it’s available.
Re: Zig: software should be perfect [video]
#27There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
Hey. Thanks for making Zig. I’m glad it’s moving forward.
Don’t let all the negative comments get you down. It happens to every language author. (See some of the nasty comments on Elm, Clojure, Go, Jai, etc.) I, for one, am happy that all of these languages exist, even those that don’t scratch my itches.
Re: Zig: software should be perfect [video]
#28[deleted]
Re: Zig: software should be perfect [video]
#29Earlier quoted context omitted.
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
> Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs. Out of curiosity, have you compared this to Rust’s backtrace mechanism? I’d be interested in the perf difference, if it’s available.
Rust's panics and their backtrackes are essentially the same as C++ exceptions.
Re: Zig: software should be perfect [video]
#30There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors.
i.e. checked-exceptions?