Rolls eyes... There is no right way for everything. Every different solution to a problem comes with its own pluses and minuses. Weighing those against alternate solutions will point you to the right way to handle the task at hand. OOP is great for some things, functional for some things and procedural for smaller applications perhaps.
Procedural code is not typically reusable though. But if you have a small, one off task, it will be the fastest to get done. Those small one off things have a nasty habit of becoming bigger beasts though. YAGNI still applies I suppose.
The first example, processing a csv file and putting the data into a database, isn't really complicated enough for the structure to really matter. The only critical issue with that example is abstracting out file paths and user credentials. Otherwise the task for this example is a straightforward procedure.
The second example is such a clunky programming exercise I would assume it was originally chosen for its didactic value, since there is nothing practical about a coin flipping program.
In the third example, Will takes actual structured code and turns it into a maintenance nightmare. I have seen this type of thinking in a production system, "Hey, let's just turn these nested conditionals into a switch statement with 25 cases." Depending on the lifespan of the project, it can become a complete quagmire. It also tends to propagate itself into other code, since the choice of conditional logic (instead of a collection of objects) here will mean there is no layer of abstraction for other code to take advantage of, and another process, possibly dealing with the exact same collection of meaningless strings, will have to use switch logic as well. Using procedural code here is a decision to choose the option with loads of technical debt.
In the fourth example, Will shows that his procedural approach is better by producing an object oriented design. I am confused how this supports his original thesis that OO code is bad.
I have to agree with you on the first two examples, they were both so simple that they could only be used as exercises in object-orient programming.
In the third case I can see an argument for keeping an object-oriented approach - the solution that he took and turned into a procedural approach was very minimal and easy to understand even as an object-oriented solution because the main class and all the subclasses used were right there in the encapsulating class, and all the subclasses were simply implementing a single method. Turning it into a procedural method with the switch statement really just reduced the amount of code, without increasing the readability or maintainability any.
I would actually argue that using functional programming would be a better solution for the third case, because that's very nearly what the original solution was doing already.
I think in the 4th example, Will was trying to demonstrate that you can create more procedural code inside of an object-oriented design instead of going to the extremes that the original example went to. The fact that he didn't make the entire thing procedural was because then it would actually be a mess of spaghetti code and very difficult to read. He did, however, reduce the number of classes and the number of methods and fields within each object by writing each of the objects in a more procedural way.
Now that I look more closely, the third example is really only using objects as a datatype (the objects only have methods and have no properties) which would seem to indicate it is a functional approach, so not really a good example of OO in the first place.
Well, (looking at the third example again) it's really functional programming wrapped in the guise of OOP - were I writing that solution in JavaScript, I would simply have a map of { string: function() } relationships and pull from the map as necessary, but the example in the video chose to wrap a single method within a class and call that particular method on each of the classes as necessary, which I suppose is the next best thing to pure function references.
I wish I did, mostly it is just opinion based on experience. A lot of that experience is looking at code actually being used in production and figuring out what it would take to fix bugs / add new features. Deal with enough technical debt and it becomes easier to spot. Working with code written by low cost developers in India or wherever is also a good learning experience.
99% of people would recommend some language, usually something that has a large open source community surrounding it. I think that provides way too much of a safety net, if you are stumped by a problem and it only takes you 5 minutes to find a solution on Google then you are going to solve your problem but not benefit from the experience of trying lots of wrong things. Also everyone wants something practical they can use later on, but that just makes them more likely to get stuck in a rut, they get attached to the first tool they use, they cling to its idiosyncrasies and never know what else is out there.
So my recommendation is to go to Google Drive and create a new Google Sheets document. The spreadsheet is your canvas. You will need to create a challenge for yourself to make the spreadsheet do something interesting, but here's one to start: write a program that whenever you put an 'x' in one of the cells, your program will draw a dot '.' in the surrounding cells. The first thing you will have to figure out is how to attach code to the spreadsheet. They use a language call Apps Script that is based on Javascript. You will have to learn a bunch of useless things about Apps Script to get your code working, and you will never have a use for that knowledge outside of the Google platform, but you will pick up some skills in the process - or perhaps you will fail miserably. Good luck.
Thank you. I took a c++ class and have been practicing by helping my friends who are taking that course now, but I will definitely try that out. I suppose I should clarify my question, is there any reading on the general practices of coding? Like a much more general, how to approach coding projects that isn't language specific? So if I were able to get an internship or job I'd have an understanding of how to embed myself in a team, while learning, without being too much of a hindrance.
Decades after OOP came out, I notice that humans are mostly unable to program in them. For me it is natural to do so, but for so many people they barely can grasp it.
14 comments
6 u/RevanProdigalKnight 05 Mar 2016 17:49
Object-oriented programming is only a disaster because people took it too far in languages like Java in forcing everything to be an object.
A nice blend of OO, Functional, and Procedural code is optimal, in my opinion.
2 u/404_SLEEP_NOT_FOUND 06 Mar 2016 04:35
Java had primitives. Ruby is all objects.
6 u/LOLATU 05 Mar 2016 20:03
Rolls eyes... There is no right way for everything. Every different solution to a problem comes with its own pluses and minuses. Weighing those against alternate solutions will point you to the right way to handle the task at hand. OOP is great for some things, functional for some things and procedural for smaller applications perhaps.
Procedural code is not typically reusable though. But if you have a small, one off task, it will be the fastest to get done. Those small one off things have a nasty habit of becoming bigger beasts though. YAGNI still applies I suppose.
4 u/Tecktonik 05 Mar 2016 21:20
The first example, processing a csv file and putting the data into a database, isn't really complicated enough for the structure to really matter. The only critical issue with that example is abstracting out file paths and user credentials. Otherwise the task for this example is a straightforward procedure.
The second example is such a clunky programming exercise I would assume it was originally chosen for its didactic value, since there is nothing practical about a coin flipping program.
In the third example, Will takes actual structured code and turns it into a maintenance nightmare. I have seen this type of thinking in a production system, "Hey, let's just turn these nested conditionals into a switch statement with 25 cases." Depending on the lifespan of the project, it can become a complete quagmire. It also tends to propagate itself into other code, since the choice of conditional logic (instead of a collection of objects) here will mean there is no layer of abstraction for other code to take advantage of, and another process, possibly dealing with the exact same collection of meaningless strings, will have to use switch logic as well. Using procedural code here is a decision to choose the option with loads of technical debt.
In the fourth example, Will shows that his procedural approach is better by producing an object oriented design. I am confused how this supports his original thesis that OO code is bad.
0 u/RevanProdigalKnight 05 Mar 2016 21:32
I have to agree with you on the first two examples, they were both so simple that they could only be used as exercises in object-orient programming.
In the third case I can see an argument for keeping an object-oriented approach - the solution that he took and turned into a procedural approach was very minimal and easy to understand even as an object-oriented solution because the main class and all the subclasses used were right there in the encapsulating class, and all the subclasses were simply implementing a single method. Turning it into a procedural method with the switch statement really just reduced the amount of code, without increasing the readability or maintainability any.
I would actually argue that using functional programming would be a better solution for the third case, because that's very nearly what the original solution was doing already.
I think in the 4th example, Will was trying to demonstrate that you can create more procedural code inside of an object-oriented design instead of going to the extremes that the original example went to. The fact that he didn't make the entire thing procedural was because then it would actually be a mess of spaghetti code and very difficult to read. He did, however, reduce the number of classes and the number of methods and fields within each object by writing each of the objects in a more procedural way.
0 u/Tecktonik 05 Mar 2016 22:02
Now that I look more closely, the third example is really only using objects as a datatype (the objects only have methods and have no properties) which would seem to indicate it is a functional approach, so not really a good example of OO in the first place.
0 u/RevanProdigalKnight 05 Mar 2016 22:11
Well, (looking at the third example again) it's really functional programming wrapped in the guise of OOP - were I writing that solution in JavaScript, I would simply have a map of { string: function() } relationships and pull from the map as necessary, but the example in the video chose to wrap a single method within a class and call that particular method on each of the classes as necessary, which I suppose is the next best thing to pure function references.
0 u/im_the_dude_man 06 Mar 2016 01:20
Is there any reading you recommend that has to do with what you're talking about?
0 u/Tecktonik 06 Mar 2016 03:47
I wish I did, mostly it is just opinion based on experience. A lot of that experience is looking at code actually being used in production and figuring out what it would take to fix bugs / add new features. Deal with enough technical debt and it becomes easier to spot. Working with code written by low cost developers in India or wherever is also a good learning experience.
0 u/im_the_dude_man 06 Mar 2016 05:11
Thank you. As someone who just started coding is there a place you would recommend starting?
0 u/Tecktonik 06 Mar 2016 07:35
99% of people would recommend some language, usually something that has a large open source community surrounding it. I think that provides way too much of a safety net, if you are stumped by a problem and it only takes you 5 minutes to find a solution on Google then you are going to solve your problem but not benefit from the experience of trying lots of wrong things. Also everyone wants something practical they can use later on, but that just makes them more likely to get stuck in a rut, they get attached to the first tool they use, they cling to its idiosyncrasies and never know what else is out there.
So my recommendation is to go to Google Drive and create a new Google Sheets document. The spreadsheet is your canvas. You will need to create a challenge for yourself to make the spreadsheet do something interesting, but here's one to start: write a program that whenever you put an 'x' in one of the cells, your program will draw a dot '.' in the surrounding cells. The first thing you will have to figure out is how to attach code to the spreadsheet. They use a language call Apps Script that is based on Javascript. You will have to learn a bunch of useless things about Apps Script to get your code working, and you will never have a use for that knowledge outside of the Google platform, but you will pick up some skills in the process - or perhaps you will fail miserably. Good luck.
0 u/im_the_dude_man 06 Mar 2016 07:47
Thank you. I took a c++ class and have been practicing by helping my friends who are taking that course now, but I will definitely try that out. I suppose I should clarify my question, is there any reading on the general practices of coding? Like a much more general, how to approach coding projects that isn't language specific? So if I were able to get an internship or job I'd have an understanding of how to embed myself in a team, while learning, without being too much of a hindrance.
0 u/Torchhead 08 Mar 2016 03:30
Steve Jobs said there was proof that OO makes you more productive. Do you guys know said proof?
0 u/roznak 09 Mar 2016 23:20
Decades after OOP came out, I notice that humans are mostly unable to program in them. For me it is natural to do so, but for so many people they barely can grasp it.