Object Oriented Programming really an Advantage

I have just learned a little of Javascript, some principles, what objects are, prototypes, inheritance, constructors.
I played a little with node.js

I also read once about the tcl extension tclOO for object oriented programming, but forgot everything.

Sure, the theory looks nice. I do understand that it may have advantages, encapsulating code, making some order,
but I have the feeling it is an exaggeration. If I have to program, I have no idea how to begin using that.

Are eventually pointers to structures in C not enough?

What is your opinion / experience?
 
Object Oriented is a way of thinking.
What is a program?
Very simplistically, "data in, transform, data out". Staying at that, it's mostly functional, concentration on the transforms of the data (algorithms).
The Data typically represents an object, maybe as simple as a character, maybe as complex as a motor vehicle.
But what is a motor vehicle? Is it a Truck, a Bus, a passenger car, a motorcycle?

Object Oriented programming typically forces you to think more about the "what am I working on, what does it expose to the public, what are the characteristics" and less about "how do I change it".
Motor vehicles accelerate and stop. A truck does both, a motorcycle does both. They just do them differently.

OO can be done in just about any language: some languages make it easier.
 
What is a program?
One has a state, represented by the memory, data input, and rule to change the state and give an output depending on this, until an end state.

Perhaps OO languages offer ways to structure data in memory?

My question was more how to use this.

Object Oriented programming typically forces you to think more about the "what am I working on, what does it expose to the public, what are the characteristics"

Perhaps the commands for creating widgets in Tk generate objects, perhaps that could inspire some uses, but is it done so frequent that one needs an inflated language?

... or this
~334 pages for starting ....
 
Nim,crystal,fsharp,scala have object orientation and you can learn it fast.
If I would really need it, I would learn TclOO, because I use Tcl.
Javascript seems omnipresent, that is why I just learned a little.
But I told you my problem: I do not really know what to do with that.
 
I ended up with a negative view of OO programming.

C++ of course invests most of the recent development (much of those 1000 pages) into facilities that are not object-oriented.
 
C++ of course invests most of the recent development (much of those 1000 pages) into facilities that are not object-oriented.
Also that is terrible.

C does not change a lot, but in my opinion also too much. In any case you have a clear kern of the language.

I learned lisp 1.5 and used prolog, they also have a clear kern.

Tcl also, even if it has always more commands, they follow a structure, there is something like a kern language,
one programs reading man pages. It may be seen as C with some libraries. In any case, they are well thought commands.

Something similar could be said about R.

With Java script I did not find a concise introduction showing a kern, but I think there is something like that in that inflation.
 
What I am saying is that C++ is not an object-oriented language anymore.
I do not disagree with this.

Some things from the language I find useful; things in the STL in particular. We've all written linked list code, the STL has just about every variation one would ever need. Someone else has verified the correctness of the algorithms, all I need to do make my data (object) into the proper container and it just works. STL and the iterator paradigms? Nice and consistent across different spaces. Algorithms in the STL, save me time and effort.

Now I personally think the STL (think of it as just a library) is not really Object Oriented but rather algorithms, made generic to work with Objects. That's my paraphrase, likely not even close to technically correct, but the way it makes sense to me.

I've come to think of C++ as it's original definition by Stroustroup:
C plus stuff (objects)

The STL (Standard Template Library) is just a library of algorithms designed with generic interfaces, written by people a lot smarter than me (think people that write compilers) and verified/mathematically proved correct. That means I can leverage off their work to make my job easier.

My real world use of C++ led me to "one can use C++ without objects, take advantage of standard language features or one can dive in head first and go overboard".
Some language features related to "pointers" are confusing at first (compared to C and void* mapping to everything) but actually help at compile and run time, but require a whiteboard and pens to map things.

Anyway, my opinions, whatever you think is fine.
 
C++ is bloated. Just like rust. It takes years to master it.
Only if you think you need to master ALL of it.
I have a book from 1995 on the STL, about 900 pgs. Very good reference for the time, still applicable now. The fundamentals are Containers, iterators, algorithms and functions.
Wrapping your head around these "What is a container, how does it work" gets you a giant step forward to understanding (you must understand before you master). Now if there are 37 different kinds of containers, you ignore that; you concentrate on "all containers have the same properties". Like "I learned to drive a car, so I don't care if it's a Ford, Chevy, Yugo, BMW".
Then you step to iterators and you realize "Oh iterators all do this. I++ I-- I.prev() I.next() and they operate the same way on any container".
Same with algorithms and functions.

So at least for me, figuring out and really understanding the fundamentals of C++ (really the STL) let me not master the language, but become conversational in it (Yes, human language metaphor because it applies. Conversational Dutch vs Mastering Dutch? I think different application of effort)
 
OOP is a "way of thinking"—this is subjective, everyone sees things differently. C++, JavaScript, and Java are OO languages. You can use C++ like C and therefore not use OO, or you can use classes and therefore use OO. The same goes for JavaScript.Basically, your program is full of functions that use data structures, or you define objects that have properties (data) and methods (functions). This is the foundation, your mental organization. The rest is just academic rhetoric (in my humble opinion).
 
  • Like
Reactions: mer
What I dislike the most is strong OO programming with RPCs on remote objects. Some object on a different computer that can changr brhavior at any moment. Nightmare to debug.
 
What I dislike the most is strong OO programming with RPCs on remote objects. Some object on a different computer that can changr brhavior at any moment. Nightmare to debug.
Oh, completely agree.
RPC done via traditional RPC/CORBA vs current HTTP REST API? Same thing debugging.
"I sent this but got this error or bad data back, why"

Pointing fingers "not my problem you didn't follow the undocumented API".
 
I just read this (boring) article:

Only interesting paragraph for me:

Abstraction​

Abstraction is the essential core concept of OO but unfortunately a lot of descriptions of OO either explain it poorly or ignore it entirely. Abstraction in OO manifests itself mainly as sub-typing polymorphism i.e.: inheritance of interface/contract. This is the only thing that matters about OO if you are trying to understand it conceptually. It’s the common defining concept of object orientation (as scoped in the introduction.) All of the other concepts that are typically thrown around with regard to OO are details which may or may not be relevant in a given OO language. Code that doesn’t use this approach is not object oriented regardless of what language is was written in or whether the author calls it OO. Simply put: anyone who talks or writes about OO and doesn’t identify this as the defining feature is describing, at best, a degenerate form of OO.
 
  • Like
Reactions: mer
Thanks for that.
Like almost everything else in life, OOP is not good or bad, it's a tool. Apply a tool correctly and it's good. Apply it incorrectly and it's bad.
So understand the tool (or lots of tools) and see how to apply it to your specific situation.
 
Like almost everything else in life, OOP is not good or bad, it's a tool. Apply a tool correctly and it's good. Apply it incorrectly and it's bad.
I think, one thing is OO programming style as you described it, concentrating on objects, other the OOP languages. The languages are the tools. Perhaps this "sub-typing polymorphism" could also be achieved in C, although its type strength may be an obstacle.
 
Back
Top