You might argue this is improper, but I think that's a bit morose. I dread the day when all people write like that second sentence.
That's not to say someone should emulate him, though. It's not that it's wrong, it's that they're bound to fail and produce something tinny and derivative. That's the thing your revised sentence has going for it: it's as cheap as it is limp.
If something becomes boring and derivative when stated plainly then there was nothing of substance to start with.
> Good writing is terse and easy to understand.
Good writing does what it sets out to do. "terse and easy to understand" is a fantastic style for certain objectives, but there's no one "good writing" style.I think you might be blurring the lines between writing something in a socratic dialogue versus writing technical documentation. Dijkstra, obviously often is writing in the former style and so there's plenty of room for his personality in the text and it doesn't take away from the overall quality and cohesiveness of the text.
I also don't mind unsubstantiated claims. It's just obnoxious to phrase it like "any person with half a brain knows [controversial claim]".
This bugs me as well. He's obviously made profound and exceptional contributions to the field but I don't like when he writes in the manner you pointed out where he's making bold statements without evidence. Worse is when people quote something Dijkstra wrote that he didn't back up with evidence as if it's true just because Dijkstra wrote it.
Those who want really reliable software will discover [authority!] that they must find means of avoiding the majority of bugs to start with [unsubstantiated!], and as a result the programming process will become cheaper [unsubstantiated!]. If you want more effective programmers, you will discover [authority!] that they should not waste their time debugging [repeated assertion!], they should not introduce the bugs to start with [repeated assertion!].
He could just say:
When creating reliable software debugging takes up much time. If we develop techniques that prevent these bugs from being introduced in the first place then programmers will become much more effective.
Good writing is terse and easy to understand. It should lead the reader from the premises to the conclusions. Good writing shouldn't contain pretentious detours. I don't think you should emulate Dijkstra.