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

▲

reliabilityguy a day ago | parent [-]

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.

▲

relativeadv a day ago | parent | next [-]

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

▲

KPGv2 a day ago | parent [-]

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.

	▲	jaggederest a day ago \| parent [-]
		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.

▲

ndriscoll a day ago | parent | prev | next [-]

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.

▲

a day ago | parent | prev | next [-]

[deleted]

▲

vkou a day ago | parent | prev [-]

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