3 ms·

I've always found OO programming completely natural. n fact, it's the only kind of programming i've ever really done - create a structure with data members, and

I've always found OO programming completely natural. n fact, it's the only kind of programming i've ever really done - create a structure with data members, and then create functions to work on that structure. you can (and should) do this in low-level languages such as C and assembler. Of course, if you want to go the whole polymorphic route, i'd suggest using something like c++, but the key ideas are really structures, and functions that operate on those structures.

opportune 4y ago
As someone who started programming in BASIC, OO is a really good way to think about stuff (it introduces the abstraction of “conjoined data” that is typed and has functions) but it was not natural. It just feels natural now that I’ve spent so long in school and at work dealing with OO languages. I imagine if you had started with BASIC you’d feel the same
sureglymop 4y ago
I've always had a hard time because I was thinking.. why would I carry the performance hit of instantiating objects for a bunch of stuff?
- rolenthedeep 4y ago
  Why accept the performance hit of copying structs when you could use a reference type? It's a tradeoff. OOP makes sense for certain types of problems, and functional programming solves other problems. It's very much a case of selecting the right tool for the job. I recently transitioned from C# game programming to C++ embedded system firmware. Objects don't make much sense for what I'm doing now, and I'm coming to see the elegance of functional programming. There is no one answer, just a box of tools. What makes a good programmer is understanding each of your tools well enough to decide which one will solve your problem in the way you want.
- zabzonk 4y ago
  you have to instantiate variables anyway. grouping those variables in objects simply makes your code more understandable - there is really no extra cost.
- intelVISA 4y ago
  Could be wrong but, at least in C++, there's realistically no overhead to creating a trivial object that you wouldn't have by manually instantiating the variables anyway. (Ignoring virtual stuff, lengthy constructors -- code run is code run but a raw object I think is by itself relatively harmless.)
  - zabzonk 4y ago
    you are right - in c++ (and in most other languages that support oo) there is no overhead on instantiating a structure, or variables, that you would not have to pay anyhow.
intelVISA 4y ago
I really struggle outside OO paradigms as well. Having classes is such a useful framework to organize how data is stored, operated on, and moved around. The hardest bit is knowing when to stop, aiming for the RAII sweetspot in C++ is the goal not AbstractBeanFactoryFactoryBuilder().
xigoi 4y ago
If the functions are not built into the objects, that's not object-oriented programming.

opportune 4y ago

As someone who started programming in BASIC, OO is a really good way to think about stuff (it introduces the abstraction of “conjoined data” that is typed and has functions) but it was not natural. It just feels natural now that I’ve spent so long in school and at work dealing with OO languages. I imagine if you had started with BASIC you’d feel the same

sureglymop 4y ago

I've always had a hard time because I was thinking.. why would I carry the performance hit of instantiating objects for a bunch of stuff?

rolenthedeep 4y ago
Why accept the performance hit of copying structs when you could use a reference type? It's a tradeoff. OOP makes sense for certain types of problems, and functional programming solves other problems. It's very much a case of selecting the right tool for the job. I recently transitioned from C# game programming to C++ embedded system firmware. Objects don't make much sense for what I'm doing now, and I'm coming to see the elegance of functional programming. There is no one answer, just a box of tools. What makes a good programmer is understanding each of your tools well enough to decide which one will solve your problem in the way you want.
zabzonk 4y ago
you have to instantiate variables anyway. grouping those variables in objects simply makes your code more understandable - there is really no extra cost.
intelVISA 4y ago
Could be wrong but, at least in C++, there's realistically no overhead to creating a trivial object that you wouldn't have by manually instantiating the variables anyway. (Ignoring virtual stuff, lengthy constructors -- code run is code run but a raw object I think is by itself relatively harmless.)
- zabzonk 4y ago
  you are right - in c++ (and in most other languages that support oo) there is no overhead on instantiating a structure, or variables, that you would not have to pay anyhow.

intelVISA 4y ago

I really struggle outside OO paradigms as well. Having classes is such a useful framework to organize how data is stored, operated on, and moved around. The hardest bit is knowing when to stop, aiming for the RAII sweetspot in C++ is the goal not AbstractBeanFactoryFactoryBuilder().

xigoi 4y ago

If the functions are not built into the objects, that's not object-oriented programming.