61–65 of 65 posts
This is the dude who ushered in the age of nonsensical boilerplate-ridden OOP code where you need to go down a bajillion of abstraction layers to see the actually implementation. Makes sense that he doesn't care about the bajillion lines of code AI produces as long as it looks good (on the surface).
Earlier quoted context omitted.
Interesting read. To his defense: the argument is not that Optionals are too complicated, but that it’s a wrong path for language design — instead programmers have to test their code properly. I like optionals, but I see his point too.
Which is a stupid argument that completely misses the point. If you let the compiler prove that nulls (or other invalid states) can't happen (because null isn't a value of that type), then you don't need to test these impossible cases. So it's easier to ensure your tests are solid because there's not a ton of noise checking what happens inside of invalid program paths. This does not require a new language feature eve…
Earlier quoted context omitted.
Which is a stupid argument that completely misses the point. If you let the compiler prove that nulls (or other invalid states) can't happen (because null isn't a value of that type), then you don't need to test these impossible cases. So it's easier to ensure your tests are solid because there's not a ton of noise checking what happens inside of invalid program paths. This does not require a new language feature eve…
Your compiler can't prove null doesn't exist if you have unsafe, and you end up being better off having tested in the first place. And how do you know your compiler is even functioning correctly? Testing is the bottom line.
Or you just rely on the type checker to say you're not allowed to pass a Book to a variable of type Account, and you never use casting (incidentally, I don't remember where, but I remember Clean Code having some example of "good" code that relies on casts, which shows the mindset). Then you literally can't even write a test case for this, because it's impossible to write the illogic at all.
If the compiler produces wrong code, all bets are off. Your tests can also miscompile. Your unsafe code could modify another thread's stack memory between instructions and act as an evil gremlin so that literally no line is trustworthy, so even your null check is pointless. Or you could... not do that, and treat your programs as logical reasoning.
Charles Babbage even addressed this:
> On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
I keep posting this but it keeps being relevant. I had an agent implement a feature completely backwards. It wrote a whole bunch of tests proving the correctness of the implementation. All the tests passed. The really interesting thing to me is that formal verification wouldn't have helped there either -- it would have just written a mathematical proof of the correctness of the backwards feature.
Wait, did you let the same agent write the tests that wrote the implementation? Or was it that the plan was the wrong way round, and both the generator of code and the generator of the tests followed that same incorrect plan? Also, what were your mechanisms for reviewing the plan against the described business outcome? Anything else you could have done there to catch the backwardness? And finally, did you run any of…