Terrible example of nested loops turned into undebuggable one-liner.
Simply reducing the number of variables used and line number to run code doesn't make that code more scalable and comprehensive to the next developer that will need to modify your code.
Terrible display on how much refactoring to replace simple if or loop can go wrong. Gone from easy to read if and loops to a terrible mess of obfuscated unreadable code. As code reviewer i would refuse any code submited to me that way. Closure and chaining makes debuging and reading a nightmare in no time. No way a junior could touch that code without asking what it does.
Great speaker with a very good articulation. My issue is more with the content. Echoing the previous comments, and to paraphrase Jurassic Park, they spent so much time showing they could refractor code, they never stopped to ask if they should. If you have a team with Jr. Programmers, and implement these changes to your codebase, be prepared to also provide A LOT of training.
Great presentation, with very useful information. Even if it doesn't fit somebody's coding preferences, the ideas are interesting and thought provoking.
I've always found some people's "semi-dogmatic" obsessions with things like avoiding if statements, immutability, strict FP, etc.. "just because" to be a little off-putting, so seeing "never write another loop again" in a talk description would have normally resulted in an eyeroll and me moving on to a different talk... however, I attended an excellent talk by this speaker at a different conference and decided to give him the benefit of the doubt and take a look anyway. I'M GLAD I DID! (and you should too, if you happen to be reading past talk ratings to help you decide if you should see this talk at whatever other conference it's being given).
The majority of this talk is a flawless live demonstration of refactoring a deeply-nested, difficult to test, horribly unreadable disaster of a function. The speaker takes you step by step throughout his thought process as he refactors it, and continues to show along the way that the end result remains the same after every incremental change. He could keep the talk exactly the same next time and the time after that and it'd still be a 5 star talk; HOWEVER, I think there are a few improvements that could be made to address some of the criticisms raised by other reviewers.
1. Terminology: Some people may not be familiar with terms like "map", "reduce", "pluck", "flatten", and so on, and might see those terms used and consider the code unreadable because they don't know what it's supposed to do. I've seen those terms before in different contexts so it wasn't hard for me to follow, but someone hearing them for the first time might have trouble understanding the examples, even if you define the terms for them before proceeding. Maybe a little "reference block" of comments off to the side, or perhaps make the editor window a little smaller in order to fit a cheatsheet on the screen at the same time? That way someone can always look back and say "ah ok, that's what pluck does. OK, now what's he doing..."
2. Performance: Refactoring to collections is absolutely going to impact performance - there is no avoiding that. Readability and maintainability trump performance micro-optimizations IMO, though, so I suggest nipping the "this is going to make my site slow" criticism in the bud. Maybe bootstrap a simple Laravel / Expressive / Symfony quickstart application, create an endpoint for the original version of the function and another for the fully refactored version, and do a benchmark to demonstrate "yes, collection pipelines are slower. this example adds 1/10 of a millisecond to your 100-200ms pageload time. can you read and understand the original version in less than 1/10 of a millisecond? no? then stop worrying." You can even use a prepared slide with the benchmark results already on it, since that wouldn't be terribly entertaining to watch live (and it's not really relevant to the talk other than "see? i told you so").
3. Debugging: People said the refactored version is harder to debug than the original monstrosity. Prove them wrong - add some strategically placed bugs and compare how you'd debug them in the collection pipeline approach versus with the original approach.
I won't be seeking out and destroying all loops and conditionals in my application (or refusing to add new ones) after this talk or anything, BUT I now have a new tool in my tool chest, and I'll be sure to wield it whenever I think it makes sense to do so.
I highly enjoyed this talk. I've been a big fan of collections for about a year or so and Adam does a good job exploring some common patterns seen in code and ways to solve it with a collection and cleanness of the approach.
On a personal note, I took a minute or two to speak with Adam about an issue and he both took the time to consider the problem and come up with a solution after our conversation. What more could you ask for from a speaker?
The one thing I'll note as a negative is there could have been more examination of the why to use Collections and various tooling around it. Simply eliminating loops, ifs and temp variables is not necessarily a succinct reason for everyone. It's also hard to express the idea that concepts we've used for our entire career may not be the correct solution. Perhaps pointing out how the cyclomatic complexity is lower, or similar might be helpful?
Really enjoyed this talk by Adam. Well put together and very informative. So many times I've wondered how I could take some of the complicated nested loops (of which I've created and/or worked on some bad ones), and Adam lit the path to a great new way to make them work. Will certainly be trying these techniques with some of my own code.
Comments
Comments are closed.
Adam is a great speaker. The examples were well planed and easy to follow. Looking forward to refactoring a lot of code and using these concepts
Terrible example of nested loops turned into undebuggable one-liner.
Simply reducing the number of variables used and line number to run code doesn't make that code more scalable and comprehensive to the next developer that will need to modify your code.
Terrible display on how much refactoring to replace simple if or loop can go wrong. Gone from easy to read if and loops to a terrible mess of obfuscated unreadable code. As code reviewer i would refuse any code submited to me that way. Closure and chaining makes debuging and reading a nightmare in no time. No way a junior could touch that code without asking what it does.
Great speaker with a very good articulation. My issue is more with the content. Echoing the previous comments, and to paraphrase Jurassic Park, they spent so much time showing they could refractor code, they never stopped to ask if they should. If you have a team with Jr. Programmers, and implement these changes to your codebase, be prepared to also provide A LOT of training.
Loved the session and it opened up my eyes to something I've been struggling with in the past.
I discovered I don't use closures often enough in my code. Great Talk!
Great presentation, with very useful information. Even if it doesn't fit somebody's coding preferences, the ideas are interesting and thought provoking.
I've always found some people's "semi-dogmatic" obsessions with things like avoiding if statements, immutability, strict FP, etc.. "just because" to be a little off-putting, so seeing "never write another loop again" in a talk description would have normally resulted in an eyeroll and me moving on to a different talk... however, I attended an excellent talk by this speaker at a different conference and decided to give him the benefit of the doubt and take a look anyway. I'M GLAD I DID! (and you should too, if you happen to be reading past talk ratings to help you decide if you should see this talk at whatever other conference it's being given).
The majority of this talk is a flawless live demonstration of refactoring a deeply-nested, difficult to test, horribly unreadable disaster of a function. The speaker takes you step by step throughout his thought process as he refactors it, and continues to show along the way that the end result remains the same after every incremental change. He could keep the talk exactly the same next time and the time after that and it'd still be a 5 star talk; HOWEVER, I think there are a few improvements that could be made to address some of the criticisms raised by other reviewers.
1. Terminology: Some people may not be familiar with terms like "map", "reduce", "pluck", "flatten", and so on, and might see those terms used and consider the code unreadable because they don't know what it's supposed to do. I've seen those terms before in different contexts so it wasn't hard for me to follow, but someone hearing them for the first time might have trouble understanding the examples, even if you define the terms for them before proceeding. Maybe a little "reference block" of comments off to the side, or perhaps make the editor window a little smaller in order to fit a cheatsheet on the screen at the same time? That way someone can always look back and say "ah ok, that's what pluck does. OK, now what's he doing..."
2. Performance: Refactoring to collections is absolutely going to impact performance - there is no avoiding that. Readability and maintainability trump performance micro-optimizations IMO, though, so I suggest nipping the "this is going to make my site slow" criticism in the bud. Maybe bootstrap a simple Laravel / Expressive / Symfony quickstart application, create an endpoint for the original version of the function and another for the fully refactored version, and do a benchmark to demonstrate "yes, collection pipelines are slower. this example adds 1/10 of a millisecond to your 100-200ms pageload time. can you read and understand the original version in less than 1/10 of a millisecond? no? then stop worrying." You can even use a prepared slide with the benchmark results already on it, since that wouldn't be terribly entertaining to watch live (and it's not really relevant to the talk other than "see? i told you so").
3. Debugging: People said the refactored version is harder to debug than the original monstrosity. Prove them wrong - add some strategically placed bugs and compare how you'd debug them in the collection pipeline approach versus with the original approach.
I won't be seeking out and destroying all loops and conditionals in my application (or refusing to add new ones) after this talk or anything, BUT I now have a new tool in my tool chest, and I'll be sure to wield it whenever I think it makes sense to do so.
(oops, i typed too much...)
I highly enjoyed this talk. I've been a big fan of collections for about a year or so and Adam does a good job exploring some common patterns seen in code and ways to solve it with a collection and cleanness of the approach.
On a personal note, I took a minute or two to speak with Adam about an issue and he both took the time to consider the problem and come up with a solution after our conversation. What more could you ask for from a speaker?
The one thing I'll note as a negative is there could have been more examination of the why to use Collections and various tooling around it. Simply eliminating loops, ifs and temp variables is not necessarily a succinct reason for everyone. It's also hard to express the idea that concepts we've used for our entire career may not be the correct solution. Perhaps pointing out how the cyclomatic complexity is lower, or similar might be helpful?
It was an interesting talk for something I haven’t been exposed to. I’d be curious if is a performance impact.
Really enjoyed this talk by Adam. Well put together and very informative. So many times I've wondered how I could take some of the complicated nested loops (of which I've created and/or worked on some bad ones), and Adam lit the path to a great new way to make them work. Will certainly be trying these techniques with some of my own code.