Discussion of article "MQL as a Markup Tool for the Graphical Interface of MQL Programs. Part 1" - page 2

New comment
 
Алексей Мокрушин:
...
No-one was "shitting". Personally, I expressed a reasonable opinion that the author did not set out clear principles of markup language structure, because he does not know them. The article has a lot of general words on the one hand, and unnecessary details (like a game of spotting) on the other. The author doesn't understand the concept of markup language yet and thinks that an ordinary library can be converted into it. We are waiting for the moment when he will describe the implementation plan.

Personally, I have the right to criticise because I created the markup language and I can see well when "water is "pouring" and when things are getting done. There is no concept in this article, but there is an attempt to formulate one. We'll see what comes next...

The best description of the article is that the author "turned on" the stream of consciousness, and tries to reason how we could try to approach the implementation. Actually, he writes it himself in the article (testing the realisability of the "POC" concept).
 
I would say that a markup language (no matter what technology it is created in) is a set of commands, c.words, rules and syntax over graphical functionality serving controls. That is, theoretically, graphical library can be wrapped in a language with simplified syntax and easy construction of graphical constructions, speeding up the process of GUI description for the user and saving his efforts, but don't forget what it takes:
1. Invent a language with rules and syntax.
2. Write an interpreter that translates the code of the "language" into MQL code, i.e. a wrapper (writing markup) into library calls of the corresponding functionality.

Behind this is the creation of a special engine, the device of which should be well understood in advance.

 
Алексей Мокрушин:
...since mql doesn't have delegates, I had to figure out what this dish is and what it's eaten with. I had to rewrite all the standard classes. I started from the beginning, with CObject. In the end I wrote a simple implementation of OnTradeTransaction, OnChartEvent, OnTimer events processing with the help of "real" OOP....

.

 
Dmitry Fedoseev:

.

hand on heart - CObject and"Standard Library" are still a legacy of the 90's :-))

until there will be a similar STL that does not require additional attributes from instances and/or the presence of "adam" (grand class/common ancestor) there will be significant problems - the visible part of which is the amount of application programs code. They're fucking huge....

 
Maxim Kuznetsov:

Hand on heart - CObject and"Standard Library" are a legacy of the 90's :-)

until there will be a similar STL that does not require additional attributes from instances and/or the presence of "adam" (grand class/common ancestor) there will be significant problems - the visible part of which is the amount of application programs code. They're fucking huge....

CObject is not the point here. OOP != Patterns, don't confuse where the power of patterns is used and where the power of OOP is used. There is no special need for OOP, and even less for templates, when writing expresso, and certainly not for creating an analogue of a delegate using OOP while there are pointers to functions.

As sad as it is, the joke about "C++ victims club" is becoming a reality. It is strange that people pile a lot of all sorts of fiddles on themselves and consider it cool coding. But in fact, a modern programmer has degenerated into a library plugger.
 
Dmitry Fedoseev:

CObject is not the main thing here. OOP != Templates, don't confuse where the power of templates is used and where the power of OOP is used. There is no special need for OOP, much less templates, in expresso-writing, much less creating an analogue of a delegate using OOP while there are pointers to functions.

As sad as it is, the joke about "C++ victims club" is becoming a reality. It is strange that people pile a lot of all sorts of fiddles on themselves and consider it cool coding. But in fact, a modern programmer has degenerated into a library plugger.

"what's the power, brother?"

library pluggers should rule. It's actually right when it reduces code size and development time.

PS/ so far all published articles (and their developments, which is more important) are the antithesis of programming - they do not increase efficiency.

 
Maxim Kuznetsov:

"what's the power, brother?"

library_plugins should rule. It's actually the right thing to do when it reduces code size and development time.

PS/ so far all published articles (and their developments, which is more important) are the antithesis of programming - they do not increase efficiency.

Power is in knowledge, and articles just give knowledge and nothing else they should give. Increasing efficiency is a personal matter for everyone. Increasing the efficiency of programming is certainly good, but not when it makes the user of the programme less comfortable.

 
Dmitry Fedoseev:

... In fact, the modern programmer has degenerated into a library plugger.

Soon he will disappear altogether, as it will be possible to build "objects" (named groups of parameters with predefined links) intuitively and without higher education, with the support of "intellectually developed" IDE, which will "understand" the essence of the logical structure being built from "half a word". The environment will wise up and the era of specialised programmers and diversity of languages will come to an end. Everyone will be able to build algorithms by reading the instructions to the programme. A natural process, nothing to worry about..... It's strange that it didn't start earlier, but instead languages repeating one concept in different ways have proliferated.

 

There will be no XML. The whole point is to do without MQL. The goal is to make an MVP-level markup system "native" to MQL - no frills, but functional and extensible enough for those who need it. It will be possible not to go into the internal structure. It's just usually better to have a description of the concept and device than not to have one.

I'm not crazy about the standard library either, but there's not a lot of choice, so it's (for now) the best compromise between those few very small and super fancy libraries that have big questions anyway.

The supposed luminaries in programming and GUI creation who have declared themselves as such on the basis of naive crafts are recommended to demonstrate their hat-trickery in their own threads.

 
Stanislav Korotky:

...

Imaginary luminaries in programming and GUI creation who declared themselves as such on the basis of naive crafts are recommended to demonstrate their hat-trickery in their own threads.

Bingo.

123456
New comment