Beta version of MetaTrader 4 IDE including new MQL4 compiler and editor - page 5
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
It's probably hard to find a more petty suggestion for optimisation, but maybe it's time to organise the output of the Market Overview list alphabetically after all? Or is it the engineer in me saying that everything should be parallel/perpendicular... Kinda not stressful, but not happy either. Maybe you could add a couple more lines to those 90% ready-made functions, eh?
Question : When is the new mt ??? Can't wait .....
What exactly are you waiting for? New bugs? (which is inevitable with such major changes). Are you itching to rewrite and debug all your codes that won't work in a moment? Don't you have free time to waste?
Personally, all this mess with recent builds has made me think globally about the prospects for such MQL-programming. And it doesn't matter if it's on 4 or 5. The essence is the same. You write your programs in a certain synthetic language that is tied to a trading platform, and eventually you become a hostage of all whims and errors of this platform / language developers. Today they want to cross MQL4 with MQL5, tomorrow with MQL6, etc. And you have no choice, you are forced to redesign your developments according to new rules. Otherwise, everything will stop working. And so it goes on and on. It's all not serious.
In general, this was the final push for me to transfer all my MQL programs into an independent programming environment without binding to a specific trading platform. And I will use MQL just as a connecting link between MT and my program. And this is probably the only right way. Unless you are going to sell your developments on the Market, of course).
Well, if you just like to program in MQL and want some new features (i.e. sporting interest), then what prevents you from coding in P5, where all this is already implemented?
What exactly are you waiting for? More bugs? (which is inevitable with such major changes). Are you itching to rewrite and debug all your codes that won't work in a heartbeat? Don't you have free time to waste?
Personally, all this mess with recent builds has made me think globally about the prospects for such MQL-programming. And it doesn't matter if it's on 4 or 5. The essence is the same. You write your programs in a certain synthetic language that is tied to a trading platform, and eventually you become a hostage of all whims and errors of the platform / language developers. Today they want to cross MQL4 with MQL5, tomorrow with MQL6, etc. And you have no choice, you are forced to redesign your developments according to new rules. Otherwise, everything will stop working. And so it goes on and on. It's all not serious.
In general, this was the final push for me to transfer all my MQL programs into an independent programming environment without binding to a specific trading platform. And I will use MQL just as a connecting link between MT and my program. And this is probably the only right way. Unless you are going to sell your developments on the Market, of course).
Well, if you just like to program in MQL and want some new features (i.e. sporting interest), then what prevents you from coding in P5, where all this is already implemented?
I agree, if the developer would leave support for old builds, at least 500 and removed compulsory upgrade to a new build, which I suspect will be implemented, it would be ok, but it's another incomprehensible move developers. Of course, I support the inclusion of OOP, but it is easily implemented in a dll and there is no need to start a fire with a new version of the language as the new standard. For example, the same C++, they have several existing standards, but in general there is a common ground that will work for any code implementation.
I have a suspicion you're ironing with cast iron irons and heating the cooker with coal ... Innovations are good, not only the currency market is very dynamic and you must always be in the trend if you want to achieve something ... new changes for the better, hopefully ....
Innovations are good, not only the currency market is very dynamic and you must always be in the trend if you want to achieve something ... new changes for the better, hopefully ....
It is one thing to be "on trend" yourself, but it is another thing to have your past designs become "on trend". If you don't have a lot of them or they are of no value, then no problem. But many people here have accumulated a huge code base, written and debugged over years. And now everyone is being put before the fact that a considerable part of this code will soon stop working. This is nonsense. In such cases, backward compatibility, i.e. support of older versions of the language is always envisaged, but the meta-quotes don't do that.
It is one thing to be "on trend" yourself, but it is another thing to have your past designs become "on trend". If you don't have a lot of them or they are of no value, then no problem. But many people here have accumulated a huge code base, written and debugged over years. And now everyone is being put before the fact that a considerable part of this code will soon stop working. This is nonsense. In cases like this, backwards compatibility is always envisaged, i.e. support for older versions of the language, but the meta-quotes do not do that.
Are you sure about it ? Is this an insider ?
It is one thing to be "on trend" yourself, but it is another thing to have your past designs become "on trend". If you don't have a lot of them or they are of no value, then no problem. But many people here have accumulated a huge code base, written and debugged over years. And now everyone is being put before the fact that a considerable part of this code will soon stop working. This is nonsense. In cases like this, backwards compatibility is always envisaged, i.e. support for older versions of the language, but the meta-quotes do not do that.
Are you sure about this? Is this an insider ?
The words of an alarmist. The metaquotes have said many times and probably won't get tired of repeating that there will be full compatibility. Will you stop with the childishness already?
Here I highlighted it, so that no one would say it is fully compatible:
What are the differences from the old version of MQL4:
The priority of boolean AND/OR operations has changed. Now everything is as in classic C/C++
A shortened evaluation of logical expressions has been introduced. Now, when evaluating a logical expression, the remaining subexpressions are not evaluated. As in C/C++.
The switch operator now uses only integer values. Previously, you could use real ones.
Now, you cannot use a full stop in variable names. Also, you cannot use the '@', '$', '?' characters in variable names.
The requirements to the start function have been tightened. Previously, you could specify parameters in the start function. Now all the entry points init, start, deinit, OnInit, OnStart, OnTick, OnTimer, etc. must exactly match their signatures
Due to the expansion of the keyword set, names such as short, long, float, const, virtual, input, delete, new, do, char cannot be used anymore.
Imported dll-functions can no longer accept arrays of strings as a parameter. As in MQL5
The differences are not fatal, and can easily be fixed in the code. Instead, a lot of features of MQL5, a faster execution speed and a much tighter quality control are available.
I, of course, support the inclusion of OOP, but it is implemented in a dll and there is no need to create a new version of the language as a new standard.
I don't think anything should have changed in Mql4 at all. It has existed unchanged for many years, all the ills have been cured and users got used to it. The main thing is that it was a very simple and unique language with its own features, for example, allowed some free will, which could save many lines of code. The only thing it really lacked was structures. You could have limited yourself to adding them, and that's all. And MQL5, with its boring severity and limitations, is not so interesting any more, because, as Barbarian rightly pointed out, it's much easier to code in real C++ with much wider possibilities.
In short, the best solution would be to leave MQL4 as it is and add MQL5 as a separate language in MT4 (only the set of features will be different from MT5). The user would decide for himself which language to write in.