3 ms·

I like the second snippet (The actual CopyFile function). It's verbose at the right level – from the single glance I know what will happen in all possible execu

by divan 4y ago

I like the second snippet (The actual CopyFile function). It's verbose at the right level – from the single glance I know what will happen in all possible execution paths. No additional cognitive load on figuring out what's going on behind the scenes on errors. Priceless.

akira2501 4y ago
The call to "Guardf" isn't great, and the fact you have to call it at sites that use it regardless if an error was generated or not offers the opportunity for plenty of "behind the scenes" subterfuge. It's all an incredible amount of effort to avoid what boils down to a basic nil pointer check. I agree the blocks are unsightly, but they're as plain and flat as you could possibly hope for. I almost think you'd be better off using syntax highlighting to obscure them if they're that painful to have to look at.
- fibonachos 4y ago
  I have found the code folding in GoLand to make this basically a non issue (for me personally). if err != nil { return nil } becomes if err != nil: err <up arrow>
- divan 4y ago
  Exactly. So much magic and complexity just to perform the nil check behind the scenes. Also it has a bit of educational component. It's like a seatbelt. In some societies people consider seatbealts annoying and irritating thing that restrict their freedom. They use seat belt plugs to get rid of that annoyance. Go just forces you to use it, regardless of your initial predisposition to the seatbelts.
jasonhansel 4y ago
I like that the execution paths are visible. The issue is that the code's actual functionality gets hidden behind all the noise created by error handling.
- divan 4y ago
  That's what I like about this approach in Go - by having no choice you accept that "error path" as "actual functionality". Phrases like "noise created by error handling" start sound like "the incovenience created by seatbelt". It's not noise.
hliyan 4y ago
This is how we used to write C++ twenty years ago. I used to maintain about 100,000 LOC and I never felt this was an additional cognitive load. In fact, it was beneficial to have the sequence of code always mirroring the sequence of execution (loops and conditionals notwithstanding). Syntactic sugar built into the language was never a priority (at least where I worked). Whatever abstractions we needed, we achieved through classes and operator overloading.
- divan 4y ago
  Cognitive load never "feels" like cognitive load. Back then in C++ times, I also felt like 10+ min compilation times were non-issue. Until I experienced subsecond compilation times, of course.

by divan 4y ago

akira2501 4y ago

The call to "Guardf" isn't great, and the fact you have to call it at sites that use it regardless if an error was generated or not offers the opportunity for plenty of "behind the scenes" subterfuge. It's all an incredible amount of effort to avoid what boils down to a basic nil pointer check. I agree the blocks are unsightly, but they're as plain and flat as you could possibly hope for. I almost think you'd be better off using syntax highlighting to obscure them if they're that painful to have to look at.

fibonachos 4y ago
I have found the code folding in GoLand to make this basically a non issue (for me personally). if err != nil { return nil } becomes if err != nil: err <up arrow>
divan 4y ago
Exactly. So much magic and complexity just to perform the nil check behind the scenes. Also it has a bit of educational component. It's like a seatbelt. In some societies people consider seatbealts annoying and irritating thing that restrict their freedom. They use seat belt plugs to get rid of that annoyance. Go just forces you to use it, regardless of your initial predisposition to the seatbelts.

jasonhansel 4y ago

I like that the execution paths are visible. The issue is that the code's actual functionality gets hidden behind all the noise created by error handling.

divan 4y ago
That's what I like about this approach in Go - by having no choice you accept that "error path" as "actual functionality". Phrases like "noise created by error handling" start sound like "the incovenience created by seatbelt". It's not noise.

hliyan 4y ago

This is how we used to write C++ twenty years ago. I used to maintain about 100,000 LOC and I never felt this was an additional cognitive load. In fact, it was beneficial to have the sequence of code always mirroring the sequence of execution (loops and conditionals notwithstanding). Syntactic sugar built into the language was never a priority (at least where I worked). Whatever abstractions we needed, we achieved through classes and operator overloading.

divan 4y ago
Cognitive load never "feels" like cognitive load. Back then in C++ times, I also felt like 10+ min compilation times were non-issue. Until I experienced subsecond compilation times, of course.