Discussão do artigo "Linguagem MQL como um meio de marcação da interface gráfica de programas MQL. Parte 1" - página 2

 
Алексей Мокрушин:
...
Ninguém estava "cagando". Pessoalmente, expressei uma opinião razoável de que o autor não estabeleceu princípios claros de estrutura de linguagem de marcação porque não os conhece. O artigo contém muitas palavras genéricas, por um lado, e detalhes desnecessários (como um jogo de localização), por outro. O autor ainda não entende o conceito de linguagem de marcação e acha que uma biblioteca comum pode ser convertida nela. Estamos aguardando o momento em que ele descreverá o plano de implementação.

Pessoalmente, tenho o direito de criticar porque criei a linguagem de marcação e posso ver bem quando "a água está "derramando" e quando as coisas estão sendo feitas". Não há nenhum conceito neste artigo, mas há uma tentativa de formular um. Veremos o que vem a seguir...

A melhor descrição do artigo é que o autor "ativou" o fluxo de consciência e tenta raciocinar como poderíamos tentar abordar a implementação. Na verdade, ele mesmo escreve isso no artigo (testando a viabilidade do conceito de "POC").
 
Eu diria que uma linguagem de marcação (independentemente da tecnologia em que foi criada) é um conjunto de comandos, palavras-chave, regras e sintaxe sobre a funcionalidade gráfica que serve os controles. Ou seja, teoricamente, a biblioteca gráfica pode ser envolvida em uma linguagem com sintaxe simplificada e fácil construção de construções gráficas, acelerando o processo de descrição da GUI para o usuário e poupando seus esforços, mas não se esqueça do que é necessário:
1. Inventar uma linguagem com regras e sintaxe.
2. Escrever um interpretador que traduza o código da "linguagem" em código MQL, ou seja, um wrapper (marcação de escrita) em chamadas de biblioteca da funcionalidade correspondente.

Por trás disso está a criação de um mecanismo especial, cujo dispositivo deve ser bem compreendido com antecedência.

 
Алексей Мокрушин:
...como o mql não tem delegados, tive que descobrir o que é esse prato e com o que ele é consumido. Tive que reescrever todas as classes padrão. Comecei do início, com CObject. No final, escrevi uma implementação simples do processamento de eventos OnTradeTransaction, OnChartEvent e OnTimer com a ajuda de OOP "real"....

.

 
Dmitry Fedoseev:

.

De coração - CObject e"Standard Library" ainda são um legado dos anos 90 :-))

Até que haja uma STL semelhante que não exija atributos adicionais das instâncias e/ou a presença de "adam" (grande classe/ancestral comum), haverá problemas significativos - a parte visível deles é a quantidade de código dos programas de aplicativos. Eles são enormes....

 
Maxim Kuznetsov:

De coração - CObject e"Biblioteca Padrão" são um legado dos anos 90 :-)

Até que haja uma STL semelhante que não exija atributos adicionais das instâncias e/ou a presença de "adam" (grande classe/ancestral comum), haverá problemas significativos - a parte visível deles é a quantidade de código dos programas de aplicativos. Eles são enormes....

CObjeto não é o ponto aqui. OOP != Padrões, não confunda onde o poder dos padrões é usado e onde o poder da OOP é usado. Não há necessidade especial de OOP, e muito menos de modelos, ao escrever expresso, e certamente não há necessidade de criar um análogo de um delegado usando OOP enquanto houver ponteiros para funções.

Por mais triste que seja, a piada sobre o "clube das vítimas do C++" está se tornando realidade. É estranho que as pessoas empilhem um monte de todos os tipos de problemas em si mesmas e considerem isso uma codificação legal. Mas, na verdade, um programador moderno se degenerou em um plugger de biblioteca.
 
Dmitry Fedoseev:

CObject não é o principal aqui. OOP != Templates, não confunda onde o poder dos templates é usado e onde o poder da OOP é usado. Não há necessidade especial de OOP, muito menos de modelos, na escrita de expressões, muito menos de criar um análogo de um delegado usando OOP enquanto houver ponteiros para funções.

Por mais triste que seja, a piada sobre o "clube das vítimas do C++" está se tornando realidade. É estranho que as pessoas empilhem um monte de todos os tipos de problemas em si mesmas e considerem isso uma codificação legal. Mas, na verdade, um programador moderno se degenerou em um plugger de biblioteca.

"Qual é o poder, irmão?"

os conectores de bibliotecas devem dominar. Na verdade, isso é correto quando reduz o tamanho do código e o tempo de desenvolvimento.

PS/ até o momento, todos os artigos publicados (e seus desenvolvimentos, o que é mais importante) são a antítese da programação - eles não aumentam a eficiência.

 
Maxim Kuznetsov:

"Qual é o poder, irmão?"

Os plug-ins de biblioteca devem ser a regra. Na verdade, é a coisa certa a fazer quando reduz o tamanho do código e o tempo de desenvolvimento.

PS/ até o momento, todos os artigos publicados (e seus desenvolvimentos, o que é mais importante) são a antítese da programação - eles não aumentam a eficiência.

O poder está no conhecimento, e os artigos apenas fornecem conhecimento e nada mais deveriam fornecer. Aumentar a eficiência é uma questão pessoal de cada um. Aumentar a eficiência da programação é certamente bom, mas não quando isso deixa o usuário do programa menos confortável.

 
Dmitry Fedoseev:

... De fato, o programador moderno degenerou em um plugger de biblioteca.

Em breve, ele desaparecerá completamente, pois será possível criar "objetos" (grupos nomeados de parâmetros com links predefinidos) intuitivamente e sem educação superior, com o apoio de um IDE "intelectualmente desenvolvido", que "entenderá" a essência da estrutura lógica que está sendo criada a partir de "meia palavra". O ambiente se tornará mais sábio e a era dos programadores especializados e da diversidade de linguagens chegará ao fim. Todos serão capazes de criar algoritmos lendo as instruções do programa. Um processo natural, nada com que se preocupar..... É estranho que isso não tenha começado antes, mas, em vez disso, as linguagens que repetem um conceito de maneiras diferentes proliferaram.

 

Não haverá XML. O objetivo é passar sem MQL. O objetivo é criar um sistema de marcação de nível MVP "nativo" para MQL - sem frescuras, mas funcional e extensível o suficiente para aqueles que precisam dele. Será possível não entrar na estrutura interna. Normalmente, é melhor ter uma descrição do conceito e do dispositivo do que não ter nenhuma.

Também não gosto muito da biblioteca padrão, mas não há muitas opções, por isso ela é (por enquanto) o melhor meio-termo entre as poucas bibliotecas muito pequenas e muito sofisticadas que, de qualquer forma, têm grandes questões.

Recomenda-se que os supostos luminares da programação e da criação de GUIs que se declararam como tais com base em trabalhos manuais ingênuos demonstrem suas habilidades em seus próprios tópicos.

 
Stanislav Korotky:

...

Recomenda-se que os luminares imaginários da programação e da criação de GUIs que se declararam como tais com base em trabalhos manuais ingênuos demonstrem suas habilidades em seus próprios tópicos.

Bingo.