Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Defer Technical Specification: It Is Time

thephd.dev

Post reply on HN
Print view View original

31–40 of 77 posts

Re: The Defer Technical Specification: It Is Time

#31

Post by fwlr »

The author takes great care to rebut a common theme among objections to the proposal - “this isn’t necessary if you just write code better”. I am reminded of this fantastic essay:

> If we flew planes like we write code, we’d have daily crashes, of course, but beyond that, the response to every plane crash would be: “only a bad pilot blames their plane!”

> This doesn’t happen in aviation, because in aviation we have decided, correctly, that human error is an intrinsic and inseparable part of human activity. And so we have built concentric layers of mechanical checks and balances around pilots, to take on part of the load of flying. Because humans are tired, they are burned out, they have limited focus, limited working memory, they are traumatized by writing executable YAML, etc.

> Mechanical processes are independent of the skill of the programmer. Mechanical processes scale, unlike berating people to simply write fewer bugs.

(https://borretti.me/article/introducing-austral#goals)

Re: The Defer Technical Specification: It Is Time

#32

Post by Etheryte »

hinkley wrote: post #22
topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

I love the Principle of Least Astonishment, but I first encountered it in the Ruby book and I gave up reading it halfway through because I kept thinking, "He and I have very different definitions of astonishing..."

In a way that makes sense though, once you're at a level where you can not only write Ruby, but write books about Ruby, surely very few things would astonish you.

Re: The Defer Technical Specification: It Is Time

#33

Post by topspin »

dgunay wrote: post #21
topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

It's incredibly ugly but you could sort of hack in a smaller-scoped defer using anonymous functions: https://go.dev/play/p/VgnprcObPHz

Yeah, I get it. There's an idiom. Still, that glitch is guaranteed to catch everyone off guard, experienced or otherwise, when taking up golang. As I said, it's an entry on the list, and such a list exists for most (all?) mainstream languages. At least it's minor compared to nil, a flaw somehow promulgated in a brand new language many years after anyone purporting to be a language designer would or should have known to avoid. That's a mystery for the ages right there.

Re: The Defer Technical Specification: It Is Time

#34

Post by ChrisMarshallNY »

Pretty much the only time I use it, is if the act of doing some cleanup might cause a change (like a mutable function in a communication API, or letting go of a reference may interfere with a last operation).

Generally, I find it isn’t necessary. I can usually figure out a way to make it work with standard flow control.

In my case, it’s the Swift language.

Re: The Defer Technical Specification: It Is Time

#36

Post by infogulch »

chrsig wrote: post #29
Jtsummers wrote: post #6

> The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”. What that means is that defer runs unconditionally at the end of the block or the scope it is bound to based on its lexical position in the order of the program. The only reasonable way for defer to behave. Function scoped never made sense to me given the wasted potent…

yeah, I've always just extracted the loop body into a new function as a result

I've created a lambda and called it inline to force lexically scoped defer semantics. Works fine and reads fine imo.

Re: The Defer Technical Specification: It Is Time

#37

Post by infogulch »

lukaslalinsky wrote: post #24

Ever since I started working with Zig, I came to realization that its errdefer is even more useful than defer itself. But you can't implement errdefer in C, since there is no standard/disambiguous way of returning errors.

Can you expand on how errdefer works in zig? I'm not familiar.

Re: The Defer Technical Specification: It Is Time

#38

Post by smadge »

fwlr wrote: post #31

The author takes great care to rebut a common theme among objections to the proposal - “this isn’t necessary if you just write code better”. I am reminded of this fantastic essay: > If we flew planes like we write code, we’d have daily crashes, of course, but beyond that, the response to every plane crash would be: “only a bad pilot blames their plane!” > This doesn’t happen in aviation, because in aviation we have d…

I agree with that, but:

- the language still allows you write the unsafe version even with defer. By your logic fallible humans will continue to write these class of bugs because they can. - adding a whole new flow control construct will introduce a whole new class of bugs. The dog barking example is cool for demonstrating how defer works, but is completely unreadable for what it does, programmers will write code like that because they are allowed to, and unreadable code becomes buggy code. - to make a language safer you should remove the things that make unsafe behavior possible, not add constructs which make safe behavior easier.

Re: The Defer Technical Specification: It Is Time

#39

Post by spacechild1 »

kats wrote: post #25
_kst_ wrote: post #20

Earlier quoted context omitted.

The author is the project editor for the ISO C standard. (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)

Great! I'm a programmer. And I've sure spent too much time on C++isms. > (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.) Nope! Gets right to it. This is really building C++ (but this time how I want). It adds work for every C programmer who has to check off a whole bunch of small tasks to keep a codebase living for many years.

"ThePhD" stands for "The Phantom Derpstorm", though.

Re: The Defer Technical Specification: It Is Time

#40

Post by neilv »

> Here’s a basic example showing off some of its core properties

Why not make the string literals in the code identify their positions in the output, to expose the behavior, rather than obfuscate it?

Then the reader only has to work through the code, to see why it would have that order.

It currently looks like a puzzle intended to be harder for the reader to understand than it needs to be.

Post reply on HN