It's not a coincidence that Fuzzing is added to Go

Posted Sep 6, 2020 4:03 UTC (Sun) by HelloWorld (guest, #56129)
In reply to: It's not a coincidence that Fuzzing is added to Go by Cyberax
Parent article: Fuzzing in Go

> OK, please now please rewrite this function without gotos or early returns

I would, but it's just too hard to read…

Anyway, I'll point out that
1. the paper you've presented is meaningless. It deals with the question how deep a single level of indentation should be (2 to 6 spaces). That says nothing about the benefits (or lack thereof) of structured programming
2. you haven't addressed my point that with structured programming it's easier to understand which conditions must apply for a certain piece of code to execute, because every condition corresponds to one level of indentation
3. you haven't addressed my point that it's easier to get resource cleanup right with structured programming (no need for any "goto fail" nonsense)
4. you keep harping on this structured vs. non-structured programming thing instead of addressing the much more important point that in order to avoid bugs we need to employ formal methods (which is another thing that Dijkstra was right about)

Frankly these discussions with you are just tiresome, because when it comes to programming, you're completely stuck in a 1980s-style imperative mindset. There's nothing interesting to learn from that.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 6, 2020 4:15 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

The paper looked purely at graphical indentation level, and it holds true for nesting as well.

Again, you seem to not understand that the theory says that every loop can be rewritten as a loop with invariant in its condition.

In practice a lot of invariants are too unwieldy to write in one condition and benefit from being split into multiple statements (with break/continue to help). Often because you need to introduce additional variables. All "structured" alternatives result in additional levels of indentation in this case.

> 4. you keep harping on this structured vs. non-structured programming thing instead of addressing the much more important point that in order to avoid bugs we need to employ formal methods (which is another thing that Dijkstra was right about)
It doesn't matter if you use break/continue for automated formal methods, they can just reconstruct the formal invariant anyway. And manually applied formal methods basically failed for anything non-trivial.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 6, 2020 19:23 UTC (Sun) by HelloWorld (guest, #56129) [Link] (2 responses)

All "structured" alternatives result in additional levels of indentation in this case.

This is purely a matter of how you choose to indent your code. It works just fine with only one level of indentation:

while foo and begin
  # several statements
  not bar
end do
  # more statements
end

But anyway, you've clearly made up your mind about this, and fortunately I don't need to convince you.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 6, 2020 19:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Gah. Your example is even WORSE than several levels of indentation, as it completely confuses condition and the body of the statement.

It's not a coincidence that Fuzzing is added to Go

Posted Sep 6, 2020 23:06 UTC (Sun) by HelloWorld (guest, #56129) [Link]

It's exactly the other way around. The statements in the "body" of the C loop up to and including "if (bar) break;" are what determines whether the loop will continue and are hence part of the condition. This is clearly reflected in the Ruby code and not in the C code, so the Ruby variant is the correct one.

This is actually kinda funny, because it shows that what Dijkstra said about BASIC also applies to C: you've been mentally mutilated by C enough to not be able to tell the condition from the body of the loop any more. I'm sorry that happened to you (-: