With small scale projects you can show that any problem can be broken down into procedural code. However things get a lot harder when you have multi million line code bases with teams of 100+ developers, several Business analysts and architects all wanting to make modifications to the "model" concurrently. Under these circumstances the "business" model is generally defined in a design tool like UML and is accessible to the entire team.
The business model alone contains 5000+ classes. From this business model there are tools that "generate" classes for the object model, the SQL interfaces, and the network layers taking the baseline class count to 15,000 classes.
For this discussion Id like to break down the procedural vs OOP argument into three "extensions" that have been added to procedural since the 1960/1970's
1) "Object Based" this is where objects and code are encapsulated to make an advanced "structures" that can also have behaviours
2) "Class based" this is where Objects can inherit from one another and be arranged in hierarchies
3) "Object oriented" this is where the user can define "polymorphic" behaviours (virtual methods or interfaces) within the class hierarchies
There is an argument that all the above can be implemented in procedural languages with enough effort, for instance most GUI toolkits in the 80/90's were created in c and had these features, but they are not easy to implement by the casual coder and are not really applicable to this discussion.
So to answer the question, can we implement a multi million line project with 100+ developers without using the 3 OOP features?
My personal opinion is it is virtually impossible to deliver a large scale project without 1) and 2) because without a "class based" system it is so hard to map the real world data structures and behaviours into code in a clean and concise manner. And more to the point as your project size scales, what starts as a "we can implement that in c" becomes a endless list of methods with less structure that become harder to maintain.
Now languages that deliver just 1) and 2) are not fully OOP languages. So we should consider if "polymorphic (virtual) methods" are really necessary. This is a bit more of a "maybe", or "sometimes" because polymorphism isn't always the correct tool to solve a problem and can overcomplicate the design. For instance when modelling some data structures that map to an object store or SQL database adding virtual behaviours can make the data mapping more difficult, however when defining extensible toolkits or API's using an "interface" or base class with "virtual methods" is invaluable. Overall I'm a huge fan of polymorphism when used sparingly and in the right context.
I've worked on a few multi-million line "C" codebases and several more multi-million line C++/Java/C# codebases, and most of the "C" codebases decline into "maintenance mode" after 5 years because the developers are afraid to change the architecture as the code is just too fragile and modifications often cause months of painful redevelopment and testing. In general Object Oriented projects are much more resilient to modification and refactoring.
if...then...else is not capable of coding "virtual" methods.
There are several implementations of "polymorphism" in "C" and most of them use vectors of function pointers to hold the necessary mappings. More to the point these "vectors of function pointers" need to be defined for each "type" you want to model in the "hierarchy". Of course "C" doesn't support hierarchies directly so you'll have to solve that issue too.
If you really want to get into the bag of worms that is "virtual" methods implemented in "C" then you can dig out the X Windows toolkits that are freely available in every Linux distribution.
Windows of course has to be slightly different and it uses extensible structures with integer message ids. This means the "polymorphic" behaviour is implemented via switch statements on the ids. (probably the dirtiest way of doing it, but it will get you there)
Do you agree that Windows operating system is offering a good GUI ? As far as I know it's written in C. Procedural language not OOP.
You are wrong Dirk if you think a complex program could only be build with OOP. You should rather explain why it's better to code it with OOP.
Windows Kernel is in "C" but the Kernel is only a small component of Windows codebase and much of the higher level codebase is implemented in C++ with "C" style external interfaces to support multiple languages.
Even the legacy windows GUI components implement their own hand rolled "polymorphic behaviour" that are effectively "OOP" implemented in "C". For instance when you get a "Handle" back from a GUI control you are getting an extensible "C" structure with polymorphic behaviour available, this is OOP just wrapped in an ugly set of "C" syntax.
Saying Windows in not OOP because it is written in "C" is not totally accurate.
I will not build a GUI in procedural language to prove you are wrong. But I could without any doubt.
By the way it's also easy to code unreadable and much slower code in OOP, and as you know the Metaquotes Standard Library is a good proof of this.
OOP being much slower than procedural code is a complete myth. The reason many OOP projects are slower is because they are poorly designed. The overhead for a virtual function call is far smaller than you would expect, especially with todays on chip memory fetch architectures that can look up and execute in parallel.
Quote from the link above: "But the cost of a call, whatever the flavor, is dominated by the evaluation of its arguments. We saw that indirect calls, whether C-style or C++ virtual methods, are inherently inexpensive. A call to a virtual method is not any more expensive than an indirect call using a struct member (something->function(arg1,arg2)) so deeming virtual function as incredibly slow is just misinformed."
Java can be a lot slower than C++ because every piece of encapsulated data must itself be a heap based class so you do get a lot more object dereferencing. However even Java can be exactly the same speed as C in loops and basic math operations.
If you compare C with C# it's really quite difficult to write some code that is significantly faster in C vs C#, even when you include some of the OOP features.
If the Metaquotes standard library is slow then it will be 90% due to the design of the library features and have very little to do with the OOP features used.
(As a comparison the C++ Standard Template Library out performs 95% of any C project ever written )
Thank you for your great contribution.
No worries I have to play my role as "moderator"
Sure, would be nice to see some examples of whatever it is you people are talking about. Talk/typing is all well and good for people who have experience in all this, but I am a visual hands on type of student, please post examples.
I am on the fence as to whether or not I am going to continue learning mql4, switch to mql5 or just go with another platform.
Thanks Alain for starting this thread. This forum really needs this.
Do you really expect someone professional is posting a compex library, just like that as a "proof"? ;) I could post you a link to something ready which cannot be sold at the market here, but Alain is gonna kick me if I did ;) You may visit my profile ans take a look at the wall picture to get an idea or drop me a pm.
Another platform? You will not find any other platform with such a powerful compiler. Not at all.
@James Cater - thanx a lot for your comments.