Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 44
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
In a word, you want to simplify the life of ordinary users. We want it to be easy, without any codes - we've touched this subject somewhere inthe FAQ.
Come on, what's there not to like, there is a Wizard, when it was announced they also shouted that they would not like it, well, Jobs did not go bankrupt, there are even signals appeared, and do not go bankrupt either. You'll be fine if you write it.
You could even discuss the model on the forum, I think the enthusiasts will show up.
I apologise for not having read the whole thread, but only pages 1 to 7 and 41 to 42 were enough for me. I'm sorry, I haven't read the whole branch, I've read only pages 1, 7, 41, 42 and I feel I have to put my opinion in it. I am using MT4 & MQL4 since the time everyone started to trade MT3. The main thing that attracted me to MQL4 was the simplicity/functionality ratio that was much better than all the competitors. In my opinion, this was its main advantage. And MQL4 has changed drastically over all this time, after such news it's hard to imagine what kind of a beast it will become. But it won't get more complicated. Since the more complex MQL4 becomes, the larger is the field of activity for the programmer, not for the trader! And thus MQL does not cover its potential audience in full, or maybe even a smaller one.
MetaDriver:
.........
So why not discuss the options of the future, even if distant (like MT6) ? Why are you looking for malice in these discussions for nothing? You'd better get involved.
.........
And on the above, I have an idea-proposal for developers. To preserve flexibility and functionality and at the same time make new MQL-X easy to understand for brains. The new MQL as a constructor of trading strategies, first of all, as a system of visual designing and development of strategies which does not require knowledge of programming languages and functionality of the trading terminal and which enables quick and easy writing (drawing) of complex trading strategies. HiAsm is a good example. Of course, HiAsm is intended for writing general purpose user programs. This is just one of many similar graphical C++ implementations. So, if MQL is very similar to C++ and is object-oriented, why not make it as a graphical constructor. With the help of which the probability of syntax errors and time spent on poking around when writing the source code of the Expert Advisor can be significantly reduced.
I would like to hear everyone's opinion on my proposed idea, I am especially interested in opinion of developers....
Come on, what's there not to like, there is a Wizard, when it was announced they also shouted that they would not like it, well, Jobs did not go bankrupt, there are even signals appeared, and do not go bankrupt either. They are not going to ruin either, even the signals have appeared.
You can even discuss the model on the forum, I think the enthusiasts will show up.
If they could do it in Metratrader like they do here, there would be no work for programmers (and if they had to pay for it, they would have a chance to earn money for the masses).
A visual constructor is needed, like in Tissilab, for example, to use both cubes and code, where to outline a framework, then with cubes, then with custom code. Such solutions have future, and not because of laziness of coding, but because of banal advantages in modeling speed. It happened with digital graphics and so will happen with all semi-empirical process modeling, where you have to "draw" the logic and experiment with multi-level structures.
Service work can not suffer from this, suffer quite a low layer of templators, well it serves them right, in general, what to be sad about those who work for less than $5 per hour, they chose such a fate ... Those who implement large projects on the contrary will rejoice at the acceleration of routine operations.
Visual constructor is needed, like in Tissilab, for example, both cubes and code, where to outline a framework, then with cubes, then with custom code. Such solutions have future, and not because of laziness of coding, but because of banal advantages in modeling speed. It happened with digital graphics and so will happen with all semi-empirical process modeling, where you have to "draw" the logic and experiment with multi-level structures.
Service work can not suffer from this, suffer quite low layer of templators, well it serves them right, in general, what sorrow those who work for less than $ 5 per hour, they chose such a fate ... Those who implement large projects on the contrary will rejoice in accelerating routine operations.
Your words are a blessing in disguise. I'm very glad at least one person understood what I tried to put forward.
FAQ, 2013.08.10 00:34
I just keep thinking, what's the purpose of your persistent advertising of the unknown? Why don't you take a bath for a couple of weeks?I'm not advertising anything here. I just gave an example, that would be evident.
The very concept of programming - writing text as commands or commands as text - is hopelessly outdated. This is only because it is a very tedious task which is very time-consuming.
Those who are at least a little bit familiar with programming, and professional programmers even more so, know what an algorithm is and how the icons of the basic elements of the algorithm look like. And now imagine how simple it would be, for example: We can easily place different (necessary) icons on a clean space in the middle of the working area (not on a chart of trade instrument quotes, but in the Source Code Editor) using Drag&Drop method. After that, connect the necessary points of the icons-figures with lines of logical links. As a result, the source code will look like a motherboard with chips, semiconductors and other elements connected by tracks. We then click the compile button in this editor, and the EA is ready!
Imagine how fast and easy it will be to compile the source code for a trading EA. When compiling it, you won't have to worry your brain about syntax compliance. This concept allows us to focus 100% on the implementation of a trading strategy. And this very concept allows making programs even more complex and flexible.
I know about Wizard MQL5 (usual pattern wizard) and Mykibo (usual expert with control of orders based on the relative positioning of graphical elements on a chart of trade instrument quotes) - THIS IS NOT IT!
There is no need to send me a wash. I offered a normal bright idea.
This, of course, is a joke coming from your mouth. Because storing these two spreads will not affect the accuracy as much as storing only HighBid and LowAsk.
no)) simply instead of the spread at the opening or average spread store the spread at the time Low bar is formed. I.e. Low_Ask - Low_Bid=Spread_Low. Then Low_Bid+Spread_Low=Low_Ask )))
I.e. change the rule of collecting bars from ticks (spread calculation) without changing anything in the data structure.
Logically, I think I need asc for HighBid and bid for LowAsk. Or we should rewrite logic, but not too much, then it will be a little bit pessimized version of real. It may work.
no)) simply instead of the spread at the opening or average spread store the spread at the time Low bar is formed. I.e. Low_Ask - Low_Bid=Spread_Low. Then Low_Bid+Spread_Low=Low_Ask )))
I.e. change the rule of collecting bars from ticks (spread calculation) without changing anything in the data structure.
Once such solutions also caused a storm of excitement, (I encountered it at work, and in trading with it). But ... I don't even know why, but it didn't work. The code has more freedom, or something like that. The visualization is of course clearer. But often the code is just two lines long, while in this visualizer it ends up in a heap of components. Again, custom components run into some architectural restrictions (they must fit into standard component model).
The main reason for this is, of course, laziness. For zeros it is laziness, for those who are good programmers it is surplus shit-code from code generators. Although the idea is appealing. On the technical side we need good asynchronous support and declarative programming style features on the lower level (this is my opinion).