I find myself literally feeling like this: https://youtu.be/GKYCA3UsmrU?t=2m20s when it comes to OOP.
The thing is, I need to program some stuff in Python for what I do and while Python is a multi-paradigm language, I find many libraries that I have to use are largely "OOP" libraries, although I prefer to program procedurally.
It also seems that Python does favor OOP.
My question is, does anyone have any experience in working with Python or a similar language, but getting by programming procedurally?
OOP blocks the crap out of my brain because I end up sitting overthinking solutions to problems whereas in C, I can just hammer code out and be done with it... Kind of ironic because the entire point of the higher level languages is to supposedly speed development up... But having 34981203948 ways to do something can be overwhelming. Not to mention, there's the whole "Pythonic way" train of thought which claims that you need to use all of Pythons OOP constructs to get the most of the language. Any advice would be appreciated. Thank you.
The thing is, I need to program some stuff in Python for what I do and while Python is a multi-paradigm language, I find many libraries that I have to use are largely "OOP" libraries, although I prefer to program procedurally.
It also seems that Python does favor OOP.
My question is, does anyone have any experience in working with Python or a similar language, but getting by programming procedurally?
OOP blocks the crap out of my brain because I end up sitting overthinking solutions to problems whereas in C, I can just hammer code out and be done with it... Kind of ironic because the entire point of the higher level languages is to supposedly speed development up... But having 34981203948 ways to do something can be overwhelming. Not to mention, there's the whole "Pythonic way" train of thought which claims that you need to use all of Pythons OOP constructs to get the most of the language. Any advice would be appreciated. Thank you.
Edited by Todd
on
Reason: Initial post
Think it should be mentioned that the "conventional way" even if it's not great has value since it's common ground with everyone else. Coming to a company and not following the coding standard is bad, even if you think your code is better off for it. If anything a discussion with your leads might be in order and see if a compromise can be made but in the end it's their code base. Sorry, not saying you believe this but just wanted it said.
As for OOP, a guy said "Objects aren't bad, it's the second O, the Oriented part that's the problem". It's like the saying "for a hammer, every problem is a nail". Tricky thing is to look at the problem the simplest way possible. There's no problem creating a class or a template or anything really, the thing to keep in mind is that it's a tool and tools are supposed to make things easier. Only use the features that helps you make the thing you're making.
Best way to stop overthinking is to think "what's the dumbest way I can do this". And by dumbest I really mean the dumbest. Think of what you want it to do and write down the steps, and then write those steps. Don't go try and think of clever solutions to anything. Just keep your code clean and readable and make sure you can come back and swap it out later. You can write a physics solver that just tests every element against every element and call it a day. You'll have to come back later and rewrite it but that's not something to be afraid of. When you come back you'll be greeted by code so simple it's trivial to understand what it does and then you can optimize it.
As for OOP, a guy said "Objects aren't bad, it's the second O, the Oriented part that's the problem". It's like the saying "for a hammer, every problem is a nail". Tricky thing is to look at the problem the simplest way possible. There's no problem creating a class or a template or anything really, the thing to keep in mind is that it's a tool and tools are supposed to make things easier. Only use the features that helps you make the thing you're making.
Best way to stop overthinking is to think "what's the dumbest way I can do this". And by dumbest I really mean the dumbest. Think of what you want it to do and write down the steps, and then write those steps. Don't go try and think of clever solutions to anything. Just keep your code clean and readable and make sure you can come back and swap it out later. You can write a physics solver that just tests every element against every element and call it a day. You'll have to come back later and rewrite it but that's not something to be afraid of. When you come back you'll be greeted by code so simple it's trivial to understand what it does and then you can optimize it.
I don't understand why things have to be that different to the way you would write something in C. You said yourself that Python in a multi-paradigm language after all.
If you're using a library provided by a third-party then you don't have to come up with the OOP design yourself, and you can just use it within your own code however you please. In that sense it's not much different to just having some structs in C that you pass into public interface functions to manipulate data.
If you're writing your own code then why do you need to sit down and design the program using OOP if you don't like it that way? I mean, no one is forcing you to write classes in your own Python programs, right? You could just use functions and objects like you would in C anyway.
Admittedly I don't write much Python, so maybe I'm missing something here that's making it difficult for you.
Is the problem that a third-party library forces you to write your own classes and use things in a strictly OOP way?
Or can you really write things how you want and you just don't like the fact that there are things like classes that you have to use from third-party libraries?
I guess what I'm getting at here is that it would help if you gave an actual example of what your problem actually is :)
If you're using a library provided by a third-party then you don't have to come up with the OOP design yourself, and you can just use it within your own code however you please. In that sense it's not much different to just having some structs in C that you pass into public interface functions to manipulate data.
If you're writing your own code then why do you need to sit down and design the program using OOP if you don't like it that way? I mean, no one is forcing you to write classes in your own Python programs, right? You could just use functions and objects like you would in C anyway.
Admittedly I don't write much Python, so maybe I'm missing something here that's making it difficult for you.
Is the problem that a third-party library forces you to write your own classes and use things in a strictly OOP way?
Or can you really write things how you want and you just don't like the fact that there are things like classes that you have to use from third-party libraries?
I guess what I'm getting at here is that it would help if you gave an actual example of what your problem actually is :)
I use Python quite a lot and I write procedural code exclusively. It's never been a significant problem.
My advice is to ignore what the "Pythonic" crowd says in general. You can go a long way with basic syntax and simple data structures and that's probably the better thing to do if you only occasionally use Python. You're a lot more likely to be able to suss out explicitly-written logic after a few months away from Python than you are to remember what the heck some clever little built-in (and totally opaque) "Pythonic" method does.
It's quite easy to extend Python with C, as well, so that may be an option you want to explore.
As far as libraries, I can't say I've had any particular issue using them, OOPy or not, once I figured out how to make them do what I want. The hard part is getting to that point. But, it's always like that when you're relying on Someone Else's Code. The effort required to learn it is inversely proportional to the effort they put into their documentation. If they have a pile of tutorials with good code examples---and plenty of Python libraries do---you're laughing. But if it's just a list of objects/methods and vague instructions, prepare to experiment a lot. Or just find another library.
My advice is to ignore what the "Pythonic" crowd says in general. You can go a long way with basic syntax and simple data structures and that's probably the better thing to do if you only occasionally use Python. You're a lot more likely to be able to suss out explicitly-written logic after a few months away from Python than you are to remember what the heck some clever little built-in (and totally opaque) "Pythonic" method does.
It's quite easy to extend Python with C, as well, so that may be an option you want to explore.
As far as libraries, I can't say I've had any particular issue using them, OOPy or not, once I figured out how to make them do what I want. The hard part is getting to that point. But, it's always like that when you're relying on Someone Else's Code. The effort required to learn it is inversely proportional to the effort they put into their documentation. If they have a pile of tutorials with good code examples---and plenty of Python libraries do---you're laughing. But if it's just a list of objects/methods and vague instructions, prepare to experiment a lot. Or just find another library.
roughcoat, I think you hit the nail on that head with that one.
Bozemoto and Sintex, I'm not sure if you guys are familiar with the "Pythonic way" stuff, but it can basically be summed up as:
Although you CAN use Python to write code similar to C (e.g. a for loop iterating using I and incrementing it), it's "Pythonic" to not do this and instead to use for something in some_collection: etc...
That's a contrived and probably pretty lackluster example but I'm tired right now... It gets a lot more heavy than that... For example using list comprehensions and lambdas to filter data and make little "inline functions" and so on... Basically, a lot of stuff I wouldn't find myself doing when programming in C regularly. Essentially, the Pythonic way of doing things is "use the most Python-specific constructs as possible and avoid traditional programming ways."
My cry in this post was partially due to having to work with third party library classes/instances, but also partially due to this "Pythonic" thinking. roughcoat's answer really wrang home with me in that what I should probably do is not worry too much about the Pythonic crap because the fact is, the few people who will be interacting with my program at work are also C programmers anyway, and we are not "shipping a production app" when we use Python... Rather, we are writing small tools, utilities, and plugins for internal use only.
So perhaps if I stop stressing about making things Pythonic (despite the Python guru's recommendations to do so), that will probably alleviate my qualms enough to where I can deal with the 3rd party object stuff as needed without too much headache.
Another closing example of what I meant by OOP mess is that where in C I would throw a struct on the heap and interact with it no problem, in Python, I found situations where I would write up a class, then be stressing about what needs to inherit from that class, then suddenly I need to compare the class object and thus needed to start writing "Python magic methods" (https://rszalski.github.io/magicmethods/) and next thing I knew, I was spending more F'ing time with all of that, writing dozens of methods, when the entire point of using Python over C was to bang out a script real quick..
So hopefully that clears up the initial problem some more.
Bozemoto and Sintex, I'm not sure if you guys are familiar with the "Pythonic way" stuff, but it can basically be summed up as:
Although you CAN use Python to write code similar to C (e.g. a for loop iterating using I and incrementing it), it's "Pythonic" to not do this and instead to use for something in some_collection: etc...
That's a contrived and probably pretty lackluster example but I'm tired right now... It gets a lot more heavy than that... For example using list comprehensions and lambdas to filter data and make little "inline functions" and so on... Basically, a lot of stuff I wouldn't find myself doing when programming in C regularly. Essentially, the Pythonic way of doing things is "use the most Python-specific constructs as possible and avoid traditional programming ways."
My cry in this post was partially due to having to work with third party library classes/instances, but also partially due to this "Pythonic" thinking. roughcoat's answer really wrang home with me in that what I should probably do is not worry too much about the Pythonic crap because the fact is, the few people who will be interacting with my program at work are also C programmers anyway, and we are not "shipping a production app" when we use Python... Rather, we are writing small tools, utilities, and plugins for internal use only.
So perhaps if I stop stressing about making things Pythonic (despite the Python guru's recommendations to do so), that will probably alleviate my qualms enough to where I can deal with the 3rd party object stuff as needed without too much headache.
Another closing example of what I meant by OOP mess is that where in C I would throw a struct on the heap and interact with it no problem, in Python, I found situations where I would write up a class, then be stressing about what needs to inherit from that class, then suddenly I need to compare the class object and thus needed to start writing "Python magic methods" (https://rszalski.github.io/magicmethods/) and next thing I knew, I was spending more F'ing time with all of that, writing dozens of methods, when the entire point of using Python over C was to bang out a script real quick..
So hopefully that clears up the initial problem some more.
Edited by Todd
on
Python is an OOP language, so you can't really avoid it. I write a lot of python, and my approach is to use Python's classes similar to C structs, just as data containers. I will add accessor methods to access the data in a more convenient way, but most of the work is done in standalone functions. I also use itertools a lot but don't try to force it where a for loop will do fine...
I do tend to avoid libraries that expect you to subclass their stuff, but most things aren't really built that way, or you can write a little stub that calls into a simpler interface if you have to.
Just because there is a "pythonic" way to do something doesn't mean you have to do it that way if that doesn't work for you. For example, the "magic methods" are good to know about, but I almost never use them. E.g. you could make something a class and write a __cmp__ for it, or you could just call sort with a lambda for key=, or often I'll just copy a list into a bunch of tuples with the sort key as the first element, sort/filter that, then copy them out.. etc...
One of the "nice" things about python is it frees you from worrying about if you're doing something efficiently because even the most efficient way to do something will run slow as heck anyways. Don't get attached to writing "clean" or "proper" python code, write ugly code fast that solves the problem. If you get to the point where something is large enough or mission critical enough that you feel like it's risky doing this, then it's probably not something that shouldn't be written in a scripting language or dynamically typed language anyways, and maybe that's a sign to step back and reevaluate the overall architecture.
I do tend to avoid libraries that expect you to subclass their stuff, but most things aren't really built that way, or you can write a little stub that calls into a simpler interface if you have to.
Just because there is a "pythonic" way to do something doesn't mean you have to do it that way if that doesn't work for you. For example, the "magic methods" are good to know about, but I almost never use them. E.g. you could make something a class and write a __cmp__ for it, or you could just call sort with a lambda for key=, or often I'll just copy a list into a bunch of tuples with the sort key as the first element, sort/filter that, then copy them out.. etc...
One of the "nice" things about python is it frees you from worrying about if you're doing something efficiently because even the most efficient way to do something will run slow as heck anyways. Don't get attached to writing "clean" or "proper" python code, write ugly code fast that solves the problem. If you get to the point where something is large enough or mission critical enough that you feel like it's risky doing this, then it's probably not something that shouldn't be written in a scripting language or dynamically typed language anyways, and maybe that's a sign to step back and reevaluate the overall architecture.
Edited by Joel Davis
on
Todd
list comprehensions and lambdas
This is not OOP. This is functional programming (although a fairly simplified subset of it). Other languages have this, including mainstream ones. It is prevalent enough that it may be worth learning and understanding, even if you end up preferring not to use it.
Todd
So perhaps if I stop stressing about making things Pythonic (despite the Python guru's recommendations to do so), that will probably alleviate my qualms enough to where I can deal with the 3rd party object stuff as needed without too much headache.
Adaptability is a skill that comes from learning to use a lot of different tools. Avoiding learning new tools (even if they turn out to be impractical) basically robs you of growth in this area. You might be able to "go deep" on your understanding, but "going broad" is also valuable.
I suggest thinking carefully before throwing other people's advice away, especially from your teammates. You are going to learn way more from your teammates than from programming-problem-flavor-of-the-week.
Also, think twice before going cowboy and ignoring the coding standard (if one already exists). The standard might suck, but so does having to read each programmer's personal take on what code should look like when maintaining an existing code base. If there is no standard, maybe you should work with the "Python guru" and others on the team to establish one, rather than just flying solo.
Edited by Merlyn Morgan-Graham
on
Todd
OOP blocks the crap out of my brain because I end up sitting overthinking solutions
I call it analysis paralysis. You don't get any work done. You spend time doing make busy work, like worrying over the perfect name for a variable or class and trying to make your code look nice. OOP is what made me not want to be a professional programmer any more. lol
I think what happens with intelligent people is they are attracted to things that are super complicated. They enjoy the challenge of mastering complicated things like it is a mental workout.
I am also starting to think the same about an editor some programmers like to use. I've been using it for more than a year, I am still not fast with it and when I am inspired and want to hammer out something quickly, I find I start making all kinds of mistakes and get really frustrated. I call this editor 'sperg bait. It caught me!
That is why I like Casey's ideas. He cuts everything back to the bare essentials.
Edited by Mór
on
MórTodd
OOP blocks the crap out of my brain because I end up sitting overthinking solutions
I call it analysis paralysis. You don't get any work done. You spend time doing make busy work, like worrying over the perfect name for a variable or class and trying to make your code look nice. OOP is what made me not want to be a professional programmer any more. lol
I think what happens with intelligent people is they are attracted to things that are super complicated. They enjoy the challenge of mastering complicated things like it is a mental workout.
I am also starting to think the same about an editor some programmers like to use. I've been using it for more than a year, I am still not fast with it and when I am inspired and want to hammer out something quickly, I find I start making all kinds of mistakes and get really frustrated. I call this editor 'sperg bait. It caught me!
That is why I like Casey's ideas. He cuts everything back to the bare essentials.
This is too true. And it is stupid, since programming ALWAYS is hard. (If you do anything useful of decent quality). We have no use for making the fairly easy things hard, we want solutions that makes very hard things slightly less so.
Telash
This is too true. And it is stupid, since programming ALWAYS is hard. (If you do anything useful of decent quality). We have no use for making the fairly easy things hard, we want solutions that makes very hard things slightly less so.
That's definitely false that programming is always hard. Even on a large complex and challenging project, for an experienced programmer a sizable amount of the work comes down to writing trivial little components or glue and requires minimal thought.