• Create Account

how alive is oop?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

26 replies to this topic

#1 fir   Members   -  Reputation: -464

Like
0Likes
Like

Posted 12 February 2014 - 07:17 AM

I probably be considered for setting up flame war but this is not my intention i would like just get the information or some 'information feeling'

because to be honest i got no idea - i am working in procedural and modular paradigms for years and to not do  any way of oop paradigms

so i got no idea if something changed over the last couple of years,

10 years ago OOP was popular Is it so much popular today of more or less? Is possible for someone to estimate how much projects are made in OOP versus how many procent projects are made in no-oop paradigms ? tnx for the info

Edited by fir, 12 February 2014 - 07:19 AM.

#2Mona2000  Members   -  Reputation: 1776

Like
5Likes
Like

Posted 12 February 2014 - 07:24 AM

It's extremely popular, about 83.743% of projects are using OOP languages.

#3krinosx  Members   -  Reputation: 606

Like
2Likes
Like

Posted 12 February 2014 - 08:09 AM

I dont know where Mona get this 83.743% number...

But, I think its very popular... I mean... OOP is a 'way of thinking'... so, you may implement its concepts even in languages like 'C' ( that is not OO oriented )...

Btw.. today OOP come with other flavors... like 'Aspects', IOC,  and another concepts that help OOP projects to achieve better results...

But I think its difficult to estimate how much projects are done with OOP vs projects are not done with OOP... we must start thinking in What kind of projects? Enterprise applications? games? embedded applications?

OOP has its uses.. but will does not implement a 'printer driver' with oop concepts... I think the enterprise applications ( ERPs, accounting applications, etc ) may use some advantages of OOP ( like code reuse, easy of maintain, easy of understand, etc etc )

#4 fir   Members   -  Reputation: -464

Like
0Likes
Like

Posted 12 February 2014 - 08:25 AM

I dont know where Mona get this 83.743% number...

But, I think its very popular... I mean... OOP is a 'way of thinking'... so, you may implement its concepts even in languages like 'C' ( that is not OO oriented )...

Btw.. today OOP come with other flavors... like 'Aspects', IOC,  and another concepts that help OOP projects to achieve better results...

But I think its difficult to estimate how much projects are done with OOP vs projects are not done with OOP... we must start thinking in What kind of projects? Enterprise applications? games? embedded applications?

OOP has its uses.. but will does not implement a 'printer driver' with oop concepts... I think the enterprise applications ( ERPs, accounting applications, etc ) may use some advantages of OOP ( like code reuse, easy of maintain, easy of understand, etc etc )

I know it is maybe hard to estimate but was curious if most projests people see (in their work etc) are OOP or maybe most are not OOP,

I am outside of this and just dont know, I remember a couple a years ago almost all i was working with (but maybe only about 5 projects i got experience with comes to my mind) was OOP - but it was a couple of years ago and today it seem to me people talk less about it - but maybe

I am more unavare of this becouse i am doing things only in procedural and modular c so jm just unconscious of this

allright so probably i may assume it is still in use like it was before (i know android has oop framework enforced and iphone too, so it maybe even goes a bit further)

Edited by fir, 12 February 2014 - 08:28 AM.

#5Buster2000  Members   -  Reputation: 3813

Like
2Likes
Like

Posted 12 February 2014 - 08:48 AM

Even if you look through GitHub projects that use non oop languages you will see that people are still writing their code in an oop way.

So yes it is very much alive.  To be honest there all of these paradigms are becoming irrelevant as languages are adapting to support all paradigms.  For example C++11 and Scala allow you to use Procedural, Funtional, OPP or a combination of these.

#6Vilem Otte  Crossbones+   -  Reputation: 2317

Like
3Likes
Like

Posted 12 February 2014 - 09:17 AM

I thought of posting the "Still alive" song here, but the people could down vote me. Anyways it is very popular, although multi paradigm is getting even more popular (especially with C++ (since C++11) and C# (there are of course others - like named Scala).

I always stand on the side - use those weapons that fits the enemy -> e.g. use OOP on the place, where OOP is strong. OOP is weak in some areas too, so why not use Functional, Procedural, or any other that fits this problem ~ e.g. don't try to force OOP on places where it doesn't fit well.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

#7Álvaro  Crossbones+   -  Reputation: 19044

Like
9Likes
Like

Posted 12 February 2014 - 09:37 AM

I don't think these trends change much in the timescale of a couple of years.

I use objects all the time, but my programming is in no way "oriented" towards objects. Objects are just a tool, and a pretty useful one because it emphasizes interfaces between parts of the code, which allows large systems to be built without getting overwhelmed by complexity. But to me "Object Oriented Programming" is a bit like "Nail Oriented Roofing".

Even if you think of your programming as "procedural" and "modular", chances are you'll end up using objects naturally. For instance, if you have a type Image', it is very likely you'll end up having a module that implements functions that operate on Image variables.

In C, the header file would look something like this:
/* ... */

typedef struct {
unsigned char R, G, B, A;
} Color;

typedef struct {
unsigned width, height;
Color *pixel_data;
} Image;

/* Create a new image, allocating memory for its pixel data. */
void create_image(Image *image, unsigned width, unsigned height);

/* Clear an image by setting every pixel to the given color */
void clear_image(Image *image, Color color);

void set_pixel(Image *image, int x, int y, Color color);

Color get_pixel(Image const *image, int x, int y);

void bit_blit(Image *destination, Image const *source, int left_x, int top_y);

/* ... */

I made the switch from C to C++ in 2001. Before then, my C code often looked a lot like this example. If you find yourself writing code in this style, you too are using objects. What are called "member functions" in C++ are essentially the functions that take a first argument of type Image *'. When it has type Image const *', it is called a "constant member function". In C++ instead of set_pixel(&my_image, x, y, my_color);' you would call the member function as my_image->set_pixel(x, y, my_color);'.

Once you get used to using objects, a lot of your code will naturally be organized this way. However, there are things that in my mind don't fit this model at all. For instance, mathematical functions like log' don't naturally take a first argument that is a pointer to anything, so it's better to use a free function (i.e., a non-member function) in this case.

A project can be anywhere in the spectrum between not using objects at all and the extreme of organizing all the code as objects. All the projects I have worked on are somewhere in the middle, with lower-level parts of the code using objects only sporadically and higher-level parts being closer to the OOP extreme.

There are good reasons why you may not want to use OOP when dealing with low-level code. For instance, modern hardware is very good at operating on batches of data, either through SIMD instructions or using GPUs. An programmer using OOP in a straight-forward manner can easily write code that does things on a large collection of objects one object at a time, perhaps calling a virtual function on each object (similar to calling a function pointer that is part of the type, in non-OOP terms). That eliminates any possibility of using an SIMD implementation, and therefore results in code that doesn't make optimal use of the computational resources available. An alternative design would have separate arrays for each specific type of object, so instead of calling a virtual function on each object, you can call a function that performs a fixed operation on a collection of objects, and then a SIMD implementation becomes possible. Check out this thread: http://www.gamedev.net/topic/575076-what-is-data-oriented-programming/

Edited by Álvaro, 13 February 2014 - 06:48 AM.

#8cdoubleplusgood  Members   -  Reputation: 895

Like
0Likes
Like

Posted 12 February 2014 - 10:07 AM

OOP is still popular, and I don't think this will change soon.

However, while 15 years or so back, OOP was the one and only paradigm, today other aspects get more attention. One of the popular examples used to explain the concept of objects was having classes for geometrical shapes, and having a virtual method "Draw" that draw each shape. Today, few people would mix the data this way with functionality. There is clearly a tendency to separate data from algorithms. Don't put everything in one class just because it is somehow related.

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

#9Kimmi  Members   -  Reputation: 652

Like
0Likes
Like

Posted 12 February 2014 - 10:07 AM

If you want to design some kind of a UI with buisness logic OOP is common I would say. If you have to adress realtime algorithms which are also cache-optimized OOP will not win. Here you need to think near to your HW and OOP is not the best choise.

Greetings,

Kim

A complicate solution may indicate a not understood problem.

@KimKulling

#10SeanMiddleditch  Crossbones+   -  Reputation: 15452

Like
1Likes
Like

Posted 12 February 2014 - 12:03 PM

I probably be considered for setting up flame war but this is not my intention i would like just get the information or some 'information feeling'
because to be honest i got no idea - i am working in procedural and modular paradigms for years and to not do
any way of oop paradigms
so i got no idea if something changed over the last
couple of years,

Depends. Are we talking about the original OOP introduced around 30 years ago (or more) before C++ was even a twinkle in Stroustroup's eye? Are you talking about the horrific OOP taught in Java schools (derived from the specific, limited, and inflexible "OOP" support in C++) and most terrible tutorials/articles on the web? Are we talking about the form of OOP that all but disallows inheritance or type hierarchies? Are we talking about a specific language's implementation of its object model or about object models in general?

The complex answer is that yes, it has changed, because the OOP you learned about a few years ago and which is encoded in languages like Java or (to a lesser extent) C++ is flawed and more people understand that today than they did a decade ago. This has led (in my personal belief) to a lot of fads pushing for "less OOP" when really people just want "less _bad_ OOP" (but they lack the experience/education to tell bad and good OOP apart). This similar in a way to the rise and fall of dynamic languages due to all the misconceptions of static typing based on the limitations of a few specific popular static languages like C++ and Java. C++ has seen a lot of growth in non-OOP code because it was (thankfully) designed as a multi-paradigm language and it's quite easy to use functional and declarative programming style _in combination with_ objects when appropriate while pure (or mostly pure) functional languages are not at all taking over.

Edited by SeanMiddleditch, 12 February 2014 - 06:41 PM.

#11mhagain  Crossbones+   -  Reputation: 11892

Like
0Likes
Like

Posted 12 February 2014 - 12:43 PM

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

It depends.

Some people will look at this and say "well an angle is an object, it stores data, you perform operations on it, sometimes you want it's value in degrees, sometimes in radians, it only makes sense to store values 0 to 360 so let's overload all operators to enforce that", so they go ahead and design an angle class that does all of this for them, and now every time they need to operate on angles they get all their desired behaviour automatically.  And sometimes that's exactly what they need and sometimes it's overkill, but if it's what they need then it is a valid way of doing things.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

#12Álvaro  Crossbones+   -  Reputation: 19044

Like
0Likes
Like

Posted 12 February 2014 - 01:20 PM

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

It depends.

Some people will look at this and say "well an angle is an object, it stores data, you perform operations on it, sometimes you want it's value in degrees, sometimes in radians, it only makes sense to store values 0 to 360 so let's overload all operators to enforce that", so they go ahead and design an angle class that does all of this for them, and now every time they need to operate on angles they get all their desired behaviour automatically.  And sometimes that's exactly what they need and sometimes it's overkill, but if it's what they need then it is a valid way of doing things.

That's why I used log' and not sin' as my example of this situation. You can make all these functions be members of the number type, but then you'll find functions that take two arguments, where it's not easy to identify what you are doing as primarily being an operation on one of the arguments. Do you want to write x.hypot(y) instead of hypot(x,y)? Or y.atan2(x) instead of atan2(y,x)?

#13Bregma  Crossbones+   -  Reputation: 7815

Like
8Likes
Like

Posted 12 February 2014 - 01:59 PM

If you're going to ask a question about the vague and poorly-defined term 'OOP' you're going to get a broad enough spectrum of answers that you can choose any you like to reinforce your beliefs.

Stephen M. Webb
Professional Free Software Developer

#14Ryan_001  Prime Members   -  Reputation: 2792

Like
0Likes
Like

Posted 12 February 2014 - 02:45 PM

The 'OOP' moniker covers a lot.  When I first started using C++ I was told (and naively assumed) that what I was learning was OOP.  In truth as I learned more I have found that modern C++ isn't really an OOP language.  Maybe I'm just splitting hairs here, but here's why I feel that way.  It lacks two fundamental OOP operations, virtual constructors and multi-dispatch.  These seem like minor things at first, until you start getting deep into OOP.

Virtual constructors allow you to treat an object, as truly an object.  Without being able to copy an object (due to fear of slicing, or loss of data, or change of type) a vast number of algorithms can't be performed.  There are ways around this, though usually all quite involved.

Multi-dispatch is required to truly make use of the hierarchical nature of OOP objects.  C++ does single dispatch fine, and that's what people think of when they think of OOP.  But this is such a small subsection of the set of functions that you would want to exhibit virtual behavior.  Where-as virtual constructors are something most C++ programmers are aware they are missing, and can see its use; I find that few even realize what multi-dispatch can do and why they actually might need it.

These are fundamental operations much like + or / are to arithmetic.  You can do arithmetic without say multiply, but it wouldn't be pretty.  Likewise OOP programs often have ugly hacks, or unwieldy factories/managers to get around these lack of virtual constructors.  And sadly few seem to even realize all the awesome things multi-dispatch can do, and so don't even know why they would miss it.

This is all a bit off topic, as you didn't ask about OOP in C++ specifically; but I found in my case and in many others that a programmers first impression of OOP is through C++, C#, or java (which are all quite similar).

I personally don't think C++ is an OOP language.  Templates + the stl have proven to be far more useful and powerful within the C++ paradigm (I'm not saying they are more useful in general, just with the way C++ approaches things templates are more powerful that classes IN C++).  So much so that most modern C++ is about containers + algorithms, not classes (Alexander Stepanov brought about a truly ingenious change to programming).  Its not that classes aren't used, but for the most part they are pretty structures; they store data, give it a unique and concrete type, and manage RAII.  Where-as the number of classes with virtual functions in any given project I can often count on one hand, almost every function and struct is littered with std::vector and std::fill, std::for_each and std::map.

Edited by Ryan_001, 12 February 2014 - 02:46 PM.

#15ChaosEngine  Crossbones+   -  Reputation: 4292

Like
5Likes
Like

Posted 12 February 2014 - 04:04 PM

Some aspects of OOP are just generally good software engineering practice.

Separation of interface from implementation, modular design with high cohesion and low coupling, enforcement of invariants... these are all useful concepts no matter what language you're using.

Other aspects (polymorphism, for instance) are less generally applicable, but still have their uses.

There is clearly a tendency to separate data from algorithms.

Tell that to a Haskell programmer

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

That's generally down a specific language failing (java and C#, I'm looking at you). In this case, what they really want are free functions grouped within a namespace, not a static class. Math.Sin(x) is a damn fine idea, especially if somewhere else in your code you have a Sinner.Sin() method.

Lack of namespaces is, IMHO, one of C's great failings.

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#16frob  Moderators   -  Reputation: 39019

Like
4Likes
Like

Posted 12 February 2014 - 05:00 PM

OOP is not a concrete thing. You can't say things like "I'm going to open up a case of OOP today", or "Let's put some OOP into this corner over here".  OOP is a concept.

At it's most basic level, OOP means that you have little gobs of data, called objects, and you do things to manipulate them. That concept is alive and strong, and isn't going anywhere.

People like to make ideas like that into formal statements, they like to add mandatory features like inheritance or whatnot, but that is playing a lawyer and trying to split hairs.

Let's compare OOP with a few other styles:

Object Oriented Programming is about keeping the contents of data in cohesive units. You make a list of things you can do with that object and still keep the unit as a cohesive whole.

Flow-based programming is all about the flow of packets from place to place. Think more about how a postal systems or package shipment systems work. Rather than operating on objects, it is about routing objects.

Then you have math-based or applicative programming, like Lisp. Instead of cohesive gobs of data you operate on, it is about math-style transformations. It is all about transforming from x to f(x), or g(f(x)), or f(x)*g(x), and all those other abstract math most people hated during middle school. Rather than operating on objects, it is about transforming, substituting and replacing objects.

Machine-based or automata-based programming is something people love in computer theory. And in AI. You aren't worried about the blobs of data, they become your alphabet. Rather than manipulating cohesive objects, it is all about states and transitions between states.

Event driven programming is common. We see it everywhere. A mouse click is an event, the system tells the program "Hey, they clicked it! Do something!".  Web pages are event driven: we say "Give me the data associated with this URL" and it replies with the data, then goes back to sleep.

Aspect-oriented programming is gaining popularity, although some see it as an extension to OOP or of event driven. It is basically thinking in terms of an upper-level executive rather than a lower-level worker. Basically everything follows the listener pattern coupled with a visitor pattern. You announce "Is it okay to do this?" at a join point, and all the listeners announce yes or no. If the listeners agree then the task is done and everybody gets a visitor pattern run on them.

It is very normal to mix and match many kinds of programming paradigms as you work.  You deal in object oriented thinking when you have a game object, say, an NPC guard. That guard internally has event driven programming (player enters line of sight), and it has automata based programming (move from idle state to alarmed state to chasing state), and so on.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

#17Starnick  Members   -  Reputation: 1711

Like
0Likes
Like

Posted 12 February 2014 - 07:43 PM

I open up a can of OOP-arse on a daily basis

Everyone has hit on it pretty well, it's one of several styles and paradigms that are ultimately just a tool in your toolbox - and having a full toolbox is what matters. Getting bent out of shape if OOP is "alive or not" is about as useless to me as talking about POCO or POJO.

(Plain Old CLR Object...omg just call them objects)

Starnick

#18Pink Horror  Members   -  Reputation: 2445

Like
6Likes
Like

Posted 12 February 2014 - 07:49 PM

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

import static java.lang.Math.*;

#19Aardvajk  Crossbones+   -  Reputation: 11242

Like
3Likes
Like

Posted 13 February 2014 - 03:45 AM

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

Its just using the class mechanism for namespacing. We certainly do have this "nonsense" in C++ - std::sin, std::cos.

#20 fir   Members   -  Reputation: -464

Like
0Likes
Like

Posted 13 February 2014 - 04:45 AM

The 'OOP' moniker covers a lot.  When I first started using C++ I was told (and naively assumed) that what I was learning was OOP.  In truth as I learned more I have found that modern C++ isn't really an OOP language.  Maybe I'm just splitting hairs here, but here's why I feel that way.  It lacks two fundamental OOP operations, virtual constructors and multi-dispatch.  These seem like minor things at first, until you start getting deep into OOP.

Virtual constructors allow you to treat an object, as truly an object.  Without being able to copy an object (due to fear of slicing, or loss of data, or change of type) a vast number of algorithms can't be performed.  There are ways around this, though usually all quite involved.

Multi-dispatch is required to truly make use of the hierarchical nature of OOP objects.  C++ does single dispatch fine, and that's what people think of when they think of OOP.  But this is such a small subsection of the set of functions that you would want to exhibit virtual behavior.  Where-as virtual constructors are something most C++ programmers are aware they are missing, and can see its use; I find that few even realize what multi-dispatch can do and why they actually might need it.

These are fundamental operations much like + or / are to arithmetic.  You can do arithmetic without say multiply, but it wouldn't be pretty.  Likewise OOP programs often have ugly hacks, or unwieldy factories/managers to get around these lack of virtual constructors.  And sadly few seem to even realize all the awesome things multi-dispatch can do, and so don't even know why they would miss it.

This is all a bit off topic, as you didn't ask about OOP in C++ specifically; but I found in my case and in many others that a programmers first impression of OOP is through C++, C#, or java (which are all quite similar).

I personally don't think C++ is an OOP language.  Templates + the stl have proven to be far more useful and powerful within the C++ paradigm (I'm not saying they are more useful in general, just with the way C++ approaches things templates are more powerful that classes IN C++).  So much so that most modern C++ is about containers + algorithms, not classes (Alexander Stepanov brought about a truly ingenious change to programming).  Its not that classes aren't used, but for the most part they are pretty structures; they store data, give it a unique and concrete type, and manage RAII.  Where-as the number of classes with virtual functions in any given project I can often count on one hand, almost every function and struct is littered with std::vector and std::fill, std::for_each and std::map.

very interesting (though i do not understand such things (as virtual constructors or multiple dispatch), but seem interesting anyways (as i said im using procedular+modular c (and im quite ok here, but dont matter))

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS