The language technology he's searching for is called dependant types. It allows you to encode the checked condition in a type which prevents checking it again. On the other hand having double checking being your main source of bugs means that you really try your best to write bad code. The whole talk boils down to: double checking conditions is bad and we found it 20 years after everybody else. His solution is: 1) do asserts instead of if-s (which doesn't match with the 2 other points) 2) & 3) implement an object oriented haskell and sprinkle some dependant types. Also you get the bonus of him interpreting "goto considered harmful" instead of quoting which bugs me to no end.
There's a bug in the Haskell code at 42:08. It should read fact (number n) = n*fact(n-1) It's trying to find the factorial, not the Fibonacci sequence.
14:05 - that's true for all loops. Heck, it's even true with recursion and either an iterative or recursive implementation of `map`. That's definitely not a problem with `goto`. The problem with `goto` is that it makes the program heterogeneous or non-uniform. With a structured loop, you know each iteration always does the same thing. With wild `goto`s, that's not true.
Nowadays you can approach a lot of this stuff using functional patterns. Null class references can be dealt with cleanly using an Option class. In Java, it would look something like this: class BigClass { Optional optionalC = Optional.empty(); BigClass() { // Might set optionalC by using the following code fragment: // optionalC = Optional.of(new LittleClass()); } void bigMethod_approach_1() { LittleClass c = optionalC.get(); // throws exception if empty // use c here... } void bigMethod_approach_2() { // map applies closure iff optinalC is non empty. optionalC.map((c) -> { // use c here... return c; }); } } Also, a functional approach would work better for the red/green example too: class Money { int number; private Money() {} Money(int amount) { number = amount; } Money mapPositive(IntConsumer fn) { if (number >= 0) fn.accept(number); return this; } Money mapNegative(IntConsumer fn) { if (number < 0) fn.accept(number); return this; } @Override public String toString() { this.stringValue = new String(); return this.mapPositive((int n) -> { this.stringValue = String.format("GREEN: %d CR ", n); }) .mapNegative((int n) -> { this.stringValue = String.format("RED: %d DR ", n); }) .stringValue; } private String stringValue; }
not really. as in, not really epic, as well as "not really" reaction to the quote. a thought is a thing. therefore, a program, even a yet unwritten one, that still only resides in your head, is a thing. in general, anything that can be in any way separated out from everything around is "a thing".
@@MidnightSt It's a mathematical object which cannot be clearly projected in material form. In the same way that there is no such thing as a circle even though we see them in our mind. In real life anything that appears to be a circle likely deviates from a real circle by some amount. The second definition of thing is an inanimate material object distinct from a sentient being. I think the author is correct in saying that programs are not things, they are mathematical objects.
"This was about two and a half MILLION lines, so IT WAS NOT A MAJOR PROGRAM." hearing this sentence after just having finished watching the talk "GOTO 2016 - Small Is Beautiful - Kevlin Henney" is... utterly absurd. also, how topical that for some reason the dots (which I replaced by "-") in the Henney's talk cause youtube to bug out and be unable to copypaste that talk name, as well as paste in whole text comment first copied into notepad.
Yeah, this talk is a load of rubble. Kevlin never has that pretense of selling you a panacea, and still manages to actually convey gem after gem of actual wisdom, while citing historic publications that track the change of thought over time. With Kevlin you realize the answer is in front of us, it's just hard to get all the pieces together. Talks like this one go rogue trying to push bizarre contrarian ultimatums acting like the world needs to catch up.
That's pretty much it. That implies keeping programs as short as possible and be suspicious of any addition of code. If there is heavy reuse of code, then the bugs will be heavily reused too, and that will make them attract more attention than many bugs that are scattered in reams of seldom-used special-case code.
25:40 how to fix bugs: first ask if is it legit that I have a null pointer here instead of making a foolish patch that sweeps the problem under the rug
At the end this turn out to remove the if (condition) duplicates by groping their respective branch in a correspondent branch line of codes in a subclass. So, from my point of view is not that if are harmful, but code duplication and our unawareness of it who causes the majority of the bugs. Besides that I should add 2 problems with this pattern: 1. It's counterintuitive becouse type systems are not supposed to be used to represent control flow (I know that this claim could be addressed in the future with another construct) 2. If I am unaware of the duplication this pattern doesn't stop me to only change the code in one place (This is typically the case when I have the same entity represented by different objects in diferent layers of the program)
"1. It's counterintuitive becouse type systems are not supposed to be used to represent control flow (I know that this claim could be addressed in the future with another construct)" Actually they are. Type systems are about formally proving any property of a program. It's just the common weak type systems (C, Java, etc) people are used to that are not very good at representing control flow. Even there, though, polymorphism for example is a control-flow substitute that type systems enable.
I understand his argument about the null pointer in code and how it can be harmful but consider building a large scale project in C++ such as a Game Engine where you have to dynamically create objects on the fly during runtime... this means the objects will not be local to the stackframe, they are not temporaries that have the life of the scope of the block since they live in the heap and their lifetime extends that of the function that creates it. Now consider having a class that manages the storage of all of your assets such as textures, models, font files, audio files, etc... you want to create a single instance of that object with a specific ID and you want to store it into some container. For efficiency reasons, the next time you need to create another instance of that same object, there is no need to copy or duplicate it, you can always reference the original that has its own "property" struct associated with that reference... Let's say we have a container such as an std::vector that lives in our StorageDatabase class... These contain the instances... Alongside that we have an std::map which is our reference map... The vector is used to store the objects where these are stored locally, yet dynamically we use the map to easily index to find the texture we want via it's key or id... The map contains the ID of the texture and a pointer to the original instance. Now it's time to search our container to find the texture we want to apply it to some shape or model object... If we don't account for `nullptr`s the program shouldn't abort, throw an exception, or needs to be asserted... if the pointer is nullptr we can still draw the shape without the texture and the program can continue execution. However, if the pointer to the texture is valid and we try to apply that to the shape, geometry, or model and its pointer is null, then, in this case, we do have a problem and need to throw some kind of warning because we have an invalid model object that can't be rendered... In this case the game mechanics such as collision detection, object interaction, game progression or state changes, particular levels or maps might rely on it. So here we do need null pointers! It's not that they are bad or that they are the source of bugs, it is more about the semantics of knowing when, where, and how to use them appropriately! With modern C++ most of this can be automated for us through the use of smart pointers and we have less to worry about when it comes to invalid pointers, dangling pointers, invalid references, memory leaks, etc. There never is a one solution fits all when it comes to software design! It all depends on the type and nature of the application and its intended uses. It depends on the context in which it will be used. Another simplified example might be this... consider having a model that consists of multiple sub-models and that those sub-models have to be valid in order for the main model to be constructed. If those sub-models have an invalid pointer, then you shouldn't be able to create the main model. At the end of the day, it depends if the object is temporary and lives on the stack with a short life span or if it is dynamic, lives in the heap with a life span longer than the function it is created in...
I am very sceptical of his suggestion to NEVER use Null pointers and use the Null Object Pattern instead. But first off if we did use it, it wouldn't actually be a functional detriment, since then you could have a single Null Object which stands in for all the objects of the same type which don't have any unique or sensible data, as an interface-compatible, safe-to-use stand-in. When you do end up generating the data that would populate the object (i.e. asynchronously loading in a texture from disc and uploading it to a hardware buffer), it would need to be replaced with the newly generated object in the collection/containers, just like Null pointer would get replaced by a final object. It would also help if the objects - such as textures, pieces of geometry, etc - are immutable or at least pretend to be. It wouldn't also necessarily be a storage efficiency detriment, since you can have the type be a smartpointer which would dereference into an existing Null Object when the underlying storage is actually a Null pointer. But i suggest that it might not be a good idea. Typical implementations use numeric 0 for the value of Null pointer, and simultaneously invalidate the first page of address space, to make dereference operation fail pretty reliably, and you get a crash report with a backtrace, indicating the location in the program where the error has occurred. In the case Null Object Pattern is used instead, you get logic errors, where the software misbehaves, but you don't have a clear clue on where or why, because it continues to operate. This whole talk is on IF conditions being wrong or having wrong set of consequences attached to them, so essentially logic errors leading to incorrect behaviour and thus long-standing tedious bugs, so it seems counterproductive to suggest an on-paper solution which trades a very specific crash for a logic error and incorrect behaviour.
I just tried a very simple implementation and I have the impression that where ever I turn, the if still has to go somewhere. Removing it from the main flow and sifting it into an object/constructor/factory may "even out" the if density so that ifs are uniformly distributed, but still it can't disappear completely. So maybe I got something wrong or he actually wants to reduce the density in small code portions. Or maybe that's just an intermediate step. So "moving" ifs to avoid complex code is ok, but thinking that they will go away completely looks utopic to me.
@Gwen Lofman After I learned Haskell, I hate null. Why should it be the case that any reference type in languages like C# and Java can be null? Now I have to always handle the case that everything is null, or otherwise risk runtime errors. This aspect of the type system is completely asinine and anxiety-inducing. C++ is a lot more inherently dangerous, with its pointer arithmetic and manual memory management, so I can't complain about null so much over there. But I'm certainly glad Rust does away with null in safe code, for the same reasons.
@@joshuakb2 Yeah, it’s super weird that these are considered type-safe compiled languages, yet everything is potentially the “null” type, which is utterly useless except as a way of letting lazy programmers avoid fully constructing their data. The impact of that is phenomenally bad... I love the idea of encoding “optionality” into the type itself, so we can know which specific pieces of data might be missing without worrying about that anywhere else.
@@joshuakb2 "C++ is a lot more inherently dangerous, with its pointer arithmetic and manual memory management" When was the last time you actually wrote C++?
Interesting analysis! In the end though, if I remember correctly, it is known that if and switch statements can be a replaced by polymorphism and factories. Isn't that part of solid? Anyways, good analysis!
A Null pointer makes sense when you want to prevent it of being uninitialized when there is no object to point to. Btw can someone bring more water for this guy please? Edit: My comment is misleading. I mean not "uninitialized" but initialized with a random address, that can be very harmful.
A dummy object wouldn't be a good idea, because I would like to have the option to determine if the pointer is already initialized or not. I wouldn't consider a null object a good idea either, because if I forget to initialize the pointer, the program seems to do just fine until the moment I get weird results. Then I would pray for an exception instead of being forced to debug the whole stuff.
@@eyebee-sea4444 Why do want to be able to test if the variable is not initialized? What couldn't you do if you test if the pointer point to the initial dummy object? You could call the object Uninitialized.
Why do I want to be able to determine if a variable is initialized or not? Are you serious? No matter of what you use as an indicator, null or a dummy object, you have to be sure the variable is in a initialized state when you use it. If it is not and you use null, you get an exception. If you use a dummy instead, you get no exception, but you operate with a de facto uninitialized variable and you don't necessarily realise it. In the worst case the program seems to work just fine, even passes the unit tests, until one day the customer calls you back, because some calculations your program does are erroneous ... sometimes ... in specific cases.
@@eyebee-sea4444 Yes, I am serious. It all depends on why you need it. The default object can throw only exceptions. In this case you can name the exceptions. In other cases a default implementation may be required. It all depend on why you want something. I view null pointer as a bad design. All that tells me is that a pointer can not be dereferenced, but does not tell you what is wrong.
In summary: "IF" - baaaad "SWITCH" - Gooood "GOTO" - neutral - neither inherently good or bad (got a bad rap) Apple computers (and their users) - VERY baaaad
Assert makes it obvious that you're checking for invalid state not invariants. "assert or throw" doesn't seem to make sense to me. Don't even know in what language that'd work and what it'd do (hard error in debug, exception in production?). Maybe it's just pseudocode.
That should be “if( not condition)”. One problem with exceptions is that they are used for multiple purposes. Sometimes an exception just indicates and unusual condition that was anticipated by the programmer and requires handling. And sometimes exceptions are used to indicate that there is a defect in the code itself. He’s using asserts for the latter case. Other than that, there’s no difference and he shows that you can get exactly the same effect as “assert x or throw ...” with “if( not x) throw ...”.
"I don't think it's goto that's harmful, I think it's 'if goto' that's harmful" well... except goto without condition can either create a deadzone (code that will never get executed) or an infinite loop... There's no other option. Which means goto without if is useless... Or, to be precise, goto without if is either useless ( when it jumps forward - because you're better off actually deleting the code it skips, since it's dead code), or a bug by default (when it jumps backwards, because you've just created an infinite loop).
@@WolfJ you missed my point which was that goto without any condition is useless, therefore making the distinction between goto and if..goto makes no sense.
Doesn't this mean that the null conditional access operator is the root of all evil? Actually it's null itself. This is why I like functional programming languages like F#, OCaml, Rust, ReScript, etc.
I would love to hear a similar talk on Common Lisp's restart/error system and how it would be useful for avoiding the problematic branching logic. From what I've seen it looks like Common Lisp's system adds flexibility to allow more than just restarting or signaling errors, as you can automate reparation and re-enter code with much flexibility.
Man I really love Jules’ presentation here, but I wish it could’ve been presented more simply. Some things are inherently complex so maybe it’s not possible. But maybe it is. I think it’s harder to say whether it’s impossible unless you try.
4 ปีที่แล้ว +2
43:51, 45:07 - oh come on, enough with the vocal noises already, it sounds horrible through headphones! (drinking, gulping, mouth clicking...)
Why not create a single source file `if-conditions.hpp`, and put _every_ if condition in that? Then we've clearly separated all the conditions from the rest of the code. (The consequences.)
That wouldn't solve anything. You've only moved all the conditions to a single file, and you're now using the preprocessor to put them back. The problem is that the very presence of the conditions makes the code hard to reason about. The proposal here is to lean on the type system so that the computer makes a decision *once* and that point is at object creation time. There are languages that achieve what he's aiming for, but they're not yet widely used, by using something called *dependent types*, something that might hopefully get into the mainstream soon.
I've wondered for a while whether the mathematics origin of so much computing lends itself to thinking of programming Platonistically (timeless, capable of perfection, etc.). Turing himself was not subject to this, but he was a very unusual guy. (I suspect that he did math because he was good at it, not because it was really he was on about most of the time.)
Goto’s don’t cause bugs. I use goto’s in C to get 1 exit from functions (or sometimes just a couple of exits at the bottom of the function) and a couple of other very narrow techniques (like retry). I have never discovered a single bug because of any goto in many hundreds of thousands of green field C code. Not a single one. The vast majority of errors I get that aren’t trivial syntax errors that are fixed in seconds, are memory bound errors. You have a buffer and your pointer goes past the end of the space you have allocated (or you access elements of an array past it’s limit). I also find that allowing NULL pointers as a signal for something not working is a disaster waiting to happen. Dereferencing a NULL pointer will at the least cause an unrecoverable error or a program crash. Don’t use stupid NULL pointers.
@@clarkd1955 Sorry, I must have misunderstood your comment as supporting the use of NULL Values. In conclusion, leaving NULL values around your software is not a good practice, and any language should make it as hard as possible to use such a value.
Errors that are fixed on first pass don't really count. The talk is fundamentally about logic errors, bugs remaining in at least medium-sized software of at least several hundred thousand lines, which generally have a particular density of known misbehaviours or bugs, issues that are invisible at first sight and evade code review and any automated means again and again, so they just sit there littering any sufficiently complex software. As large software develops and ages, the conditions and consequences which once obviously belonged together become separated by a good bit of code distance, and can even become aliased under different names, making them difficult to keep track of. For example if one spot says if(A) and another says if(B), but it turns out that B can only be true if A is true, or has some other kind causal relationship to condition A, then when you modify the action that happens when if(A), you may fail to update the other dependent actions under aliases and which live further away. Thus long-standing, difficult-to-find logic errors. Dereferencing a NULL pointer is UD as per spec but implementations are free to constrain it and substitute well-defined behaviour instead, and commonly (e.g. on all multitasking desktop operating systems with all toolchains i can think of), this is exactly the case, you see numeric 0 used for NULL pointer, with zero-page being made inaccessible, which crashes the software reliably, and you can get a backtrace which pinpoints EXACTLY where the issue is. Naturally the solution is not to blindly stick an "if(!ptr) return" in there but think about WHY it happened and what to do about it. If you think it's a "disaster waiting to happen", well to me it's the opposite, it's an opportunity for an easy discovery of the origin of a bug - but i wouldn't exactly program software for a nuclear power plant this way. In fact the latter better have exactly zero allocations AT ALL. As opposed to desktop operating systems, MMUless embedded systems don't generally have a NULL pointer dereference guard of any kind (thus the UD spec makes sense), obviously you adjust your approach to the target you're dealing with and take consequences of the kind of bug that can happen in account. For some cases, Defensive Programming, where you try for foresee ways for the software to continue execution in all eventualities and in case of bugs, is actually a good idea. But when developing multi million line desktop software that is not anyhow life critical, you have a barrage of bug reports raining down on you and much too little time and you need to find ways to increase the speed at which you fix them and improve correctness of the software, even if you have to temporarily inconvenience the users by a crash to get there, thus Offensive Programming. Defensive and Offensive Programming are two opposite approaches to software quality that both make sense situationally. Life is too short and software isn't developed under ideal conditions where you have endless time to chase down mystery bugs. Buffer overruns can be a bit insidious, as there is generally a chunk of valid memory right behind the allocated region and only in rare cases will this particular kind of invalid dereference cause a crash, but they are subject to be found with automated means such as asan or valgrind. Some of the least comfy crash bugs i have seen have been multithreading synchronisation bugs, and also iterator invalidation, where backtraces as they come back simply don't make sense, and almost all the time software works, except there's a mystery crash sometimes. Also not my favourite: resource hoarding bugs, where the program has the behaviour of a slow memory leak and just gradually slows down during the session of use, as the size of data structures keeps ballooning and increases search space, but tool assisted tests come back inconclusive, because there is no technical leak as the objects or resources appear to still be tied into something, even though they have become practically useless and should have been cleaned up. I am critical of his claim that NULL pointers should never be used and Null Object Pattern is to be used instead, because it makes the software not crash, but it does NOTHING for program correctness. I.e. if someone didn't think to check the NULL pointer, similarly, they will fail to handle the Null Object correctly, such as will fail to replace it with actual useful data in time, and the software will just sometimes not behave correctly and where the issue comes from will remain a mystery, which is the whole thing he seeks to avoid with if-considered-harmful. Null Object Pattern is particularly incompatible with Offensive Programming approach.
I'm not a big fan of break, or return for that matter. To me that block between the curly brackets should either execute or not execute and you should only crash out part way through for an exception, and exceptions shouldn't be part of "normal" flow.
But on return you'll end up setting a flag like "found" rather than just returning the result which can obfuscate normal flow to satisfy the single return normal flow constraint. Yes, often you can structure code with while and a function but that might make say scanning arrays harder to reason about. It's a matter of good taste rather than absolutism. Having had to write at one time a significant amount of code in Pascal without return or break or exceptions, the purity was in practice detrimental; tasteful C was both clearer and more concise because it avoided control flow flags and allowed pre-intialised static data. For clarity and concise code, very often I'd simply assign defaults updated conditionally which the compiler often optimised to branchless code avoiding the synchronisation and code duplication that seems to me to be the root cause of the bugs in that originally Delphi (Pascal) codebase. But for that you need to decompose the problem well, I think that then avoids the anti-pattern, but he showed toy not real examples and in C it was simple to develop with conditionally compiled module tests which made updating far more reliable.
4 ปีที่แล้ว
drinking game: drink a shot every time the guy asks the audience "does this/that make sense?"
"New computer, it's an apple, it should work" ...how easily such smart people are able and willing to fall into such black holes of overpriced stupidity... =D
It appears the presenter - speaking on good software development practices - has failed to apply good software development practices and did not test. Accidents happen, and sometimes you have to beam off someone else's machine with different software because the correct adapter has somehow evaporated, but i don't know, hardly makes a case for taking him seriously, with a justification like that.
While I agree that at times he's going around and around but that's him stressing the point. What I find funny is the fact that the actual problem is not with the ifs but what he called 'synchronized state' while answering one of the questions. An object in different states should behave differently and the problem is who, where and how should enforce/ensure that. That's where the bugs are coming from: object behaves/operates/is operated on differently than it should be in its current state. Well, everything boils down to state and state management, again.
Bah humbug. 🤗 if you honestly feel comfortable saying that, then I would bet you didn’t actually understand the information well enough to judge its adequacy. The ideas are important. Big ideas take more words to illustrate. You seem to be too impatient for this sort of thinking, which is not Jules’ failing. Perhaps you are young, you may grow to love this sort of presentation as you mature a bit more. I do not know you, I am making several suppositions, but that is my sincere guess about the reason behind your comment. Good software design is all about thinking; Not consuming adequately dense information without regard to quality, but qualitative and careful reasoning.
In a sense null pointers always violate the LSP. The LSP says that if we have “T x;”, then the behaviour of “x.foo()” should be allowed by the specification of foo in T. When x is null, this is very unlikely to be the case.
The language technology he's searching for is called dependant types. It allows you to encode the checked condition in a type which prevents checking it again.
On the other hand having double checking being your main source of bugs means that you really try your best to write bad code.
The whole talk boils down to: double checking conditions is bad and we found it 20 years after everybody else. His solution is:
1) do asserts instead of if-s (which doesn't match with the 2 other points)
2) & 3) implement an object oriented haskell and sprinkle some dependant types.
Also you get the bonus of him interpreting "goto considered harmful" instead of quoting which bugs me to no end.
You don’t need full dependent types, refinement types are sufficient for this (and are simpler)
Though actually, ADTs do almost all of what he wants
@@aDifferentJT if you have GADT’s then you can almost fully encode what he’s talking about, although ADT’s will get you pretty far indeed.
There's a bug in the Haskell code at 42:08. It should read
fact (number n) = n*fact(n-1)
It's trying to find the factorial, not the Fibonacci sequence.
51:10 mm, i think cobol is still the most-used computer language in the world. it's just well-hidden
14:05 - that's true for all loops. Heck, it's even true with recursion and either an iterative or recursive implementation of `map`. That's definitely not a problem with `goto`. The problem with `goto` is that it makes the program heterogeneous or non-uniform. With a structured loop, you know each iteration always does the same thing. With wild `goto`s, that's not true.
such a shame this comment isn't (one of the) top one(s)
Correct! The problem with 'goto' is not its disruption of flow control - - it's that the target can be *ANYWHERE*.
Nowadays you can approach a lot of this stuff using functional patterns.
Null class references can be dealt with cleanly using an Option class.
In Java, it would look something like this:
class BigClass {
Optional optionalC = Optional.empty();
BigClass() {
// Might set optionalC by using the following code fragment:
// optionalC = Optional.of(new LittleClass());
}
void bigMethod_approach_1() {
LittleClass c = optionalC.get(); // throws exception if empty
// use c here...
}
void bigMethod_approach_2() {
// map applies closure iff optinalC is non empty.
optionalC.map((c) -> {
// use c here...
return c;
});
}
}
Also, a functional approach would work better for the red/green example too:
class Money {
int number;
private Money() {}
Money(int amount) { number = amount; }
Money mapPositive(IntConsumer fn) { if (number >= 0) fn.accept(number); return this; }
Money mapNegative(IntConsumer fn) { if (number < 0) fn.accept(number); return this; }
@Override
public String toString() {
this.stringValue = new String();
return this.mapPositive((int n) -> { this.stringValue = String.format("GREEN: %d CR
", n); })
.mapNegative((int n) -> { this.stringValue = String.format("RED: %d DR
", n); })
.stringValue;
}
private String stringValue;
}
"When we talk about a program, we talk about a thing...but what it actually is, is not a thing at all; it's something quite different." Epic.
not really. as in, not really epic, as well as "not really" reaction to the quote.
a thought is a thing. therefore, a program, even a yet unwritten one, that still only resides in your head, is a thing.
in general, anything that can be in any way separated out from everything around is "a thing".
@@MidnightSt It's a mathematical object which cannot be clearly projected in material form. In the same way that there is no such thing as a circle even though we see them in our mind. In real life anything that appears to be a circle likely deviates from a real circle by some amount. The second definition of thing is an inanimate material object distinct from a sentient being. I think the author is correct in saying that programs are not things, they are mathematical objects.
Interesting presentation. I'm also amazed by the presenter's superhuman ability to drink so much water and not have to take a bathroom break.
I don't understand, why switch is better than if? And I think around 30:00 and 58:00's example, the theory behind is the same as Tell, don't ask?
"This was about two and a half MILLION lines, so IT WAS NOT A MAJOR PROGRAM."
hearing this sentence after just having finished watching the talk "GOTO 2016 - Small Is Beautiful - Kevlin Henney" is... utterly absurd.
also, how topical that for some reason the dots (which I replaced by "-") in the Henney's talk cause youtube to bug out and be unable to copypaste that talk name, as well as paste in whole text comment first copied into notepad.
Yeah, this talk is a load of rubble. Kevlin never has that pretense of selling you a panacea, and still manages to actually convey gem after gem of actual wisdom, while citing historic publications that track the change of thought over time. With Kevlin you realize the answer is in front of us, it's just hard to get all the pieces together. Talks like this one go rogue trying to push bizarre contrarian ultimatums acting like the world needs to catch up.
There is a 100% correlation between programs and bugs. Please visit my talk at the next convention, titled: "Programming Considered Harmful".
That's pretty much it. That implies keeping programs as short as possible and be suspicious of any addition of code. If there is heavy reuse of code, then the bugs will be heavily reused too, and that will make them attract more attention than many bugs that are scattered in reams of seldom-used special-case code.
20:38 one condition express more than one time in controlling is the 95% of the bug
What happens at 21:45? The speaker makes the code a garbled mess and then declares we've been looking at a bug all along? Is this meant as a joke?
Netherlands031 I believe his animations crashed, he continues to have problems with his slides throughout.
25:40 how to fix bugs: first ask if is it legit that I have a null pointer here instead of making a foolish patch that sweeps the problem under the rug
sdf wer exactly, you need to do "root cause analysis" to find out why the bad state occurred.
At the end this turn out to remove the if (condition) duplicates by groping their respective branch in a correspondent branch line of codes in a subclass. So, from my point of view is not that if are harmful, but code duplication and our unawareness of it who causes the majority of the bugs. Besides that I should add 2 problems with this pattern:
1. It's counterintuitive becouse type systems are not supposed to be used to represent control flow (I know that this claim could be addressed in the future with another construct)
2. If I am unaware of the duplication this pattern doesn't stop me to only change the code in one place (This is typically the case when I have the same entity represented by different objects in diferent layers of the program)
"1. It's counterintuitive becouse type systems are not supposed to be used to represent control flow (I know that this claim could be addressed in the future with another construct)"
Actually they are. Type systems are about formally proving any property of a program. It's just the common weak type systems (C, Java, etc) people are used to that are not very good at representing control flow. Even there, though, polymorphism for example is a control-flow substitute that type systems enable.
The subtitle makes me think * "Testers hate him!" *
I understand his argument about the null pointer in code and how it can be harmful but consider building a large scale project in C++ such as a Game Engine where you have to dynamically create objects on the fly during runtime... this means the objects will not be local to the stackframe, they are not temporaries that have the life of the scope of the block since they live in the heap and their lifetime extends that of the function that creates it. Now consider having a class that manages the storage of all of your assets such as textures, models, font files, audio files, etc... you want to create a single instance of that object with a specific ID and you want to store it into some container. For efficiency reasons, the next time you need to create another instance of that same object, there is no need to copy or duplicate it, you can always reference the original that has its own "property" struct associated with that reference... Let's say we have a container such as an std::vector that lives in our StorageDatabase class... These contain the instances... Alongside that we have an std::map which is our reference map... The vector is used to store the objects where these are stored locally, yet dynamically we use the map to easily index to find the texture we want via it's key or id... The map contains the ID of the texture and a pointer to the original instance. Now it's time to search our container to find the texture we want to apply it to some shape or model object... If we don't account for `nullptr`s the program shouldn't abort, throw an exception, or needs to be asserted... if the pointer is nullptr we can still draw the shape without the texture and the program can continue execution.
However, if the pointer to the texture is valid and we try to apply that to the shape, geometry, or model and its pointer is null, then, in this case, we do have a problem and need to throw some kind of warning because we have an invalid model object that can't be rendered... In this case the game mechanics such as collision detection, object interaction, game progression or state changes, particular levels or maps might rely on it. So here we do need null pointers! It's not that they are bad or that they are the source of bugs, it is more about the semantics of knowing when, where, and how to use them appropriately! With modern C++ most of this can be automated for us through the use of smart pointers and we have less to worry about when it comes to invalid pointers, dangling pointers, invalid references, memory leaks, etc. There never is a one solution fits all when it comes to software design! It all depends on the type and nature of the application and its intended uses. It depends on the context in which it will be used. Another simplified example might be this... consider having a model that consists of multiple sub-models and that those sub-models have to be valid in order for the main model to be constructed. If those sub-models have an invalid pointer, then you shouldn't be able to create the main model. At the end of the day, it depends if the object is temporary and lives on the stack with a short life span or if it is dynamic, lives in the heap with a life span longer than the function it is created in...
I am very sceptical of his suggestion to NEVER use Null pointers and use the Null Object Pattern instead.
But first off if we did use it, it wouldn't actually be a functional detriment, since then you could have a single Null Object which stands in for all the objects of the same type which don't have any unique or sensible data, as an interface-compatible, safe-to-use stand-in. When you do end up generating the data that would populate the object (i.e. asynchronously loading in a texture from disc and uploading it to a hardware buffer), it would need to be replaced with the newly generated object in the collection/containers, just like Null pointer would get replaced by a final object. It would also help if the objects - such as textures, pieces of geometry, etc - are immutable or at least pretend to be. It wouldn't also necessarily be a storage efficiency detriment, since you can have the type be a smartpointer which would dereference into an existing Null Object when the underlying storage is actually a Null pointer.
But i suggest that it might not be a good idea. Typical implementations use numeric 0 for the value of Null pointer, and simultaneously invalidate the first page of address space, to make dereference operation fail pretty reliably, and you get a crash report with a backtrace, indicating the location in the program where the error has occurred. In the case Null Object Pattern is used instead, you get logic errors, where the software misbehaves, but you don't have a clear clue on where or why, because it continues to operate. This whole talk is on IF conditions being wrong or having wrong set of consequences attached to them, so essentially logic errors leading to incorrect behaviour and thus long-standing tedious bugs, so it seems counterproductive to suggest an on-paper solution which trades a very specific crash for a logic error and incorrect behaviour.
I just tried a very simple implementation and I have the impression that where ever I turn, the if still has to go somewhere. Removing it from the main flow and sifting it into an object/constructor/factory may "even out" the if density so that ifs are uniformly distributed, but still it can't disappear completely.
So maybe I got something wrong or he actually wants to reduce the density in small code portions. Or maybe that's just an intermediate step. So "moving" ifs to avoid complex code is ok, but thinking that they will go away completely looks utopic to me.
@Gwen Lofman After I learned Haskell, I hate null. Why should it be the case that any reference type in languages like C# and Java can be null? Now I have to always handle the case that everything is null, or otherwise risk runtime errors. This aspect of the type system is completely asinine and anxiety-inducing.
C++ is a lot more inherently dangerous, with its pointer arithmetic and manual memory management, so I can't complain about null so much over there. But I'm certainly glad Rust does away with null in safe code, for the same reasons.
@@joshuakb2 Yeah, it’s super weird that these are considered type-safe compiled languages, yet everything is potentially the “null” type, which is utterly useless except as a way of letting lazy programmers avoid fully constructing their data. The impact of that is phenomenally bad... I love the idea of encoding “optionality” into the type itself, so we can know which specific pieces of data might be missing without worrying about that anywhere else.
@@joshuakb2 "C++ is a lot more inherently dangerous, with its pointer arithmetic and manual memory management"
When was the last time you actually wrote C++?
Interesting analysis!
In the end though, if I remember correctly, it is known that if and switch statements can be a replaced by polymorphism and factories. Isn't that part of solid?
Anyways, good analysis!
A Null pointer makes sense when you want to prevent it of being uninitialized when there is no object to point to.
Btw can someone bring more water for this guy please?
Edit: My comment is misleading. I mean not "uninitialized" but initialized with a random address, that can be very harmful.
You can point to a null or dummy object in those cases.
A dummy object wouldn't be a good idea, because I would like to have the option to determine if the pointer is already initialized or not.
I wouldn't consider a null object a good idea either, because if I forget to initialize the pointer, the program seems to do just fine until the moment I get weird results. Then I would pray for an exception instead of being forced to debug the whole stuff.
@@eyebee-sea4444 Why do want to be able to test if the variable is not initialized? What couldn't you do if you test if the pointer point to the initial dummy object? You could call the object Uninitialized.
Why do I want to be able to determine if a variable is initialized or not? Are you serious?
No matter of what you use as an indicator, null or a dummy object, you have to be sure the variable is in a initialized state when you use it. If it is not and you use null, you get an exception. If you use a dummy instead, you get no exception, but you operate with a de facto uninitialized variable and you don't necessarily realise it. In the worst case the program seems to work just fine, even passes the unit tests, until one day the customer calls you back, because some calculations your program does are erroneous ... sometimes ... in specific cases.
@@eyebee-sea4444 Yes, I am serious. It all depends on why you need it. The default object can throw only exceptions. In this case you can name the exceptions. In other cases a default implementation may be required. It all depend on why you want something. I view null pointer as a bad design. All that tells me is that a pointer can not be dereferenced, but does not tell you what is wrong.
In summary:
"IF" - baaaad
"SWITCH" - Gooood
"GOTO" - neutral - neither inherently good or bad (got a bad rap)
Apple computers (and their users) - VERY baaaad
Switches can be expressed as if, so if ifs are considered harmful then switches are considered harmful.
In the case of a program that has no loops, the static map and the dynamic process are one and the same, correct?
Does anyone know of a reference for the Intercity 125 anecdote?
In what way "assert(condition) or throw Error()" is different from "if (condition) throw Error()"?
Assert makes it obvious that you're checking for invalid state not invariants.
"assert or throw" doesn't seem to make sense to me. Don't even know in what language that'd work and what it'd do (hard error in debug, exception in production?). Maybe it's just pseudocode.
That should be “if( not condition)”. One problem with exceptions is that they are used for multiple purposes. Sometimes an exception just indicates and unusual condition that was anticipated by the programmer and requires handling. And sometimes exceptions are used to indicate that there is a defect in the code itself. He’s using asserts for the latter case. Other than that, there’s no difference and he shows that you can get exactly the same effect as “assert x or throw ...” with “if( not x) throw ...”.
"I don't think it's goto that's harmful, I think it's 'if goto' that's harmful"
well... except goto without condition can either create a deadzone (code that will never get executed) or an infinite loop... There's no other option. Which means goto without if is useless... Or, to be precise, goto without if is either useless ( when it jumps forward - because you're better off actually deleting the code it skips, since it's dead code), or a bug by default (when it jumps backwards, because you've just created an infinite loop).
@@WolfJ you missed my point which was that goto without any condition is useless, therefore making the distinction between goto and if..goto makes no sense.
Doesn't this mean that the null conditional access operator is the root of all evil? Actually it's null itself. This is why I like functional programming languages like F#, OCaml, Rust, ReScript, etc.
I would love to hear a similar talk on Common Lisp's restart/error system and how it would be useful for avoiding the problematic branching logic. From what I've seen it looks like Common Lisp's system adds flexibility to allow more than just restarting or signaling errors, as you can automate reparation and re-enter code with much flexibility.
Seems pretty woo-woo. A case for "parse, don't validatate"? Obviously ifs are not evil.
Man I really love Jules’ presentation here, but I wish it could’ve been presented more simply.
Some things are inherently complex so maybe it’s not possible. But maybe it is. I think it’s harder to say whether it’s impossible unless you try.
43:51, 45:07 - oh come on, enough with the vocal noises already, it sounds horrible through headphones! (drinking, gulping, mouth clicking...)
Why not create a single source file `if-conditions.hpp`, and put _every_ if condition in that? Then we've clearly separated all the conditions from the rest of the code. (The consequences.)
That wouldn't solve anything. You've only moved all the conditions to a single file, and you're now using the preprocessor to put them back. The problem is that the very presence of the conditions makes the code hard to reason about. The proposal here is to lean on the type system so that the computer makes a decision *once* and that point is at object creation time. There are languages that achieve what he's aiming for, but they're not yet widely used, by using something called *dependent types*, something that might hopefully get into the mainstream soon.
@@talideon you may have missed the factitious quality of my remark.
How can someone drink so much water? It'll get him killed.
1968 - GOTO considered harmful... 2015 - IF considered harmful... 2068 - FOR considered harmful?
You're on it! We'll be working on quantum computers by then. Why operate on a series of data in sequence when you can do it all at once!
Programming considered harmful is a talk waiting for happen once we have AI coders
I've wondered for a while whether the mathematics origin of so much computing lends itself to thinking of programming Platonistically (timeless, capable of perfection, etc.). Turing himself was not subject to this, but he was a very unusual guy. (I suspect that he did math because he was good at it, not because it was really he was on about most of the time.)
assert ... seems to be just "if" in none simple human language. Though I understand the point trying to be made.
Interesting talk :D
Goto’s don’t cause bugs. I use goto’s in C to get 1 exit from functions (or sometimes just a couple of exits at the bottom of the function) and a couple of other very narrow techniques (like retry). I have never discovered a single bug because of any goto in many hundreds of thousands of green field C code. Not a single one.
The vast majority of errors I get that aren’t trivial syntax errors that are fixed in seconds, are memory bound errors. You have a buffer and your pointer goes past the end of the space you have allocated (or you access elements of an array past it’s limit). I also find that allowing NULL pointers as a signal for something not working is a disaster waiting to happen. Dereferencing a NULL pointer will at the least cause an unrecoverable error or a program crash. Don’t use stupid NULL pointers.
Dereferencing a NULL causes undefined behaviour, not a program crash. Those are just bugs in waiting.
Daniel Stanciu I stand corrected but my dislike of NULL would still seem to hold. Program crash or undefined behavior are both bad.
@@clarkd1955 Sorry, I must have misunderstood your comment as supporting the use of NULL Values. In conclusion, leaving NULL values around your software is not a good practice, and any language should make it as hard as possible to use such a value.
Errors that are fixed on first pass don't really count. The talk is fundamentally about logic errors, bugs remaining in at least medium-sized software of at least several hundred thousand lines, which generally have a particular density of known misbehaviours or bugs, issues that are invisible at first sight and evade code review and any automated means again and again, so they just sit there littering any sufficiently complex software. As large software develops and ages, the conditions and consequences which once obviously belonged together become separated by a good bit of code distance, and can even become aliased under different names, making them difficult to keep track of. For example if one spot says if(A) and another says if(B), but it turns out that B can only be true if A is true, or has some other kind causal relationship to condition A, then when you modify the action that happens when if(A), you may fail to update the other dependent actions under aliases and which live further away. Thus long-standing, difficult-to-find logic errors.
Dereferencing a NULL pointer is UD as per spec but implementations are free to constrain it and substitute well-defined behaviour instead, and commonly (e.g. on all multitasking desktop operating systems with all toolchains i can think of), this is exactly the case, you see numeric 0 used for NULL pointer, with zero-page being made inaccessible, which crashes the software reliably, and you can get a backtrace which pinpoints EXACTLY where the issue is. Naturally the solution is not to blindly stick an "if(!ptr) return" in there but think about WHY it happened and what to do about it. If you think it's a "disaster waiting to happen", well to me it's the opposite, it's an opportunity for an easy discovery of the origin of a bug - but i wouldn't exactly program software for a nuclear power plant this way. In fact the latter better have exactly zero allocations AT ALL.
As opposed to desktop operating systems, MMUless embedded systems don't generally have a NULL pointer dereference guard of any kind (thus the UD spec makes sense), obviously you adjust your approach to the target you're dealing with and take consequences of the kind of bug that can happen in account. For some cases, Defensive Programming, where you try for foresee ways for the software to continue execution in all eventualities and in case of bugs, is actually a good idea. But when developing multi million line desktop software that is not anyhow life critical, you have a barrage of bug reports raining down on you and much too little time and you need to find ways to increase the speed at which you fix them and improve correctness of the software, even if you have to temporarily inconvenience the users by a crash to get there, thus Offensive Programming. Defensive and Offensive Programming are two opposite approaches to software quality that both make sense situationally. Life is too short and software isn't developed under ideal conditions where you have endless time to chase down mystery bugs.
Buffer overruns can be a bit insidious, as there is generally a chunk of valid memory right behind the allocated region and only in rare cases will this particular kind of invalid dereference cause a crash, but they are subject to be found with automated means such as asan or valgrind. Some of the least comfy crash bugs i have seen have been multithreading synchronisation bugs, and also iterator invalidation, where backtraces as they come back simply don't make sense, and almost all the time software works, except there's a mystery crash sometimes. Also not my favourite: resource hoarding bugs, where the program has the behaviour of a slow memory leak and just gradually slows down during the session of use, as the size of data structures keeps ballooning and increases search space, but tool assisted tests come back inconclusive, because there is no technical leak as the objects or resources appear to still be tied into something, even though they have become practically useless and should have been cleaned up.
I am critical of his claim that NULL pointers should never be used and Null Object Pattern is to be used instead, because it makes the software not crash, but it does NOTHING for program correctness. I.e. if someone didn't think to check the NULL pointer, similarly, they will fail to handle the Null Object correctly, such as will fail to replace it with actual useful data in time, and the software will just sometimes not behave correctly and where the issue comes from will remain a mystery, which is the whole thing he seeks to avoid with if-considered-harmful. Null Object Pattern is particularly incompatible with Offensive Programming approach.
I'm not a big fan of break, or return for that matter. To me that block between the curly brackets should either execute or not execute and you should only crash out part way through for an exception, and exceptions shouldn't be part of "normal" flow.
But on return you'll end up setting a flag like "found" rather than just returning the result which can obfuscate normal flow to satisfy the single return normal flow constraint. Yes, often you can structure code with while and a function but that might make say scanning arrays harder to reason about.
It's a matter of good taste rather than absolutism.
Having had to write at one time a significant amount of code in Pascal without return or break or exceptions, the purity was in practice detrimental; tasteful C was both clearer and more concise because it avoided control flow flags and allowed pre-intialised static data.
For clarity and concise code, very often I'd simply assign defaults updated conditionally which the compiler often optimised to branchless code avoiding the synchronisation and code duplication that seems to me to be the root cause of the bugs in that originally Delphi (Pascal) codebase.
But for that you need to decompose the problem well, I think that then avoids the anti-pattern, but he showed toy not real examples and in C it was simple to develop with conditionally compiled module tests which made updating far more reliable.
drinking game: drink a shot every time the guy asks the audience "does this/that make sense?"
1. Go Tos Considered Harmful
2. Ifs Considered Harmful
3. Variables Considered Harmful
Ok, I got it. Turing Completeness Considered Harmful.
"New computer, it's an apple, it should work"
...how easily such smart people are able and willing to fall into such black holes of overpriced stupidity... =D
It appears the presenter - speaking on good software development practices - has failed to apply good software development practices and did not test. Accidents happen, and sometimes you have to beam off someone else's machine with different software because the correct adapter has somehow evaporated, but i don't know, hardly makes a case for taking him seriously, with a justification like that.
Too much talk - not enough adequate information.
It's mostly waste of time.
While I agree that at times he's going around and around but that's him stressing the point. What I find funny is the fact that the actual problem is not with the ifs but what he called 'synchronized state' while answering one of the questions. An object in different states should behave differently and the problem is who, where and how should enforce/ensure that. That's where the bugs are coming from: object behaves/operates/is operated on differently than it should be in its current state. Well, everything boils down to state and state management, again.
Nikolai Aleksandrenko but the info is very very interesting though
Bah humbug. 🤗 if you honestly feel comfortable saying that, then I would bet you didn’t actually understand the information well enough to judge its adequacy. The ideas are important. Big ideas take more words to illustrate. You seem to be too impatient for this sort of thinking, which is not Jules’ failing. Perhaps you are young, you may grow to love this sort of presentation as you mature a bit more. I do not know you, I am making several suppositions, but that is my sincere guess about the reason behind your comment.
Good software design is all about thinking; Not consuming adequately dense information without regard to quality, but qualitative and careful reasoning.
How do his answers jive with SOLID principles?
SOLID is not a set of unbendable laws. I see no stone tablets.
In a sense null pointers always violate the LSP. The LSP says that if we have “T x;”, then the behaviour of “x.foo()” should be allowed by the specification of foo in T. When x is null, this is very unlikely to be the case.
Seems a little different than Allan Holub's solution.
Can you provide a reference to what you call "Allan Holub's solution" please?
I've watched so many videos since then, so I'm not sure which one of Allen's presentations it was that triggered the question.
More about the billion dollar mistake codeburst.io/null-the-billion-dollar-mistake-c2918c92f7e0
Interesting - the claimed percentage rose by 5% just by making it to the title. (Instant disklike)
When do a presentation never ever drink during your presentation! Its annoying ! STOP swallowing in the mic.
What he shows at 50:51 resembles the Strategy Pattern. en.wikipedia.org/wiki/Strategy_pattern