Record on the Market - page 31
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Probably because I don't work for a company. And I find it easier to use procedural programming rather than OOP.
There's been a lot of debate on this, of course.
Well, just in the last week I've been doing some modifying of the trading quality estimation algorithm for my TS League. And I'm very glad that everything is based on virtual interfaces.
The point is that before the maximum drawdown was estimated only by balance. And I wanted to estimate it by Equity. But to do this, when analyzing the history - for each transaction it is necessary to request the time series, and see what the maximal drawdown of the transaction was, based on the then prices.
Now remember, that my code is portable, it means that based on the same interface - both MT4 and MT5 work. Accordingly, for each platform - calls the appropriate class with its own functions, which are noticeably different. So, while I was modifying the code - probably a dozen of times I was in a situation, when I wasn't able to directly access the required data - the interfaces didn't allow it. And each time I made sure that I was correct, that the interfaces had restricted me - if I had "tapped" into this data directly - it would have led to errors in other parts of the program. The data I needed, I had to access in a different way, through additional queries, which allowed me to be sure that no other parts were affected.
In summary: once again I'm convinced that the principle "in each place the user must have access only to those structures that he needs at the moment and no others" is absolutely correct. You can't allow the user to always have access to everything - it's fraught with modification errors.
But on the other hand - people who are used to a procedural style - simply limit themselves in such cases by remembering which data can be changed from a given location and which cannot.
Well, just in the last week I've been doing some modifications to the trading quality evaluation algorithm for my League TS. And I am very glad that everything is based on virtual interfaces.
The point is that before the maximum drawdown was estimated only by balance. And I wanted to estimate it by Equity. But to do this, when analyzing the history - for each transaction it is necessary to request the time series, and see what the maximal drawdown of the transaction was, based on the then prices.
Now remember, that my code is portable, it means that based on the same interface - both MT4 and MT5 work. Accordingly, for each platform - calls the appropriate class with its own functions, which are noticeably different. So, while I was modifying the code - probably a dozen of times I was in a situation, when I wasn't able to directly access the required data - the interfaces didn't allow it. And each time I made sure that I was correct, that the interfaces had limited me - if I had "messed" with that data directly - it would have caused errors in other parts of the program. The data I needed, I had to access in a different way, through additional queries, which allowed me to be sure that no other parts were affected.
In summary: once again I'm convinced that the principle "in each place the user must have access only to those structures that he needs at the moment and no others" is absolutely correct. You must not let the user always have access to everything he/she needs - it might cause modification errors.
But, on the other hand - people used to the procedural style - just limit themselves in such cases by remembering what data can and cannot be changed from the given place.
Well, that's the competition. It can't be helped. Just don't give up. Keep moving forward and win. Otherwise, you'll be left behind.
Forget about the PLO. If this question bothers you, I can tell you that in programming you must use only what you can do without. If you can do with procedural style - do that.
My principle:"If you can do without something in solving a task, you should definitely do without it".
Does the dog need a fifth leg? :)
Exactly.
That's the kind of competition you need.
You'd be surprised, but I still suffer from procedural programming.
I got into Pascal when I was 14 and I can't change myself. And I "learned the classes" a long time ago, but I can't change my mind...
Probably because I don't work for a company. And I find it easier to use procedural programming rather than OOP.
OOP principles do not differ much from procedural programming, the more so in MQL-programs the tasks are highly specialized and there is often no point in developing the internal structure of a class. More than 90% of examples using classes in Codobase are no more than "wrapped in class" procedural programming, because tasks that are solved by a class are performed only once and inheritance and polymorphism are not used (because there is no need).
And serious problems, where there is no way without OOP - it is a graphic. This problem has already been solved and it is in the free access and you just need to know how to use or modify it (like inheritance).
They have already done it and it is freely available, it's just a matter of knowing how to use it (graphics in MQL) or how to inherit it (how to use inheritance).
ZZZY: that's what I will not say about usability in terms of ALGLIB - it certainly should be "wrapped" in a normal class!
Igor Makanu:
...
And serious tasks where you can't do without OOP are graphics...
Very controversial.))
Very controversial.))
The principles of OOP do not differ much from procedural programming, especially in MQL-programs the tasks are highly specialised and there is often no point in developing the internal structure of a class. Over 90% of examples using classes in Codobase are no more than "wrapped in class" procedural programming, because tasks that are solved by a class are performed only once and inheritance and polymorphism are not used (because there is no need).
And serious problems, where there is no way without OOP - it is a graphic. This problem has already been solved and it is in the free access and you just need to know how to use or modify it (like inheritance).
They have already done it and it is freely available, it's just a matter of knowing how to use it (graphics in MQL) or how to inherit it (how to use inheritance).
ZZZY: that's what I will not say about usability in terms of ALGLIB - it certainly should be "wrapped" in a normal class!
It depends what for.
For ease of use by other users?
Possibly, yes.
So that the users don't have an urge to "mess around" and cause any harm.
I use 5 drawing functions for my graphics (text, button, checkbox, field, background) !)
Everything is clear to me. Others don't need to see it.
Exactly.
That is the kind of competition we need.
I dream that such competition would grow in our Market. Only the Market needs to be cleaned up.
In order to perfect swimming, the pool needs to be cleaned first and then filled with water. In short, the right conditions are needed.
If the pool is dirty, no one will want to compete. :)Well, just in the last week I've been doing some modifications to the trading quality evaluation algorithm for my League TS. And I am very glad that everything is based on virtual interfaces.
The point is that before the maximum drawdown was estimated only by balance. And I wanted to estimate it by Equity. But to do this, when analyzing the history - for each transaction it is necessary to request the time series, and see what the maximal drawdown of the transaction was, based on the then prices.
Now remember, that my code is portable, it means that based on the same interface - both MT4 and MT5 work. Accordingly, for each platform - calls the appropriate class with its own functions, which are noticeably different. So, while I was modifying the code - probably a dozen of times I was in a situation, when I wasn't able to directly access the required data - the interfaces didn't allow it. And each time I made sure that I was correct, that the interfaces had restricted me - if I had "tapped" into this data directly - it would have led to errors in other parts of the program. The data I needed, I had to access in a different way, through additional queries, which allowed me to be sure that no other parts were affected.
In summary: once again I'm convinced that the principle "in each place the user must have access only to those structures that he needs at the moment and no others" is absolutely correct. You must not let the user always have access to everything he needs - it may cause modification errors.
But, on the other hand - people who are used to a procedural style - simply limit themselves in such cases, remembering which data can be changed from a given place and which cannot.
With all due respect, but your arguments are like those of a very old man explaining and proving the necessity of the stick he is leaning on. They say that without it I will surely fall down. That's true. But not for everyone.
Very controversial.))
Maybe, but I'm also a "dinosaur from the late 90's" I saw Turbo Pascal and the rudiments of graphics in the form of libraries which no matter how you spin it - you still get Norton Commander ))))
But with the advent (and my transition) to Delphi, as they say, that's where life just started.... I can't imagine how to make active windows, checkboxes, etc. without OOP, I guess in theory, but I don't even see how it can be done without OOP, as they say you get used to a good thing!
With all due respect, but your arguments are like those of a very old man explaining and proving the necessity of the stick he is leaning on. Without it, I'm bound to fall over. That's true. But not for everyone.
You, as I recall, remember perfectly well everything that lies in your enormous data set. I, on the other hand, did not remember such things even when I was young. Now, when I am an old man, I certainly cannot remember everything I meant when I wrote a certain block. This "stick" really helps me a lot. But, I agree that if someone is able to retain everything necessary in his memory, he can do without it.
Nevertheless, I've cited respected fxsaber's code several times already, where he himself couldn't tell me exactly how it works. It's just that it has very tricky and non-obvious checks which are indeed difficult to remember. And the man doesn't remember. The consensus was that "this code has been checked many times, so it can be trusted". But what will happen if some working protocols change? The code immediately becomes invalid, and in this case - instead of correcting what has changed - it will have to be re-examined until this very changed place is found.
This is what these "sticks" are for. Software products today are so complicated that it is unrealistic to keep in mind all their intricacies. This is why various techniques are used (OOP is only one of them).