I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.
(To be clear, I realize you’re kidding. But I do think it’s important to know just how at odds the TDD philosophy is from the “safe languages” philosophy.)
This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:
Here is a new feature modern languages are starting to adopt.
You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.
The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?
And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…
Yeesh, I thought you were being hyperbolic, but it really is that bad! He even has this massive self report towards the end:
And how do you avoid being punished? There are two ways. One that works; and one that doesn’t. The one that doesn’t work is to design everything up front before coding. The one that does avoid the punishment is to override all the safeties.
And so you will declare all your classes and all your functions open. You will never use exceptions. And you will get used to using lots and lots of ! characters to override the null checks and allow NPEs to rampage through your systems.
Uncle Bob must be the kind of guy who makes all of his types any when writing Typescript.
For example, in Swift, if you declare a function to throw an exception, then by God every call to that function, all the way up the stack, must be adorned with a do-try block, or a try!, or a try?
I agree with him on this point. Sounds similar to how it’s in Java, and I hate it. I always wrap my exceptions in a RuntimeExceptions because of this.
I disagree with him the rest of the post. The job of the programmer is to communicate the intent of the program. Both for others and for yourself. The language provides the tools to do so. If a value is intended to be nullable, then I would like to communicate this intent. I think it’s good when a language provides this tool.
Tests don’t communicate the intent of the code. Tests can’t perfectly validate all the possible edge cases of the system either.
Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.
Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I’ve seen them used to simplify the inner workings of some frameworks.
I think they get a bad rep because there aren’t a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.
Imo, if a method require the caller to do error handling, then that should be part of the return value. For example, use optional or either. Exceptions shouldn’t be part of any expected control flow (like file not found). Exceptions is an emergency panic button.
The problem is that most languages with exceptions treat that as the idiomatic error mechanism. So checked exceptions were invented, essentially, to do exactly what you say: add the exception type to the function signature.
Having separate errors-as-return-values and unwinding-for-emergencies is a much more recent trend (and, IMO, an obviously good development).
I’m not sure why it’s “obviously” good to move from one mechanism to two: as a user I now have to categorise every path to work out which is appropriate.
What I said was less about adding to a function signature than it was about adding to a facade - that is, a system boundary, although the implementation may be the same depending on language. People typically use exceptions pretty badly - a function signature with a baggage-train of internal exceptions that might be thrown by implementation guts is another antipattern that gives the approach a bad rep. Errors have types too (or they should have), and the typical exception constructor has a wrapper capability for good reason.
My own use of jvm errors tends to follow the same kinds of patterns: I think the major fault with that model is having RuntimeException as a subclass of Exception, because it’s really intended for abandonment-style errors. (The problem is that lots of people use it instead as an exception system in order to cut down on boilerplate.)
I find it eye-opening that the author prefers callsite annotation with try (although I’m not going to argue with their experience at the time). I can see this being either “no big deal” or even “a good thing” to Rust users in particular - mutability and borrowing annotations at both callsite and definition aren’t required to make the language work afaict (your ide will instantly carp if you miss 'em out) but the increased programmer visibility is typically seen as a good thing. (Perhaps this is down to people largely reviewing PRs in a browser, I dunno.) Certainly there’s tons of good food for thought there.
That’s fine, and for that there are sum types. My own opinion differs - it’s a question of taste. Being able to bundle the handling of exceptional situations aside from the straight-line logic (or use RAIi-style cleanup) is notationally convenient.
Yes, you can do the same with monads; use the tools available to you.
The exception is part of the method signature and thus part of the return value. I don’t see a difference between using if or try-catch to validate a method call.
I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.
Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.
We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.
One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.
Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.
How is that different than what Go, for example, does? An if err != nil after each statement is just as annoying. In the end you have to validate almost all return values and the way it happens is just syntax.
His take strangely acknowledges that defects are caused by programmers, yet doesn’t want to improve the tools we use to help us not make these mistakes. In summary, git gud.
Experience has taught me that I’m awfully good at finding and firing foot guns, and when I use a language that has fewer foot guns along with good linting, I write reliable code because I tend to focus on what I want the code to do, not how to get there.
Declarative functional programming suits me down to the ground. OOP has been friendly to me, mostly, but it also has been the hardest to understand when I come back to it.
Experience has given me an almost irrational aversion to side effects, and my simple mind considers class members as side effects
To my knowledge, the Rust’s book actually encourages writing as many automated tests as you can, as the compiler can’t catch every type of bug in existance.
Yes. True. But Uncle Bob literally complains about non-nullable types in the linked blog post.
I’m not saying testing isn’t important. I’m saying that hand-written unit tests are not the end-all be-all of software quality, and that Uncle Bob explicitly believes they are.
[In Java] you can also violate many of the type rules whenever you want or need to
Okay. Well maybe being able to not spell out types every single time would also count as not burdening the programmer ¯\_(ツ)_/¯
I bought Clean Code when I started learning programming, some of it was useful, but now I understand that it was too opinionated for a beginner
Edit: also
Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job[?]
It is language’s job to enforce risk management wherever possible, humans are demonstrated time and time again to be poor at risk management (same for the other questions like ‘whose job it is to check for nulls’
Edit2:
Defects are the fault of programmers. It is programmers who create defects
… and that is why he proposes to not help programmers with language means. I never thought that views of how problems should be tackled might differ so much while having in mind the same reasons and goals.
Albeit I do agree that one must write tests, even if language helps, not everything can reasonably be automatically checked
Funny how he is actually now a fan of Clojure yet the examples in his book are actually full of mutating data and side effects. And Rich Hickey also stressed that tests are no silver bullet.
You can write an unmaintainable fucking mess in any language. Rust won’t save you from cryptic variable naming, copy-paste code, a complete absence of design patterns, dreadful algorithms, large classes of security issues, unfathomable UX, or a hundred other things. “Clean code” is (mostly) a separate issue from choice of language.
Don’t get me wrong - I don’t like this book. It manages to be both long-winded and facile at the same time. A lot of people seem to read it and take the exact wrong lessons about maintainability from it. I think that it would mostly benefit from being written in pseudocode - concentrating on any particular language might distract from the message. But having a few examples of what a shitfest looks like in a few specific languages might help
As an example of a language that many people are familiar with, which is likely to be in long-term use where maintainability is most important, and which can almost read like pseudocode anyway, sure - probably the best ‘real language’ choice.
But is he rewriting in Rust?
Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.
(To be clear, I realize you’re kidding. But I do think it’s important to know just how at odds the TDD philosophy is from the “safe languages” philosophy.)
Ahhhh, the ol’ “dynamic languages are better than static languages because I have tests that check for different types” argument.
This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:
And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…
It makes no sense.
Yeesh, I thought you were being hyperbolic, but it really is that bad! He even has this massive self report towards the end:
Uncle Bob must be the kind of guy who makes all of his types
anywhen writing Typescript.I agree with him on this point. Sounds similar to how it’s in Java, and I hate it. I always wrap my exceptions in a RuntimeExceptions because of this.
I disagree with him the rest of the post. The job of the programmer is to communicate the intent of the program. Both for others and for yourself. The language provides the tools to do so. If a value is intended to be nullable, then I would like to communicate this intent. I think it’s good when a language provides this tool.
Tests don’t communicate the intent of the code. Tests can’t perfectly validate all the possible edge cases of the system either.
Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.
Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I’ve seen them used to simplify the inner workings of some frameworks.
I think they get a bad rep because there aren’t a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.
Imo, if a method require the caller to do error handling, then that should be part of the return value. For example, use optional or either. Exceptions shouldn’t be part of any expected control flow (like file not found). Exceptions is an emergency panic button.
The problem is that most languages with exceptions treat that as the idiomatic error mechanism. So checked exceptions were invented, essentially, to do exactly what you say: add the exception type to the function signature.
Having separate errors-as-return-values and unwinding-for-emergencies is a much more recent trend (and, IMO, an obviously good development).
I’m not sure why it’s “obviously” good to move from one mechanism to two: as a user I now have to categorise every path to work out which is appropriate.
What I said was less about adding to a function signature than it was about adding to a facade - that is, a system boundary, although the implementation may be the same depending on language. People typically use exceptions pretty badly - a function signature with a baggage-train of internal exceptions that might be thrown by implementation guts is another antipattern that gives the approach a bad rep. Errors have types too (or they should have), and the typical exception constructor has a wrapper capability for good reason.
I should have stressed the “opinion” part of “IMO”. What I mean is that, when I read this, it struck me immediately as being exactly correct: https://joeduffyblog.com/2016/02/07/the-error-model/
That’s a cracking article.
My own use of jvm errors tends to follow the same kinds of patterns: I think the major fault with that model is having RuntimeException as a subclass of Exception, because it’s really intended for abandonment-style errors. (The problem is that lots of people use it instead as an exception system in order to cut down on boilerplate.)
I find it eye-opening that the author prefers callsite annotation with
try(although I’m not going to argue with their experience at the time). I can see this being either “no big deal” or even “a good thing” to Rust users in particular - mutability and borrowing annotations at both callsite and definition aren’t required to make the language work afaict (your ide will instantly carp if you miss 'em out) but the increased programmer visibility is typically seen as a good thing. (Perhaps this is down to people largely reviewing PRs in a browser, I dunno.) Certainly there’s tons of good food for thought there.That’s fine, and for that there are sum types. My own opinion differs - it’s a question of taste. Being able to bundle the handling of exceptional situations aside from the straight-line logic (or use RAIi-style cleanup) is notationally convenient.
Yes, you can do the same with monads; use the tools available to you.
The exception is part of the method signature and thus part of the return value. I don’t see a difference between using if or try-catch to validate a method call.
I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.
Consider this example:
try { File file = openFile(); String contents = file.read(); file.close(); return contents: } catch (IoException) { }Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.
We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.
One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.
Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.
How is that different than what Go, for example, does? An if err != nil after each statement is just as annoying. In the end you have to validate almost all return values and the way it happens is just syntax.
His take strangely acknowledges that defects are caused by programmers, yet doesn’t want to improve the tools we use to help us not make these mistakes. In summary, git gud.
Experience has taught me that I’m awfully good at finding and firing foot guns, and when I use a language that has fewer foot guns along with good linting, I write reliable code because I tend to focus on what I want the code to do, not how to get there.
Declarative functional programming suits me down to the ground. OOP has been friendly to me, mostly, but it also has been the hardest to understand when I come back to it. Experience has given me an almost irrational aversion to side effects, and my simple mind considers class members as side effects
To my knowledge, the Rust’s book actually encourages writing as many automated tests as you can, as the compiler can’t catch every type of bug in existance.
Yes. True. But Uncle Bob literally complains about non-nullable types in the linked blog post.
I’m not saying testing isn’t important. I’m saying that hand-written unit tests are not the end-all be-all of software quality, and that Uncle Bob explicitly believes they are.
Okay. Well maybe being able to not spell out types every single time would also count as not burdening the programmer ¯\_(ツ)_/¯
I bought Clean Code when I started learning programming, some of it was useful, but now I understand that it was too opinionated for a beginner
Edit: also
It is language’s job to enforce risk management wherever possible, humans are demonstrated time and time again to be poor at risk management (same for the other questions like ‘whose job it is to check for
nulls’Edit2:
… and that is why he proposes to not help programmers with language means. I never thought that views of how problems should be tackled might differ so much while having in mind the same reasons and goals.
Albeit I do agree that one must write tests, even if language helps, not everything can reasonably be automatically checked
wtf did i just read?
The blog post? Yeah, that was the moment I lost most of my remaining respect for his tech opinions.
Funny how he is actually now a fan of Clojure yet the examples in his book are actually full of mutating data and side effects. And Rich Hickey also stressed that tests are no silver bullet.
You can write an unmaintainable fucking mess in any language. Rust won’t save you from cryptic variable naming, copy-paste code, a complete absence of design patterns, dreadful algorithms, large classes of security issues, unfathomable UX, or a hundred other things. “Clean code” is (mostly) a separate issue from choice of language.
Don’t get me wrong - I don’t like this book. It manages to be both long-winded and facile at the same time. A lot of people seem to read it and take the exact wrong lessons about maintainability from it. I think that it would mostly benefit from being written in pseudocode - concentrating on any particular language might distract from the message. But having a few examples of what a shitfest looks like in a few specific languages might help
Java is a fine choice. Much prefer it over pseudocode.
As an example of a language that many people are familiar with, which is likely to be in long-term use where maintainability is most important, and which can almost read like pseudocode anyway, sure - probably the best ‘real language’ choice.
Prolly Clojure. He’s heavily on Clojure these days.