Auto-aprendizagem da linguagem MQL5 a partir do zero - página 17

 
Roman:

Exatamente o oposto de vocês!
A coisa mais importante na programação é conhecer a linguagem no nível mais baixo possível!
Para iniciantes, um nível baixo é a sintaxe do idioma sem invólucros de código adicionais.
E a decomposição, como você coloca, é um entendimento de como os fluxogramas são compostos.
É por isso que um programador é valorizado não por fantasias filosóficas, mas pelo conhecimento prático da língua.
Como você pode fantasiar sem o básico do idioma? Onde está a lógica simples?
Equivalente à linguagem de um engenheiro eletrônico, que é o autor deste fio, primeiro fornece tensões para a placa, e depois se pergunta por que a placa se queimou ))

Eu discordo. Quando você estabelece uma meta, não precisa conhecer o idioma, só precisa compreender suas capacidades. Mas ao estabelecer um objetivo, resolvê-lo, selecionar algoritmos e codificar, em todas estas etapas é necessário. Definir um problema sem conhecer a sintaxe da linguagem é às vezes um grande problema na implementação))))

 
Roman:

... Equivalente, em linguagem eletrônica, que é o autor deste fio, para primeiro aplicar tensões ao quadro, e depois se perguntar por que o quadro queimou ))

Olá Roman! Ótima comparação. Agora estou na programação no mesmo nível de engenheiro eletrônico, quando passei de conhecer os princípios dos transistores para aprender os princípios dos circuitos digitais K155.

Embora, muitos de meus colegas em 1983 tenham conseguido reparar computadores da série EU sem nenhum entendimento de como funcionavam os transistores. Era suficiente para eles conhecerem a álgebra da lógica. Foi uma digressão - nostalgia dos tempos soviéticos!

Cumprimentos, Vladimir.

 
Valeriy Yastremskiy:

Eu discordo. Ao estabelecer uma meta, você não precisa conhecer o idioma, precisa entender suas capacidades. Mas na definição de problemas, solução de problemas, seleção e codificação de algoritmos, todas estas etapas são necessárias. Definir um problema sem conhecer a sintaxe da linguagem é às vezes um grande problema na implementação))))

Portanto, como você entenderá as possibilidades se não conhecer essas possibilidades )
Definição do problema, é o estágio extremo do domínio do básico do idioma, quando você já entende o que é uma variável, que tamanhos ela pode ser, escopo, etc.
Eu também estava numa encruzilhada, quando não sabia por onde começar, que língua aprender e compreender tudo. Foi uma agonia, porque tentei várias línguas para encontrar a verdade.
Mas quando finalmente percebi que o mql era uma linguagem em C, comecei a aprender C de uma maneira proposital, a partir do básico.
E quando terminei o estudo básico, fiquei surpreso ao descobrir que praticamente já conheço o mql, e tudo está claro para mim, apenas a sintaxe e as especificidades devem ser melhoradas pelas docas, é uma característica do mql.
Tendo compreendido a abordagem processual da programação, comecei a entrar no OOP depois de um ano. Durante muito tempo, não ficou claro para mim, por causa de outros nomes da mesma coisa.
Por exemplo, método e função, qual é a diferença )) variável e membro de classe ) etc.
Mas para chegar lá, você precisa entender a própria base da abordagem processual, e quando você começa a entender gradualmente a terminologia do OOP, o entendimento se abre instantaneamente.
Essa é a diferença, a escolha do caminho de aprendizado inicial. Como você pode escrever em russo sem conhecer as letras e os sinais de pontuação?
Lembre-se de onde você começou, com ganchos e bastões.

 
Roman:

Exatamente o oposto de vocês!
O fator determinante na programação é o conhecimento da linguagem, no nível mais baixo possível!

O que isso lhe traz? Você conhece o idioma a um nível ultra-baixo. Você sabe com que comandos assembler são substituídos por if, como o for loop é convertido em goto. Você conhece assembler. Onde está o lucro nisso? Veja os programadores Python. Eles não sabem de nada disso. Mas eles são muito bons no manuseio de funções, eles sabem como Mapear/Reduzir. Eles são capazes de compô-las e inseri-las umas nas outras. E onde está a MQL agora que eles não estão escrevendo tanto nela em comparação com a Python?

Roman:

Como você pode imaginar sem o básico do idioma? Onde está a lógica simples?
É semelhante à linguagem eletrônica, que é a autora deste fio, primeiro para fornecer tensões à placa, e depois se perguntar por que a placa queimou ))

Na sua compreensão da lógica simples, é um procedimento de venda livre. Do meu ponto de vista, é como uma linguagem de montagem: "o que eu vejo é o que eu canto". Não há lógica aí, é apenas uma habilidade de digitação idiota. Um datilógrafo pode fazer isso após duas semanas de treinamento. Isso não é programação.

Roman:

No que diz respeito à decomposição, como você diz, é compreender como são feitos os fluxogramas.

Um fluxograma é um diagrama para os idiomas de procedimento. "Aqui está o laço para o loop, aqui está o se loop". Hoje em dia, ninguém escreve em idiomas de procedimento. Isto é um absurdo para uma aplicação do usuário escolher, por exemplo, C ou Pascal. Para um núcleo de SO ou alguma outra linguagem processual, é o melhor. Mas esta é uma porcentagem muito pequena de tarefas e claramente não está dentro do escopo da tarefa em questão.
 
Vasiliy Sokolov:

E qual seria o benefício de tal conhecimento? Você conhece o idioma a um nível ultra-baixo. Você sabe o que os comandos de assembler substituem se, como o para loop é convertido para goto. Você conhece o assembler. Onde está o lucro nisso? Veja os programadores Python. Eles não sabem de nada disso. Mas eles são muito bons no manuseio de funções, eles sabem como Mapear/Reduzir. Eles são capazes de compô-las e inseri-las umas nas outras. E onde está a MQL hoje em dia onde eles escrevem não tanto como em Python?

Na sua compreensão da lógica simples, é uma coisa terrivelmente processual. Na minha compreensão da lógica é como em assembler: "o que eu vejo, que eu canto sobre". Não há lógica aí, é apenas uma habilidade de digitação idiota. Um datilógrafo pode fazer isso após duas semanas de treinamento. Não é programação.

Um fluxograma é um diagrama para os JDs de procedimento. "Aqui está o laço para o loop, aqui está o se loop". Hoje em dia, eles não escrevem nos idiomas de procedimento. Isto é um absurdo para uma aplicação do usuário escolher, por exemplo, C ou Pascal. Para um núcleo de SO ou alguma outra linguagem processual, é o melhor. Mas é uma porcentagem muito pequena de tarefas e está claramente fora do escopo da tarefa em questão.
Vasily, como você pode imaginar ensinar o TC a programar no OOP-paradigma, evitando as coisas elementares, que ele não tem?) Não, bem, talvez seja possível, mas não consigo imaginar...

Como explicamos: "Algoritmos de programação (rotinas) = abordagem errada". Você deve programar sistemas conceitualmente completos, hierarquicamente estruturados e com padrões chamados "objetos" que herdam as propriedades e métodos uns dos outros dentro de um ambiente de software".

E ele disse imediatamente: "Ahhhh, por que você não disse isso antes! Tudo isso faz sentido"))))
 
Vasiliy Sokolov:

E qual seria o benefício de tal conhecimento? Você conhece o idioma a um nível ultra-baixo. Você sabe o que os comandos de assembler substituem se, como o para loop é convertido para goto. Você conhece o assembler. Onde está o lucro nisso? Veja os programadores Python. Eles não sabem de nada disso. Mas eles são muito bons no manuseio de funções, eles sabem como Mapear/Reduzir. Eles são capazes de compô-las e inseri-las umas nas outras. E onde está a MQL hoje em dia onde eles escrevem não tanto como em Python?

Na sua compreensão da lógica simples, é uma coisa terrivelmente processual. Na minha compreensão da lógica é como em assembler: "o que eu vejo, que eu canto sobre". Não há lógica aí, é apenas uma habilidade de digitação idiota. Um datilógrafo pode fazer isso após duas semanas de treinamento. Não é programação.

Um fluxograma é um esquema para os idiomas de procedimento. "Aqui está o laço para o loop, aqui está o se loop". Hoje em dia, ninguém escreve em idiomas de procedimento. Isto é um absurdo para uma aplicação do usuário escolher, por exemplo, C ou Pascal. Para um núcleo de SO ou alguma outra linguagem processual, é o melhor. Mas esta é uma porcentagem muito pequena de tarefas e claramente não está dentro do escopo da tarefa em questão.

Para seu esclarecimento, Python está escrito em C.
E a Python foi projetada para facilitar a escrita do código. Mas tendo se tornado uma linguagem popular por causa de sua aparente simplicidade, o conhecimento dos codificadores permanece no nível de Python.
E somente programadores que conhecem C escrevem bibliotecas e coisas adicionais a ela. Estes são programadores e não codificadores.
Esse é o ponto que uma simples datilógrafa de código irá bater os codificadores com sua compreensão do assunto.
Você é apenas um C#-nik, é por isso que você tem esse olhar, mas nem pense em que linguagem essa linguagem C# está escrita))

 
Roman:

Portanto, como você entenderá as possibilidades se não conhecer essas possibilidades )
O problema é o estágio extremo do domínio do básico de uma linguagem, quando você já entende o que é uma variável, que tamanhos ela pode ter, escopos, etc.
Eu também estava numa encruzilhada, quando não sabia por onde começar, que língua aprender e entender tudo. Foi uma agonia, porque tentei várias línguas para encontrar a verdade.
Mas quando finalmente percebi que o mql era uma linguagem em C, comecei a aprender o C como uma forma orientada a metas, a partir do básico.
E quando terminei o estudo básico, fiquei surpreso ao descobrir que praticamente já conheço o mql, e tudo está claro para mim, apenas a sintaxe e as especificidades devem ser melhoradas pelas docas, é uma característica do mql.
Tendo compreendido a abordagem processual da programação, comecei a entrar no OOP depois de um ano. Durante muito tempo, não ficou claro para mim, por causa de outros nomes da mesma coisa.
Por exemplo, método e função, qual é a diferença )) variável e membro de classe ) etc.
Mas para chegar lá, você precisa entender a própria base da abordagem processual, e quando você começa a entender gradualmente a terminologia do OOP, o entendimento se abre instantaneamente.
Essa é a diferença, a escolha do caminho de aprendizado inicial. Como você pode escrever em russo sem conhecer as letras e os sinais de pontuação?
Pense no ponto de partida, com ganchos e bastões.

Eu não sei o que dizer. Cada um tem seu próprio caminho, acho eu. Eu não insisto. Mas os objetivos podem ser resolvidos em diferentes idiomas e pode-se não conhecer a sintaxe ao escolher um objetivo, mas apenas as possibilidades. Existem bibliotecas para websites em python, e o site pode ser feito em python, pxp, jumla, html ou qualquer outro, é uma questão de preço e disponibilidade de funcionalidade pronta (scripts), e esta é uma declaração de problema e requer um conhecimento mais profundo do idioma. Podemos selecionar os seguintes roteiros para trabalhar com séries: MKL, Python, R e Matlab. O MCL nativo será suficiente para definir ordens por parte dos MA.

Tudo tem que estar em harmonia. Conhecer a mecânica do carro não é o mesmo que dirigi-lo bem. Mas não saber que o mecanismo é ruim para avarias na estrada).

E para cada um deles, muitas vezes um bom codificador não é um bom algorítimo e vice-versa. Se essas qualidades forem boas juntas, geralmente é legal e caro, mas não tão frequentemente.))))

 
Naturalmente, a abordagem processual isola o programador de enormes bibliotecas OOP que contêm toneladas de soluções prontas. E este "isolamento" certamente afeta o nível de sua codificação. Mas só se pode chegar às bibliotecas depois de dominar a base. Ou seja, é possível estruturar um programa como um ambiente objeto, em vez de uma instrução funcional plana, tendo apenas uma forte base de teoria e prática inicial. Imho, é claro.
 
Vasiliy Sokolov:

E qual seria o benefício de tal conhecimento? Você conhece o idioma a um nível ultra-baixo. Você sabe o que os comandos de assembler substituem se, como o para loop é convertido para goto. Você conhece o assembler. Onde está o lucro nisso? Veja os programadores Python. Eles não sabem de nada disso. Mas eles são muito bons no manuseio de funções, eles sabem como Mapear/Reduzir. Eles são capazes de compô-las e inseri-las umas nas outras. E onde está a MQL hoje em dia onde eles escrevem não tanto como em Python?

Na sua compreensão da lógica simples, é uma coisa terrivelmente processual. Na minha compreensão da lógica é como em assembler: "o que eu vejo, que eu canto sobre". Não há lógica aí, é apenas uma habilidade de digitação idiota. Um datilógrafo pode fazer isso após duas semanas de treinamento. Não é programação.

Um fluxograma é um fluxograma para os idiomas de procedimento. "Aqui está o laço para o loop, aqui está o se loop". Hoje em dia, ninguém escreve em idiomas de procedimento. Isto é um absurdo para uma aplicação do usuário escolher, por exemplo, C ou Pascal. Para um núcleo de SO ou alguma outra linguagem processual, é o melhor. Mas esta é uma porcentagem muito pequena de tarefas e claramente não está dentro do escopo da tarefa em questão.

É muita coisa, é a maneira correta de fazer as coisas. Idealmente, o cliente deve ser um bom codificador)))) Quanto nervos seria poupado))))

Conhecer um idioma em um nível baixo não invalida o conhecimento de idiomas de alto nível e apenas dá uma compreensão mais profunda de como o programa funciona. E se ele sabe como funcionam os loops e quanta memória eles consomem, pode otimizá-los se necessário. Não mais do que isso.

Para ser honesto, não entendo o objetivo do argumento.

 
Valeriy Yastremskiy:

...

E, francamente, não entendo o objetivo do argumento.

Eu acho que Vasily quer tentar ensinar a um principiante o pensamento OOP, onde tudo, exceto o próprio OOP, é secundário. Não comece com variáveis, operadores, arrays, mas comece com classes, herdando propriedades, construindo hierarquias de objetos e conectando bibliotecas poderosas. Transferência do "berçário" e ir direto para a universidade))))