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

Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
...
...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"....
.
.
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....
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.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.
"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.
... 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.
...
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.