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

Posted Sep 5, 2020 10:49 UTC (Sat) 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

Yeah, maybe he didn't own a computer. Who cares? What he did own – unlike you – is a Turing award. You also completely fail to explain how structured programming mutilated anybody, so you're basically just trolling rather than making an actual point.

Dijkstra was right about one thing: we can't ever hope to get programs right unless we employ some kind of formal method for proving the absence of bugs, or at least certain kinds of bugs. Type systems are crucial here due to the Curry-Howard isomorphism.

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

Posted Sep 5, 2020 18:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> Yeah, maybe he didn't own a computer. Who cares? What he did own – unlike you – is a Turing award.
His theoretical achievements are great, nobody argues about it. It's his practical skills that were clearly lacking.

Here's an analogy, I studied the circuit theory and quantum electrodynamics in university. That doesn't mean that I'm qualified giving advice to an electrician on how to use their tools.

> You also completely fail to explain how structured programming mutilated anybody, so you're basically just trolling rather than making an actual point.
Ask Linus Torvalds about it, he's way more eloquent than me. But in practice enforcing the single exit from functions and banning break/continue in loops (since they break loop invariants) lead to bad code.

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

Posted Sep 5, 2020 23:09 UTC (Sat) by HelloWorld (guest, #56129) [Link] (14 responses)

I won't ask Torvalds, because you're the one who made that point, so the burden of proof is on you.

I also disagree that single exit and banning break/continue leads to bad code. A loop with a break statement looks something like this:

  while (foo)
  {
    # several statements
    if (bar)
      break;
    # more statements
  }

But this is necessary only because of the useless distinction between statements and expressions that many languages still have. Blocks are expressions in e. g. Ruby, so you can write this:

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

“break” etc. are completely unnecessary clutter, and the fact that Go nevertheless includes them only shows what a poorly designed language it is.

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

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

See? You've also been mutilated by "structured programming". You have an additional indentation layer that actually obscures the control flow.

See this thread: https://lkml.org/lkml/2003/1/12/156

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

Posted Sep 6, 2020 0:38 UTC (Sun) by HelloWorld (guest, #56129) [Link] (11 responses)

The idea that more indentation somehow ”obscures“ the code is complete and utter bullshit. There is _zero_ evidence to support it.

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

Posted Sep 6, 2020 0:47 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

There actually is: https://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf - deep indentation (be it purely visual or a result of deep nesting) hampers the comprehension.

I've seen other studies, but I'm too lazy to find them again. Deep nesting is definitely bad, and "structured programming" often requires it, while break/continue allow to un-nest some of the code.

I'm personally fond of this style:

for (i : someCollection) {
  if (i.frobBarBaz == SomeConstant) {
     // The flag frobBarBaz disqualifies the object
     continue;
  }
  if (!somethingElse(i)) {
     // This is not the object you're looking for.
     continue;
  }
  ...
}

Sure, it can be rewritten as a one long condition, split into predicates for map/filter, but often at the expense of readability.

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

Posted Sep 6, 2020 1:16 UTC (Sun) by HelloWorld (guest, #56129) [Link] (6 responses)

Deep nesting is definitely bad

Let's take some code that's indented twice:

while (foo)
  while (bar)
    baz();

And rewrite it with one level of indentation:

l1:
if (! foo)
  goto l4;
l2:
if (! bar)
  goto l3;
baz();
goto l2;
l3:
goto l1;
l4:

Yeah, you're right. That is so much more readable, I wonder why I never noticed…

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

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

OK, please now please rewrite this function without gotos or early returns: https://elixir.bootlin.com/linux/latest/source/mm/mmap.c#...

Of course if you remove ALL structure, the code becomes bad. 'for' loops are there for a reason.

However, there's an easy test to tell that early return/break/continue is well-placed. It's if it reduces (or keeps the same) the overall number of lines of code.

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

Posted Sep 6, 2020 4:03 UTC (Sun) by HelloWorld (guest, #56129) [Link] (4 responses)

> 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 (-:

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

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

In fact, it's the other way around: it's the *lack* of indentation caused by early returns that obscures the code. Somebody came up with the idea that one should return early from functions when encountering errors:

do_stuff();
if (foo)
  return bar;

do_more_stuff();

But this is downright retarded. The whole idea about indenting the contents of blocks guarded by if and while is that it allows you to tell at a glance that a piece of code is not always executed but only when some condition is true. Early returns break this: you need to read the code and notice the return statement in the if (foo) block to know that do_more_stuff() will not be executed unconditionally but only when foo is false. And even worse, it's very easy to mess up resource cleanup when coding in this style. People then came up with even more retarded ideas like “goto fail” to “fix” that, and when the Go developers noticed that people were messing that up too, they added *yet more* crap to the language, i. e. the defer statement. And then they give talks about how “Less is exponentially more” 🤦

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

Posted Sep 6, 2020 1:11 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

I have never found code using the early-return pattern hard to read.

I have, however, encountered code with deeply nested ifs, and I concur with the paper Cyberax cited that reading it is a horrible experience.

(It's still more pleasant than trying to read JSP, though.)

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

Posted Sep 6, 2020 4:41 UTC (Sun) by flussence (guest, #85566) [Link]

I first learned of the early-return pattern when doing maintenance work on someone else's PHP site in 2003. Namely, they had never heard of it, and every single page was wrapped in a giant "if access_check then page_contents else show_error" construct (not to mention the contents themselves would meander off to the right). It was downright painful to read until that got fixed.

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

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

And by the way, that E-mail is essentially a rant about Pascal which suffers from the exact same problem as C: the useless distinction between statements and expressions.