> I’m significantly older than you. I started coding in the late 60s.
Any opinion that starts with such a blatant appeal to authority can safely be ignored.
My current strategy is to not read any of the code written by my agents
11–20 of 65 posts
Re: My current strategy is to not read any of the code written by my agents
#12This is the guy that thinks optionals are too complicated? https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...
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 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.
Re: My current strategy is to not read any of the code written by my agents
#13This is the guy that thinks optionals are too complicated? https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...
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.
Re: My current strategy is to not read any of the code written by my agents
#14[flagged]
Re: My current strategy is to not read any of the code written by my agents
#15> I’m significantly older than you. I started coding in the late 60s. Any opinion that starts with such a blatant appeal to authority can safely be ignored.
It was a pertinent response to the end of the tweet he was replying to.
> Started programming in 1983. Old?
I took that sentence as asking if he was old because he couldn’t trust AI and uncle bob brought up that he was much older and trusted the AI output because he trusted his constraints and test harnesses
Re: My current strategy is to not read any of the code written by my agents
#16The author of clean code (who makes his living consulting on how to write software) has pivoted to AI in a spectacular tweet about how to set up automated software development just in time to make his living consulting about how to set up automated software development.
"How does Uncle Bob code today? Find out in Clean Vibe, the long-awaited sequel to the legendary Clean Code - coming soon from Prentice Hall!"
Re: My current strategy is to not read any of the code written by my agents
#17> I’m significantly older than you. I started coding in the late 60s. Any opinion that starts with such a blatant appeal to authority can safely be ignored.
Appeals to authority aren't necessarily bad. I would hold an opinion on the internals of postgres from someone who worked heavily on postgres internals for forty years quite highly.
Robert Martin started coding in the late 60s and then became an author and a software design consultant - his statement defines the start date of his relevant experience but doesn't speak to the end date of that experience or the density of his experience. He has a wealth of experience but not in a field that's relevant to his comment.
I think an appeal to authority is a good basis for extending a bit of extra trust to statements - but you should always verify things yourself.
Re: My current strategy is to not read any of the code written by my agents
#18This 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).
Re: My current strategy is to not read any of the code written by my agents
#19Does he read his tests and constraints? You’d need lots of tests to have that kind of confidence (SQLite has 500+ lines of tests per line of code), at which point it’s not a lot of additional work to just read the code.
Re: My current strategy is to not read any of the code written by my agents
#20But does he read all those tests to know if they're right? Or does he just ask the LLM if the test it created were good?