Perguntas sobre OOP em MQL5 - página 25
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
Há estatísticas detalhadas aqui https://githut.info/, mas é o ano 14.
Novas estatísticas sobre o github https://madnight.github.io/githut/#/pull_requests/2019/2
Penso que todos se beneficiariam da leitura da opinião profissional contida neste artigo.
Boa sorte.
Penso que todos se beneficiariam da leitura da opinião profissional contida neste artigo.
todas as conclusões (totalmente tendenciosas) do artigo são compensadas por uma simples pergunta.
FP existe há muito tempo, por que ela ainda tem um nicho tão pequeno se é tão fantástica?
Não quero dizer de forma alguma que o OOP é o melhor conceito ou OP é uma porcaria.
todas as conclusões (totalmente tendenciosas) do artigo são niveladas por uma simples pergunta.
A FP existe há muito tempo, por que ainda tem um nicho tão pequeno se é tão fantástico?
O artigo tem a resposta para essa pergunta. Você não o leu com atenção.
O artigo tem uma resposta para esta pergunta.
Totalmente tendencioso e sobre nada.
Há desenvolvedores que realmente escrevem o código. Há gerentes que podem não saber programar nada.
Portanto, a pilha de tecnologia não é necessariamente escolhida pelos desenvolvedores. E se uma certa pilha permite que uma equipe resolva um problema de forma mais eficiente, você não precisa conhecer e possuir a tecnologia para entendê-lo.
Você ainda acha que o artigo responde à pergunta?
Penso que todos se beneficiariam da leitura da opinião profissional contida neste artigo.
Boa sorte.
Aqui está o costume. Pontos de vista extremos. É como uma discussão sobre o que é melhor - um martelo ou um martelo de forja.
Você não vai escrever boas ferramentas em C#, mas em C# puro você vai se cansar de descrever e depurar cadeias lógicas ramificadas em uma aplicação séria.
Portanto, este artigo é inútil.
É sempre assim. Pontos de vista extremos. É como uma discussão sobre o que é melhor - um martelo ou um martelo de forja.
Você não vai escrever boas ferramentas em C#, mas em C# puro você vai se cansar de descrever e depurar cadeias lógicas ramificadas em uma aplicação séria.
Portanto, este artigo é sobre nada.
Há, é claro, alguma verdade no artigo... pelo menos, que a herança "puxará" métodos e campos que não são realmente necessários, mas, infelizmente, você tem que pagar por tudo - economiza tempo, mas pode aumentar o uso de memória ou o desempenho geral de uma solução, mas nem tudo é tão triste, o nível de compiladores e otimização de código é muito íngreme agora, de modo que o resultado muitas vezes resulta em uma boa solução por um curto tempo de desenvolvimento
sobre C#, bem, como se o propósito tivesse outros, é puramente uma "linguagem Windows" para obter resultados rapidamente em um PC em particular ou em um grupo limitado de PCs, mesmo que não estejam instaladas atualizações .Net podem causar erros críticos em PCs que não têm acesso, e pegar isso é bastante caro - escreveu um painel para comércio em C# já o verificou em uma máquina virtual, se não estiver instalado todo o "patch" nas atualizações, o projeto não pode previsivelmente voar para fora ;) É claro que você pode tentar escrever para a versão mais junior do .Net, mas há um problema - todas as notícias no GitHub postadas sob as novas construções do .Net - ou seja, você estará limitado apenas aos seus desenvolvimentos
Em geral, como em outros lugares - a inovação é "dolorosa e longa e triste", você tem que seguir as tendências definidas pelos gigantes de TI, então tudo é escrito rapidamente e sem problemas, bem, a Microsoft escreveu tudo o que pôde no estilo OOP, você tem que usar tudo ou vai escrever do zero todos os seus WinForm, etc. milhares de toneladas e terabytes de código escrito desde Win-95)))
há certamente um pouco de verdade no artigo...
Um pouco? ) Na verdade, as coisas são assim mesmo. No entanto, o autor não revela a verdade, são coisas óbvias (pelo menos para mim). Pensei que qualquer programador com experiência chegasse à mesma compreensão dos problemas de mudança de estado. A propósito, recentemente vi um artigo muito parecido, mas mais curto. Mas, talvez, seja o eterno debate entre funcionalistas e programadores de código aberto )
Mas, na verdade, ninguém impede que você use o OOP corretamente. Até o próprio autor menciona que você pode usar objetos imutáveis. E 99% dos problemas descritos desaparecem de uma só vez. Portanto, tudo depende apenas da questão das mãos retas e da cabeça sobre os ombros, não do paradigma que está sendo usado.
Embora, é claro, o fato de que as linguagens populares do OOP não fornecem os meios para controlar a variabilidade dos objetos, complica o processo. Portanto, seria muito legal ter a palavra-chaveimutável em vez de const/readonly.
Quanto às razões de impopularidade das linguagens funcionais, não concordo com o autor aqui. Em primeiro lugar, é uma percepção mais complicada de tal código, como me parece. Esta não é apenas uma oposição do OOP e do FP, mas uma oposição de abordagens imperativas e funcionais. A primeira é mais próxima e intuitiva para a maioria das pessoas, na minha opinião. Só conheço idiomas funcionais por correspondência, portanto não posso julgá-los objetivamente, mas quando, por exemplo, vejo o código sobrecarregado com lambda, isso causa dissonância cognitiva) É muito complicado e intrincado. E provavelmente a maioria das pessoas também pensa assim )
E além dos idiomas funcionais não são destinados a uma série de tarefas ligadas à interação com o ambiente externo. Tomemos o GUI, por exemplo. Quando de uma forma ou de outra você precisa armazenar o estado globalmente alterado entre os eventos.
Um pouco? ) Na verdade, este é exatamente o caso. Entretanto, o autor não está revelando as Américas, estas coisas são meio óbvias (pelo menos para mim). Pensei que qualquer programador com experiência chegasse à mesma compreensão dos problemas de um estado mutável. A propósito, recentemente vi um artigo muito parecido, mas mais curto. Mas, talvez, seja o eterno debate entre funcionalistas e programadores de código aberto )
Mas, na verdade, ninguém impede que você use o OOP corretamente. Até mesmo o autor menciona que você pode usar objetos imutáveis. E 99% dos problemas descritos desaparecem imediatamente. Portanto, tudo depende apenas da questão das mãos retas e da cabeça sobre os ombros, mas não do paradigma usado.
Embora, é claro, o fato de que as linguagens populares do OOP não fornecem um meio de controlar a variabilidade dos objetos, complica o processo. Seria legal ter a palavra-chave imutável em vez de const/readonly.
Em qualquer caso, nada mudará no futuro próximo, os fornecedores de TI suportam este paradigma, pode ser benéfico forçar os desenvolvedores de software a fazer implementações complexas que exigirão hardware mais poderoso para funcionar, bem como apresentar sua documentação para SO ou compiladores com bibliotecas prontas na forma de OOP, o que força os desenvolvedores .... e assim por diante até o infinito ;)
Podemos considerar esta história do OOP como conhecimento obrigatório do latim pelos médicos - não era necessário, mas como meio de comunicação a nível profissional era necessário utilizar ;)