Hacker News Reader

Comment by daaaaaaan | Hacker News Reader

This is the guy that thinks optionals are too complicated? https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...

View on HN

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.

Bob Martin has built a career on asking the wrong questions. He is doing the same here as well.

I think Uncle Bob worship by OOP adherents is crazy, but I also think dismissing him this way is also crazy. His work on popularizing methods for writing good OOP is solid.

But at the end of the day, he's a guy with a long career in programming, which makes him significantly better than the median, but it doesn't make him three sigma above.

In this case, he's got a pretty good short- to medium-term argument that if you have a robust testing and verification suite, AI code that passes it all is a terrific outcome.

I'm really not convinced about long-term. Possibly, AI ends up writing even better in the future and we never have to worry about human maintainability.

But it's also possible AI is at/near its limit, and we'll always need human maintainers. In which case, incomprehensible vibe coding might be a problem.

You just have to make maintainability and readability explicit criteria at the strategic level and hold the AI accountable yourself, same as with testing and linting and the tactical level. Fable can generate code that is absolutely readable by a middle school kid, it'll just be less efficient at it than full jargon-laced fanciness, so finding the sweet spot isn't too hard.

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 every time there is a bug, as he asserts. It requires language features to let you be descriptive in your type definitions so that invalid program states don't exist by definition. You literally cannot write one down. It's the same idea as saying you can't assign a Monkey to an int64. Scala's ZIO also shows that in fact you can type-infer whether a given path will produce errors or nulls, so you don't need to have perfect knowledge up front or go back and change tons of code if that changes. Errors can automatically propagate, and you need to handle them once, somewhere. Checked exceptions were a fantastic idea; you just need to let the compiler infer them everywhere.

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.

That's just a nonsense answer though. Like if you have an Account class and a Book class, do you test what happens if you do an invalid, forced typecast to pass a Book to a function that expects an Account? Of course not. You'd have to check that every function "correctly" handles every possible invalid input. Otherwise where do you draw the 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.

You can both test your code for correctness, while also letting the compiler enforce correctness, and communicate important information to people reading your code.

Reply on news.ycombinator.com