fantastic talk.. finally all comes together: clean architecture, pure functions, immutable data structures. Now I am beginning to understand because Brandon shows everything in context of real code. Enlightenment :-)
This is the Grand Unified Theory of Software Design. I never expected that Uncle Bob's framework, which I recently discovered, tends towards the Functional Programming paradigm that I love (which encourages reducing the side-effects to an imperative shell, and having most of the code in a functional core). And this is illustrated in a tiny one-screen sized code! What a fantastic presentation!
The BEST video regarding Clean Architecture. Examples seem easy but it's heavily packed information! Lot of issues adressed here. Thank you Brandon Rhodes!
Thank you for this amazing talk. I have watched this video time and again from the beginning of my programming journey and every time I take away something new!
What he failed to explain is that immutability allows you not have to lock your datascructures. Reember the GIL? Well with immutable objects it wouldn't be necessary and we'd achieve full parallelization when runing pure python code (we'd just have to change the garbage collector not to rely on refcount) But to me the main advantage of immutable datastructures is readbility: you're certain that when you call any thing it won't modify what you give it. Like he said, the sate in FP is entirely defined by the inputs whereas in Python the state is split and burried in many places potentially. In python that's not the case (as in C and Java and all mutable languages): when you give anything to a function, there's no guarantee that the object will be the same after the call. And those bugs are the most difficult to spot and debug.
Technically having the immutability built into the language is better, but his argument is that most of the benefits of this approach can be had by just using a functional design pattern. This is very much like following an object-oriented design pattern in plain C. A lot of this "immutability" is just an abstraction/illusion, anyway. Just put your state as a parameter (data) and voila, even a state machine can be implemented with pure functions. I'm actually interested in this clean architecture pattern for embedded C. Testing with mocks is a hard sell to people who are accustomed to doing all testing at the integration or system level. Organizing code this way just makes sense.
I don't get it : On 8.34 he is asking how to call find_definition() without doing IO, however I don't see how you 're calling find_definition() on Listing 3 without doing IO either. I can understand that the code on Listing 3 is far more readable, but not the decoupling issue.
In listings 1 and 2, the logic depends on the IO. In 3, IO depends on the logic. Coupling doesn't go away, but it's restructured. I think he mentions something about intentionally isolating coupling to just one function for listing 3.
What you actually want to test is that (1) URL is properly formed and (2) The logic part properly extracts the info from the returned data. The I/O is incidental. With Listings 1 & 2, you can't do that easily; you have to mock. With Listing 3, you can do (1) and (2) easily and separately. In short: Test the _wanted behavior_ rather than testing "a function with a certain name".
Or pay attention to the point of the talk and architect your system such that you don't need do the painful bending backwards of dependency injection at all.
th-cam.com/video/DJtef410XaM/w-d-xo.html How could you even compare 10 pages of Pascal to 6 lines of Shell code ?!?!? It's like comparing fancy car to a junk car logic, they both drive lol Run the fair test for 20 million of pages and time it.
I am sorry, but you are completely missing the point. Mocking Knuth for providing computationally more efficient solution without knowing whether performance was of any relevance for the task is just plain brain dead, sorry.
Oh, come on. He wasn't mocking Knuth, he was using him as a crutch to show that expressivity does matter. Knuth is an algorithms guy and thinking about the performance of it all is the mindset that justifies his approach to solving the problem, sure. I also find it a bit ironic that this particular toy problem is almost highly parallelize-able and as such can easily be modified to beat Knuth's solution in terms of performance. Knuth didn't believe in concurrency and for a good reason.
16:30 - this argumentation is highly misleading. It creates the impression you end up with a long list of arguments in your high level code, which is simply not the case. Since composition is a thing, your have a dependency graph, and on each level of abstraction you just see that part of the graph. The one place where you see the graph is where you construct it, though for this you do not need some huge framework, some simple factory typically suffices, even for bigger apps. Edit: wow, then you go ahead to suggest patching global definitions is a better approach? I found the talk quite interesting so far, though this really is losing me. What does this argumentation even have to do with the Clean Architecture? It, or Hexagonal for that matter, say nothing about it. Uncle bob also happens to advocate dependency injection. Devs working with dynamic languages should really get over themselves. Design still applies to you. Dependency injection has nothing to do with static vs dynamic or even if your language has the concrete notion of a class. An no, I am not a Java dev. My main language is dynamic. #GrumpGrumpGrump
With composition it is still non-trivial to isolate the node in the graph that you are trying to test, so I think there is still some merit to wanting to deal with pure functions / simple data transformations
This is a simplified introduction to the idea of decoupling your logic from your IO. Once you understand the benefits this has, you're more equipped to understand the clean/hexagonal/onion architecture
And what about the efficiency? Whose code faired better? Python is very slow and inefficient in terms of memory when compared to C++...It is hardly used in any coding competitions where memory and time are constraints.
Clever algorithm ( or data structure ) almost always beats a fast compiler or whatever tool you are using . Also try to switch to the appropriate Python implementation that suits you the most . Fortunately you have a big choice of what to pick .
@@GlukAlex Notionally your argument sounds logical and sound but in practice I personally have never seen it pan out. A dumb C++ or Go will nearly always beat any clever algorithm in Python or any other dynamic language.
Work on real world problem and you will learn that at the end, that rarely matters: machine time is cheap, but programmer's time is massively more expensive.
Interesting talk, even though there is some bullshit framing and argumentation at some points. No idea why this is called The Clean Architecture in Python, since it is not about The Clean Architecture at all.
You are quite the troll. How do the examples not reflect The Clean Architecture? Look at Uncle Bob's diagram at 1:30 - the outside routines that do I/O (web, UI, DB) are called "Plug-ins" by Uncle Bob. They call the inner Controllers and Presenters, which then call Use Case Objects / Interactors, which then call Entities, which are at the center. Since the calls may only go one way across architecture boundaries (towards the Entities in the center), the I/O plug-ins are decoupled from the core, and may change easily. Also, the core does not have to change if its callers change. The same way, Brandon shows us a shell of a program that deals with the exterior by causing side effects, but the core is pure-functional and decoupled. What's not to like?
Brandon Rhodes has the best talks.
Needs his own TH-cam series!!
fantastic talk.. finally all comes together: clean architecture, pure functions, immutable data structures. Now I am beginning to understand because Brandon shows everything in context of real code. Enlightenment :-)
Dude, I;m so happy to watch that video.
rhodesmill.org/brandon/slides/2014-07-pyohio/clean-architecture/ This is the presentation of the lecture from Brandon. Thank you, Brandon Rhodes.
This is the Grand Unified Theory of Software Design. I never expected that Uncle Bob's framework, which I recently discovered, tends towards the Functional Programming paradigm that I love (which encourages reducing the side-effects to an imperative shell, and having most of the code in a functional core).
And this is illustrated in a tiny one-screen sized code! What a fantastic presentation!
The BEST video regarding Clean Architecture. Examples seem easy but it's heavily packed information! Lot of issues adressed here. Thank you Brandon Rhodes!
I specially liked the idea of using generators to split procedural side-effects from iteration.
#CleanArchitecture #python #FunctionalProgramming
People need to start to explain things like that. Great lecture !
this guy is a genius - every talk is just wow
Thank you for this amazing talk. I have watched this video time and again from the beginning of my programming journey and every time I take away something new!
Thanks Brandon! This talk was absolute genius. I have to watch all your talks.
Absolutely great talk. Provides clarity.
Thank you sooo much, Mister Rhodes!
Wow! Amazing summary of some very big concepts.
I Love Brandon Rhodes!
He is such a good teacher.
Absolutely marvelous! Thanks for posting!
this is so helpful and relevant
Love python. Now teach me how!
Very nice talk on #python and #CleanArchitecture
What he failed to explain is that immutability allows you not have to lock your datascructures.
Reember the GIL? Well with immutable objects it wouldn't be necessary and we'd achieve full parallelization when runing pure python code (we'd just have to change the garbage collector not to rely on refcount)
But to me the main advantage of immutable datastructures is readbility: you're certain that when you call any thing it won't modify what you give it. Like he said, the sate in FP is entirely defined by the inputs whereas in Python the state is split and burried in many places potentially.
In python that's not the case (as in C and Java and all mutable languages): when you give anything to a function, there's no guarantee that the object will be the same after the call. And those bugs are the most difficult to spot and debug.
Technically having the immutability built into the language is better, but his argument is that most of the benefits of this approach can be had by just using a functional design pattern. This is very much like following an object-oriented design pattern in plain C. A lot of this "immutability" is just an abstraction/illusion, anyway. Just put your state as a parameter (data) and voila, even a state machine can be implemented with pure functions.
I'm actually interested in this clean architecture pattern for embedded C. Testing with mocks is a hard sell to people who are accustomed to doing all testing at the integration or system level. Organizing code this way just makes sense.
brilliant talk
Really excellent talk.
The key is to get to "immutability" by being performant. Python's list comprehensions is not a tool for that. Views and iterators are.
Slides: rhodesmill.org/brandon/slides/2014-07-pyohio/clean-architecture/
build_url also introduces a bug, by not returning the new value.
Awesome talk!
18:47 How am I supposed to test the find_definition() function here?
+T Chen answer starts from 26:00
+Kinjal Dixit So, the answer is to use integrated tests? I don't think It is elaborated. Could you show me some code examples if possible?
Tests at the beginning of the talk are not so good either :/
I don't get it : On 8.34 he is asking how to call find_definition() without doing IO, however I don't see how you 're calling find_definition() on Listing 3 without doing IO either. I can understand that the code on Listing 3 is far more readable, but not the decoupling issue.
In listings 1 and 2, the logic depends on the IO. In 3, IO depends on the logic. Coupling doesn't go away, but it's restructured. I think he mentions something about intentionally isolating coupling to just one function for listing 3.
Put the io on the top. Make it a “manager”.
What you actually want to test is that (1) URL is properly formed and (2) The logic part properly extracts the info from the returned data. The I/O is incidental.
With Listings 1 & 2, you can't do that easily; you have to mock. With Listing 3, you can do (1) and (2) easily and separately.
In short: Test the _wanted behavior_ rather than testing "a function with a certain name".
7:49 "hiding is not enough". We must decouple.
is there any implementation clean architecture in python?
Great talk LOL. And did he just explain the MVC pattern here but in another manner ?
赞
at 40min. congrats, you just invented flow-based programming.
14:37 - this defaulting is bad practice, esp since the default is still something you pull from global scope. Just require the dependency
Or pay attention to the point of the talk and architect your system such that you don't need do the painful bending backwards of dependency injection at all.
Крутой чел.
so good in content, so bad in sound/video quality :/
th-cam.com/video/DJtef410XaM/w-d-xo.html How could you even compare 10 pages of Pascal to 6 lines of Shell code ?!?!? It's like comparing fancy car to a junk car logic, they both drive lol Run the fair test for 20 million of pages and time it.
I am sorry, but you are completely missing the point. Mocking Knuth for providing computationally more efficient solution without knowing whether performance was of any relevance for the task is just plain brain dead, sorry.
Oh, come on. He wasn't mocking Knuth, he was using him as a crutch to show that expressivity does matter. Knuth is an algorithms guy and thinking about the performance of it all is the mindset that justifies his approach to solving the problem, sure. I also find it a bit ironic that this particular toy problem is almost highly parallelize-able and as such can easily be modified to beat Knuth's solution in terms of performance. Knuth didn't believe in concurrency and for a good reason.
16:30 - this argumentation is highly misleading. It creates the impression you end up with a long list of arguments in your high level code, which is simply not the case. Since composition is a thing, your have a dependency graph, and on each level of abstraction you just see that part of the graph. The one place where you see the graph is where you construct it, though for this you do not need some huge framework, some simple factory typically suffices, even for bigger apps.
Edit: wow, then you go ahead to suggest patching global definitions is a better approach? I found the talk quite interesting so far, though this really is losing me. What does this argumentation even have to do with the Clean Architecture? It, or Hexagonal for that matter, say nothing about it. Uncle bob also happens to advocate dependency injection.
Devs working with dynamic languages should really get over themselves. Design still applies to you. Dependency injection has nothing to do with static vs dynamic or even if your language has the concrete notion of a class. An no, I am not a Java dev. My main language is dynamic. #GrumpGrumpGrump
With composition it is still non-trivial to isolate the node in the graph that you are trying to test, so I think there is still some merit to wanting to deal with pure functions / simple data transformations
This is a simplified introduction to the idea of decoupling your logic from your IO. Once you understand the benefits this has, you're more equipped to understand the clean/hexagonal/onion architecture
The "good" examples have code smell all over :/
Like what?
And what about the efficiency? Whose code faired better? Python is very slow and inefficient in terms of memory when compared to C++...It is hardly used in any coding competitions where memory and time are constraints.
Abhilasha Jha Most operations are at C speed. You just need to use python correctly
Clever algorithm ( or data structure ) almost always beats a fast compiler or whatever tool you are using .
Also try to switch to the appropriate Python implementation that suits you the most .
Fortunately you have a big choice of what to pick .
@@GlukAlex Notionally your argument sounds logical and sound but in practice I personally have never seen it pan out. A dumb C++ or Go will nearly always beat any clever algorithm in Python or any other dynamic language.
Efficiency is not significant most of the time. If it does matter then measuring is the only way to justify an alternative approach.
Work on real world problem and you will learn that at the end, that rarely matters: machine time is cheap, but programmer's time is massively more expensive.
Interesting talk, even though there is some bullshit framing and argumentation at some points. No idea why this is called The Clean Architecture in Python, since it is not about The Clean Architecture at all.
You are quite the troll. How do the examples not reflect The Clean Architecture?
Look at Uncle Bob's diagram at 1:30 - the outside routines that do I/O (web, UI, DB) are called "Plug-ins" by Uncle Bob. They call the inner Controllers and Presenters, which then call Use Case Objects / Interactors, which then call Entities, which are at the center.
Since the calls may only go one way across architecture boundaries (towards the Entities in the center), the I/O plug-ins are decoupled from the core, and may change easily. Also, the core does not have to change if its callers change.
The same way, Brandon shows us a shell of a program that deals with the exterior by causing side effects, but the core is pure-functional and decoupled. What's not to like?
Hell, Uncle Bob even started coding in Clojure, a functional language: blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html
Excellent talk!
Very nice talk on #python and #CleanArchitecture