Back when I was the “new guy” code monkey at a fairly sizeable brick-and-mortor-and-e-retailer, I let the intrusive thoughts win and did some impromptu QA on the e-commerce site. (In the test environment. Don’t worry.)
It handled things like trying to put “0” or “-1” or “9999999999999” or “argyle” quantity of an item in the cart just fine.
But I know my 2’s-compliment signed integers. So I tried putting “0xFFFFFFFF” quantity of an item in my cart. Lo and behold, there was now -1 quantity of that item in my cart and my subtotal was also negative. I could also do things like put a $100.00 thing in the cart and then -1 quantity of something that cost $99.00 in the cart and have a $1.00 subtotal.
(IIRC, there was some issue with McDonalds ordering kiosks at one time where you could compose an order with negative quantities of things to get an arbitrarily large unauthorized discount.)
The rest of my team thought I was a fucking genius from that moment on. I highly recommend if you’re ever the “new guy” dev on a team and want to appear indispensible, find a bug that it would never occur to a QA engineer who doesn’t have a computer science degree to even test for.
A long time ago I was the guinea pig/first user for a company developed system.
I often had my 1 year old at the time son with me when I worked on the weekend. He had a great time smashing buttons on the keyboard and randomly clicking the mouse on the test version. He found most of the bugs.
The amount of times colleagues would dismiss bug reports because “they couldn’t reproduce” my steps rapidly declined when they didn’t only get the steps based on the video, but also the video.
Take that Daniel, you lazy <beeep>
Taught our test infrastructure to record and attach those recordings to the reports, too, before the manufacture of the testing tool implemented that. Good times.
To be fair, the team at the time was all business majors. (Is “Computer Information Systems” what they call that degree most places or just at my alma mater?) I think I was the only computer science major there.
They’d done a surprisingly admirable job of cobbling together a working e-commerce, loss prevention, customer sercvice portal, orderfulfillment, and CMS suite. And their schooling was in, like, finance, MS Office, and maybe one semester on actual programming.
None of them had ever learned how to count in binary. Let alone been exposed to 2’s compliment. And there were no QA engineers.
Oh, there was the sysadmin. He had a temper and was a cowboy. If you asked him to do something, it’d be fuckin’ done, man. But you did not want to know how he made sausage. The boss asked him to set up a way for us to do code reviews and he installed Atlassian Fisheye/Crucible on a laptop under his desk. We used that for years. And a lot of the business logic of the customer-facing e-commerce site lived in the rewrite rules in the Apache config that only he had access to and no one else could decipher if they did have access.
My school also had a major called “Computer Information Systems”. That was in the 90s. Do they still even offer that? Last I checked I didn’t see my school still offering that.
I know a french degree that I would translate to Computer Information System in English but there is waay more computer science in it that what you described… I’m so glad I didn’t live thought the hardship of international studies!
The McDonalds thing was simple. 90 cent burger, minus cheese, was -10 cents. Or something along that way. Basically the “hold the cheese” value was fixed but they forgot some items with cheese are piss cheap.
I still fondly remember the QA guy on the first consumer electronics project I worked on. He didn’t do scripting or test harnesses or dependency injection, he used the product and filed good bugs telling us what would fuck up our customer’s expectations.
A good QA person helps with product design too if you let them.
Honestly, a pretty fucking hilarious take. I wonder if he’s publishing a new book because the old dead tree format was boring and there’s some new crystal inscription system he read about on the forums.
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.)
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.
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 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: joeduffyblog.com/2016/02/07/the-error-model/
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.
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.
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.
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.
[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
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
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.
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.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.