07:03 is one of my favorite quotes ever: If you want everything to be familiar, you will never learn anything new, because it can't be significantly different from what you already know.
38:58 the ability to extract a value is your path to simplicity. if i can get a value out of this i can continue with my program. if i pass a reference to something i'm poisoning the rest of the system.
I've nodded all the way, but what the heck should I do now? For my tiny brain it was too "abstract", I need examples. Wonderful to say who, when, where... show me how, I mean please show me...
I disagree. We test exact behavior, so more like the rails for a train or a tram, making sure a train going in a certain direction end up at an exact location. Guard rails are by nature "hopefully" stopping a catastrophe. That's a better analogy for using strict types. I.e. you know what kind of data you have, but you might be using it wrong. The typing doesn't stop you from doing that. But tests do. I don't love writing tests either, but I've learned to do it pretty well (not testing implementation and focusing on happy path only at the start). As with any tool, it's about learning how to use it correctly to benefit from it 🙃
30:02 I don't understand his point about vars vs. managed references and switches being complex vs. "polymorphism a la carte". My assumption is that he's talking about vars as inferred types and managed refs are pointers to a data structure in a garbage collected language. If so, I'd say that neither of them are simple but vars are vastly simpler because the compiler knows both the type and the data structure so it's only behind one layer of abstraction where as managed data structures have a complex and opaque lifecycle. If he instead means strongly typed references, then I'd agree. As for the polymorphism, I don't understand how it can be seen as simple. Because with switch statements everything is transparent and polymorphism hides functionality behind at least one layer of abstraction. He reiterates that simple means "unentangled" but I'd argue that polymorphism is usually just hidden entanglement. I don't know all the types of polymorphism though, so maybe I'm just not getting it.
What's being argued as complex in the case of vars vs. managed references is unconstrained mutability. For instance, an object member variable -- once it has been changed, every reference to the class that reads that member will read the new value. The term "managed reference" happens to use the already-overloaded term "reference", but is actually describing a reference mechanism like the one Clojure uses, in which the reference itself is an identity object and the value is acquired specifically by explicitly "dereferencing" it. In this system, the value is never actually mutated -- the reference simply associates to the "next version" of that value, and that association can only be done in a particular context. Rich Hickey gives more detail on this sort of system in a talk called "Persistent Data Structures and Managed References", which I cannot link here because of TH-cam comment reasons. As for polymorphism being simpler than switch/match -- switch/match are complex because you have (1) a value (2) being intrinsically compared to multiple potential other values that (3) determines what behavior to execute (and, in many languages, (4) that must be explicitly broken -- but this isn't currently relevant). To borrow a word from the talk, this directly complects many possible values (and therefore has many possible states) and branches, yet only one of them gets run (assuming #4 isn't a factor). Enter polymorphism, where the polymorph implementation is the only component that needs to be concerned about the value, and is already explicitly and directly associated with the value's type such that everything you might need to know about that type is associated with it. This might sometimes result in more places to check for this kind of operation (so it isn't as "easy" in accordance with the talk), but it ends up simpler because you define one interaction and then implement that interaction only where necessary.
12:00 - I would add an item to your list. Can you ship it bug free IN THE FIRST PLACE? That's far, far more valuable than being able to "fix it." But no one even acts like this possibility even exists in our world today, which AMAZES ME. Let me ask you a question. Imagine a world in which the automobile industry, or the passenger airliner industry, had a reputation for quality akin to the one that the software industry has. That would simply . The big difference is that car makers and airline makers can't push a button and change all of there products in the field the way software companies can. Recalls are EXPENSIVE. This ability to push updates out almost automatically has become a crutch, and the software industry uses it to get away with shoddy quality. This should be the problem you're trying to solve.
Development costs (time, money, consequences). Software development has much faster “create - use - get feedback” cycle than automobile industry, and in many cases it’s cheap (in terms of time, mental effort, money, consequences) to ship faster and get quick feedback to iterate further. In most of the cases these programs are non-critical, and people just restart program/computer or refresh the web page if something fails and move on. For businesses it’s easier to wait for errors to start flowing and fixing them rather than polish the product for a year and then rollout perfect thing - they’d just lose money. With cars the cost of failure is drastically higher (people could be seriously injured or killed), and you cannot manufacture a slightly new iteration of a car five times per hour, which makes the making/testing/thinking phase much longer and thorough, and as consequence you have less bugs/failures. The design itself hasn’t changed drastically for decades. It still does not prevent serious failures from happening though (for example, see Toyota unintended acceleration case 2009-2011). I share your sentiment and also wish that software was less bloated, more reliable, and I wish that completing software was harder than it is.
this amazing man, very smart but is not showing anything concrete, how to make things simple???? all I got out of this talk is just some nice jokes, and high level concepts. How to I apply it????
07:03 is one of my favorite quotes ever: If you want everything to be familiar, you will never learn anything new, because it can't be significantly different from what you already know.
I could literally watch this million times and I will not be bored! One of the most enlightening talks ever by Strangeloop
I've already viewed this 5 times over the last 2 years
thank you for making subtitles!
You're welcome! They were manually reviewed and fixed but if you find any issues, let me know.
An oldie but goodie! I make everyone I work with watch this!
38:58 the ability to extract a value is your path to simplicity. if i can get a value out of this i can continue with my program. if i pass a reference to something i'm poisoning the rest of the system.
20:50 on incidental complexity: "incidental is Latin for 'your fault'"
I've nodded all the way, but what the heck should I do now?
For my tiny brain it was too "abstract", I need examples.
Wonderful to say who, when, where... show me how, I mean please show me...
What a great lecture
I should re-watch it every quarter or so.
15:32 love the guard rail programming reference. Such an amazing insight.
that explains why he gave the keynote at _Rails_ Conf 2012.
I disagree. We test exact behavior, so more like the rails for a train or a tram, making sure a train going in a certain direction end up at an exact location. Guard rails are by nature "hopefully" stopping a catastrophe. That's a better analogy for using strict types. I.e. you know what kind of data you have, but you might be using it wrong. The typing doesn't stop you from doing that. But tests do. I don't love writing tests either, but I've learned to do it pretty well (not testing implementation and focusing on happy path only at the start). As with any tool, it's about learning how to use it correctly to benefit from it 🙃
I am also disagree. Its great and poor analogy--both at the same time--on how the tests are useful now and in the future.
This was a fantastic talk. Well done!
30:02 I don't understand his point about vars vs. managed references and switches being complex vs. "polymorphism a la carte".
My assumption is that he's talking about vars as inferred types and managed refs are pointers to a data structure in a garbage collected language. If so, I'd say that neither of them are simple but vars are vastly simpler because the compiler knows both the type and the data structure so it's only behind one layer of abstraction where as managed data structures have a complex and opaque lifecycle. If he instead means strongly typed references, then I'd agree.
As for the polymorphism, I don't understand how it can be seen as simple. Because with switch statements everything is transparent and polymorphism hides functionality behind at least one layer of abstraction. He reiterates that simple means "unentangled" but I'd argue that polymorphism is usually just hidden entanglement. I don't know all the types of polymorphism though, so maybe I'm just not getting it.
What's being argued as complex in the case of vars vs. managed references is unconstrained mutability. For instance, an object member variable -- once it has been changed, every reference to the class that reads that member will read the new value. The term "managed reference" happens to use the already-overloaded term "reference", but is actually describing a reference mechanism like the one Clojure uses, in which the reference itself is an identity object and the value is acquired specifically by explicitly "dereferencing" it. In this system, the value is never actually mutated -- the reference simply associates to the "next version" of that value, and that association can only be done in a particular context. Rich Hickey gives more detail on this sort of system in a talk called "Persistent Data Structures and Managed References", which I cannot link here because of TH-cam comment reasons.
As for polymorphism being simpler than switch/match -- switch/match are complex because you have (1) a value (2) being intrinsically compared to multiple potential other values that (3) determines what behavior to execute (and, in many languages, (4) that must be explicitly broken -- but this isn't currently relevant). To borrow a word from the talk, this directly complects many possible values (and therefore has many possible states) and branches, yet only one of them gets run (assuming #4 isn't a factor). Enter polymorphism, where the polymorph implementation is the only component that needs to be concerned about the value, and is already explicitly and directly associated with the value's type such that everything you might need to know about that type is associated with it. This might sometimes result in more places to check for this kind of operation (so it isn't as "easy" in accordance with the talk), but it ends up simpler because you define one interaction and then implement that interaction only where necessary.
Thanks for adding my russian subtitles!
12:00 - I would add an item to your list. Can you ship it bug free IN THE FIRST PLACE? That's far, far more valuable than being able to "fix it." But no one even acts like this possibility even exists in our world today, which AMAZES ME. Let me ask you a question. Imagine a world in which the automobile industry, or the passenger airliner industry, had a reputation for quality akin to the one that the software industry has. That would simply . The big difference is that car makers and airline makers can't push a button and change all of there products in the field the way software companies can. Recalls are EXPENSIVE. This ability to push updates out almost automatically has become a crutch, and the software industry uses it to get away with shoddy quality. This should be the problem you're trying to solve.
Development costs (time, money, consequences).
Software development has much faster “create - use - get feedback” cycle than automobile industry, and in many cases it’s cheap (in terms of time, mental effort, money, consequences) to ship faster and get quick feedback to iterate further. In most of the cases these programs are non-critical, and people just restart program/computer or refresh the web page if something fails and move on. For businesses it’s easier to wait for errors to start flowing and fixing them rather than polish the product for a year and then rollout perfect thing - they’d just lose money.
With cars the cost of failure is drastically higher (people could be seriously injured or killed), and you cannot manufacture a slightly new iteration of a car five times per hour, which makes the making/testing/thinking phase much longer and thorough, and as consequence you have less bugs/failures. The design itself hasn’t changed drastically for decades. It still does not prevent serious failures from happening though (for example, see Toyota unintended acceleration case 2009-2011).
I share your sentiment and also wish that software was less bloated, more reliable, and I wish that completing software was harder than it is.
I don’t get how he manages to be so funny at the same time
wow, wow, wow, wow, wow
this amazing man, very smart but is not showing anything concrete, how to make things simple???? all I got out of this talk is just some nice jokes, and high level concepts. How to I apply it????