Why generic programming is more natural than OOP?
2 january 2014 by Issam Lahlali
As Bjarne Stroustrup points out, "C++ is a multi-paradigmed language." It supports many different styles of programs, or paradigms, and object-oriented programming is only one of these. Some of the others are structured programming, and generic programming. In the last few years C++ gurus like Andrei Alexandrescu, Scott Meyers and Herb Sutter promotes the uses of the generic programming and they qualify it as Modern C++ Design.And as the author of this interesting article explains, there's a tension beteween the generic programming and OOP. And here's from the article the opnion of Alexander Stepanov the inventor of the STL about OOP:
"I find OOP technically unsound."
"I find OOP philosophically unsound."
"I find OOP methodologically wrong."
"I have yet to see an interesting piece of code that comes from these OO people."
"I think that object orientedness is almost as much of a hoax as artificial intelligence."
But it's still just an opinion and many other C++ gurus will not be agreed. And to try explaining the difference between these two paradigms, we will discuss a fundamental difference between generic programming and OOP.
Let's begin with this story:
Three people TaxExpert, OOPMen, and GenericMen met at a party. The following conversation begin between them.
TaxExpert: I'm a Tax specialist and I spend many years in this domain.
OOPMen : That's great, I need to calculate the Tax tha I have to pay.
TaxExpert: No problem , I can help you what's exactly your situation?
OOPMen: Thanks, however are you graduated from cambridge?
TaxeExpert: No.
OOPMen: Sorry you can't help me.
TaxExpert: I have to be gradueted from cambridge to know how to calculate the Tax?
OOPMen: No , but I trust only the expertise of people graduated from cambridge.
TaxExpert: But it's compeletly unsound, and it's like you adhere to a caste system.
GenericMen: I have the same problem, I have to calculate the TVA I have to pay.
TaxExpert: did you want to know who I'm? before continuing the discussion?
GenericMen: No, but I want to know if you are able to calculate the Tax in case of an LLC company.
TaxExpert: Yes I can, give me more details about your case.
The TaxExpert calculate the Tax for the GenericMen, and he said to OOPMen:
"What's important is not who you are, but What you can do"
If you participate at such discussion, maybe your first remark will be:
OOPMen is abnormal, why he needs to know where TaxExpert comes from?
However in the programming world we have the same situation and many developers use the OOP without saying:
It's abnormal, why the OOP adhere to a cast system?
And to be more concrete let's discuss this pseudo code
class OOPMen
{
TaxExpert* expert;
public:
float calculateTax(...)
{
return expert->calculate(...);
}
}
OOPMen could collaborates only with classes of TaxExpert kind, and even another class with no inheritence relation with TaxExpert could calculates the Tax, it couldn't be used.
And concerning this template class:
template < typename TaxExpert>
class GenericMen
{
float calculateTax(...)
{
TaxExpert* expert=new TaxExpert();
return expert->calculate(...);
}
}
The GenericMen class is not aware about the TaxExpert kind, but if the TaxExpert could calculate the Tax.
It's true that in OOP we can define an abstract class defining a contract, and let many classes implemeting it, but in the final we need absolutely to ask the question: who you are? are you an IMyContract kind?
We can say that the OOPMen class adhere to a caste system, and it can explain why the cast (dynamic_cast, static_cast, reinterpret_cast) are overused in the OOP projects.
Why OOP still popular?
Generic programming sound more natural and flexible, and it can provides more possibilities than OOP, however many developers found it very complex and difficult to learn and use.
- The code became illisible and hard to maintain.
- The compiler errors are very hard to understand.
And the OOPMen would say: I prefer to adhere to a cast system rather than a chaos system.
Fortunately the C++ designers are aware of these issues, for this reason many improvement are added to template programming in the new C++ standards, for example a new interesting feature "Concept-lite" is planed for the next C++14 to let define constraints for the template params.
Back to the first discussion, which became more philosophical:
TaxExpert: OOPMen you are not sociable, and this behavior is not suitable for you. GenericMen accepted my help and now he has what he want.
An another person DynamicLanguageMen(DLMen) who listen to the entire discussion join them:
DLMen:I'm the most social one, I will not ask you first who you are or even what you can do, I could help until I can't do it, and after it's up to you to decide what to do.
GenericMen: But it's very risky, suppose that I spend with you one hour and after I discover that you can't do some operation, in this case I will waste my times and yours, and worse than that, I have to back for some operations.
DLMen: Yes, this risk exist, but it's the price to pay for my amazing social behavior:)
To be more concrete let's discuss this following javascript code
function calculate(a)
{
a.operation1();
a.operation2();
a.operation3();
a.operation4();
}
calculate (new MyExpert);
This code is not aware first who the param a is, or even it could do all the oprations needed, but in the runtime it checks if MyExpert could do some operation or not.
With the generic programing , these requirements are checked in the compilation step, which makes the code more safe, and it's more natural to know first if a class could do some operations or not.
Generic programming could also have the advantages of dynamic languages, however it must be simplified, and we hope that the new C++ standards make the generic programming more easy to use and understand than now.
