Discussão do artigo "Linguagem MQL como um meio de marcação da interface gráfica de programas MQL. Parte 1" - página 3
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
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. É que geralmente é melhor ter uma descrição do conceito e do dispositivo do que não ter nenhuma.
...
Na verdade, não existem usuários de bibliotecas gráficas, linguagem de marcação ou editor visual (talvez existam, mas você não os vê). Há pessoas ansiosas para aprender. Se não houver um conceito de linguagem de marcação nos artigos, eles não terão sentido. Escreva um conceito. Boa sorte.
Não há usuários de bibliotecas gráficas, linguagem de marcação ou editor visual (talvez haja, mas você não os vê). Há pessoas tentando aprender. Se os artigos não tiverem um conceito de linguagem de marcação, eles não terão sentido. Escreva um conceito. Boa sorte.
Significado. Não há linguagem no artigo, nem mesmo o conceito em si?
O que isso significa? Não que não haja linguagem no artigo, nem mesmo que o conceito em si esteja ausente?
O autor não descreveu como a linguagem de marcação funciona. Faça a pergunta"como funciona a linguagem de marcação?" e encontre uma resposta detalhada no artigo. Não há.
O autor não descreveu como a linguagem de marcação funciona. Faça a pergunta"como funciona a linguagem de marcação?" e encontre uma resposta detalhada no artigo. Não há.
Provavelmente, ela estará na próxima edição.
Provavelmente estará na próxima edição.
Também achei que estaria na próxima. Não somos simplórios aqui. Todos entendem.
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. É que geralmente é melhor ter uma descrição do conceito e do dispositivo do que não ter nenhuma.
Também não estou entusiasmado com a biblioteca padrão, mas não há muitas opções em geral, portanto, ela é (por enquanto) um compromisso ideal entre as poucas bibliotecas muito pequenas e muito sofisticadas que, de qualquer forma, têm grandes questões.
Os supostos luminares da programação e da criação de GUIs que se declararam como tais com base em trabalhos manuais ingênuos são aconselhados a demonstrar suas habilidades em seus próprios tópicos.
A quem exatamente você está se referindo? Especialmente porque está no plural, e não há muitos de nós aqui. Se fosse no singular, eu pensaria que se tratava do Peter... mas está no plural. Isso levanta questões.
Por que você não usa apenas seu primeiro nome? Para que não surjam dúvidas desnecessárias. Ou você não pode simplesmente chutar o ar?
Ao tópico do artigo. Pela quinta vez, reli todo o texto com cuidado, de forma neutra e o mais objetiva possível. E aqui está o resultado final:
1. No início do artigo, o autor discute de forma clara e lúcida com o leitor as questões de relevância da GUI nos programas. Fala sobre as ferramentas gráficas disponíveis do MQL - objetos MT, bibliotecas e até mesmo um editor de visualização. Afirma que a GUI é mais necessária do que desnecessária. Essa é uma parte clara e agradável do artigo.
2. A aceleração começa. O autor dá um exemplo de código de biblioteca padrão e o critica merecidamente - ele é longo, inconveniente e ineficiente ao criar uma GUI. A simpatia está do lado dele.
3. Em seguida, o autor passa para a discussão de GUIs em outras linguagens, onde observa corretamente que a descrição do layout é sabiamente separada do código do programa e representa um ramo independente que simplifica o layout de rotina das interfaces. Ele lista as vantagens. Dessa vez, o autor usa frases gerais e referências à literatura, à plataforma .Net, ao Android, ao XML.... Ele diz que lá, assim como aqui, tudo está em "um único flacon" e a hierarquia é visível, e também são definidos "controladores únicos". Ele não esclarece, apenas continua. Para os não iluminados, a clareza acaba e tudo se transforma em uma névoa. Onde, o que, por que....
4- O autor "voa" e o diálogo com o leitor se transforma em um monólogo de alta velocidade. A sequência clara de apresentação desaparece: perguntas/temas/soluções/exemplos/códigos - tudo fica misturado. É claro que não é difícil para os telepatas, mas o restante de nós tem dificuldades. Parece que o autor está pensando em soluções para um novo idioma na hora e vai terminar tudo até o final do artigo. Tipo"não interfira, eu faço tudo!". Em um ritmo frenético, pedaços de pensamentos, códigos, nomes de variáveis e métodos (talvez conhecidos por alguém...) passam rapidamente. Os saltos são cada vez mais frequentes e minha cabeça não consegue lidar com a busca de links entre as frases. Torna-se realmente difícil de ler.
5. O diálogo com o leitor se perdeu após os dois primeiros capítulos e a leitura posterior não me esclareceu nada. Embora eu tenha me esforçado muito. A pergunta permaneceu: "E o que exatamente o autor sugere?".
Fechei o artigo e não conseguia me lembrar de nada, exceto do exemplo com as manchas e os primeiros parágrafos. Todo o resto se dissolveu em uma névoa.
Espero que, na próxima edição, o autor continue o diálogo com o leitor e mantenha a estrutura narrativa até o final do artigo.
Obrigado.
Dmitry Fedoseyev, embora ofensivo, é um vídeo muito engraçado. Eu ri por um bom tempo. Quando li o que você destacou, percebi que parecia muito estúpido. Seria mais correto dizer que não foi reescrito, mas melhorado e complementado. Li muitos de seus artigos durante os cinco anos de sua presença neste site e não tenho dúvidas de que seu conhecimento é muito maior do que o meu, mas não concordo com você quando diz que não há necessidade de OOP na escrita expressa. Como em programas complexos, que usam interfaces gráficas, combinam vários TS em um EA, mantêm estatísticas etc., a OOP ajuda muito a estruturar melhor o código do programa, e os padrões de design (embora eu ainda esteja no início de seu estudo) aumentam o poder da OOP muitas vezes. Obviamente, isso não significa que você deva colocá-la em um pequeno EA, onde você pode usar procedimentos comuns, e a velocidade de escrita será muitas vezes maior. Se for interessante, descreverei um exemplo em que apliquei OOP e um modelo, e como isso simplificou minha vida. E se não for muito difícil, Dmitry, você poderia mostrar suas palavras"e ainda mais ao criar um análogo de um delegado usando OOP enquanto houver ponteiros para funções" em um exemplo. Ou em que artigo você pode encontrar informações sobre ponteiros de função. Desde já, obrigado.
Tudo está na documentação, estude-a e use-a.