Mt4 End of support. - page 11
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
Vladimir:
Maybe to organize the interface with the user? This is where a lot of variations on the OOP are contrived, one visual component library in Delphi. So, Expert Advisors and scripts are designed to replace humans on the computer, this interface directly contradicts their purpose, it is not needed. That is, it is in the way. Just like unnecessary items in a penknife. Or a nailer on the end of the steel handle of a universal hammer - not only scratches, but also shifts the centre of gravity from the striker to the handle.
I disagree with you on this particular point.
A graphical interface may be necessary for algotraders who understand that a fully automated EA is, by far, much less effective than a semi-automated one. Combining automated and manual trading can be more professional and profitable from a trading perspective. When people realise this, their robots will definitely need an interface.
1. graph_id can be read by a Russian-speaking person faster than m_chart_id.
2. If there are hundreds of variables in a program, the Russian language provides indispensable support.
All this can be tested in an experiment.
The speed of reading and comprehending code in the native language will always be faster and the memorization will be better.
You just need to work out the rules of variable naming in Russian. Instead of "variable_to_store_general_profit_position, just: general_profit.
If there are hundreds of variables in a program, most of them can probably be combined by structures. Also, do not forget to use functions.
Many variables have no sense at all, because they are counters, temporary storages of intermediate data, and are used behind a bunch of brackets. And best of all, behind all brackets we can again use the same variables, but again in brackets {....}
Or initially write in OOP.
It seems to me that the essence of his rejection of OOP lies in this. I could be wrong of course, but I usually feel people.
In my opinion, the problem with most non-OBOs is an internal resistance to "limiting legal rights".
An old-school programmer is used to having full access to any data, any block, any program entity at any time. And OOP-approach implies the opposite - the maximum limitation of rights, when you - have access to a very small part of data and program actions.
As I remember it, I didn't like it very much. Back in the early days of Windows, I remember being highly disgusted by protected memory access - I can't access the address I like, so what if it's in the system kernel? I would like to have it read from a program or change it at all! I even programmed a direct memory access controller, which would send data to the "allowed area" from the "forbidden area", bypassing the system restrictions.
But, over time, I really appreciated all these restrictions. "Unnecessary" access can always turn into errors. So it's very wise to move the access control work - to the compiler.Restricting access here turns out to be "foolproof", not "infringement of your rights". If you need an access that you don't have, it just means that you designed the system wrong - you should have provided for it if you needed it.
And now - on the contrary, I always limit access as much as possible. At any point there should be access only to those entities which are necessary. All other entities must be inaccessible. This protects you from mistakes with access to places you shouldn't, and also accustoms you to a certain sequence of system development, where every operation is performed in one place, and no other places are affected.
For example, I hate inludes in the form of libraries, just because I don't know what they put there and how it can help me, it's easier to write a dozen more functions
similar to what I'm used to with Re-Tag Konow.
And why?
One and the same function is required in many places - why copy functions when you can have everything in the libraries, and do not clutter the main code with unnecessary blocks?
And why?
One and the same function is required in many places - why copy functions when you can have everything in libraries, and not clutter the main code with unnecessary blocks?
You're good at finding arguments, Nikolai).
Grandmother, too, can assimilate everything without any problems. She just subconsciously does not want any trinket to drag her settled mind into a cycle of unnecessary information. She's right).
Peter, so it turns out you are a grandmother.
Hello
I might be able to get some help here. I have a question for the MT4 developers. Where can it be voiced. If on this forum, in what thread? Or somewhere else? If you know, please tell me.
I disagree with you on this particular point.
A graphical interface may be necessary for algotraders who realise that a fully automated EA is, by far, much less effective than a semi-automated one. Combining automated and manual trading can be more professional and profitable from a trading perspective. When people realise this, their robots will definitely need an interface.
You fully support the person who says that mql should only have server access functions, and everything else through crutches should be programmed by third-party development tools. Don't deviate from the party line. Be consistent - dump all your developments on mql and make a bridge - in studio for example - or wherever you are going to write your canvases... Then report on your next victory over the mill.
For example, I hate inludes in the form of libraries, just because I don't know what they put there and how it can help me, it's easier to write a dozen more functions
similar to the one in Retrog Konow.
Well, the law of conservation of energy: why decompile the library and understand it if everything works without it?
P.S.
Have you seen my top about moose?
When your codes start to overflow 10, 20, 30, ... , 100 thousand lines, then come back and tell me how you copy your codes in such volume.
In my opinion, the problem with most non-OBOs is an internal resistance to "limiting legal rights".
An old-school programmer is used to having full access to any data, any block, any program entity at any time. And OOP-approach implies the opposite - the maximum limitation of rights, when you - have access to a very small part of data and program actions.
As I remember it, I didn't like it very much. Back in the early days of Windows, I remember being highly disgusted by protected memory access - I can't access the address I like, so what if it's in the system kernel? I could even want to read it from a program or change it at all! I even programmed a direct memory access controller, which would send data to the "allowed area" from the "forbidden area", bypassing the system restrictions.
But, over time, I really appreciated all these restrictions. "Unnecessary" access can always turn into errors. So it's very wise to move the access control work - to the compiler.Restricting access here turns out to be "foolproof", not "infringement of your rights". If you need an access that you don't have, it just means that you designed the system wrong - you should have provided for it if you needed it.
And now - on the contrary, I always limit access as much as possible. At any point, only the entities that need to be accessed should be available. All other objects must be inaccessible. This protects you from mistakes with access to places you shouldn't, and also accustoms you to a certain sequence of system development, where every operation is performed in one place, and no other places are affected.
You gave a good example of what OOP can repel.
In my case it was a little different. I set out to learn OOP, but at a certain stage I stopped seeing any practical benefit in using it. To this day, that hasn't changed. All because I formed my approach, which pushed OOP out of my practice.
This statement - that access limitation is a necessary protection that saves from errors - is something I cannot understand at all. If variable names coincide in different parts of the program, of course yes. But if there is common global memory of all the main global variables in one array, you don't need restrictions and there will be no confusion.