Interessante assumir a OLP

 
Leia menos artigos de ativistas radicais de PF. O conceito de PF não tem um ano ou dois, mas você não ouve falar de uma revolução
 

Isto não é um problema com o OOP, mas com sua aplicação, e ainda mais com aqueles que o aplicam. Eles são os que sentem...

entusiasmo, até êxtase que com a ajuda do OOP você pode escrever incrivelmente

código incrivelmente complicado (e até mesmo competir nele :). Eles se sentem como uma elite especial.

Eles até inventaram seu próprio "grande livro" que eles leram e leram e leram, mas não podem

mas eles não conseguem lê-lo. É chamado de " Padrões de Design" - em linguagem humana

traduzido como "A Última Arte de Escrever Fuzzy, Muzzy e Código Confuso". Se, no entanto.

é uma coisa muito, muito legal, incrivelmente simplificadora e

simplifica e simplifica a vida.

 

Você deve entender que tais artigos são provavelmente escritos por pessoas que não estão familiarizadas com FP e seus ganchos confusos, o que pode incluir 20 tabs....

Depois você começa a pensar em laconismo e conveniência do OOP, você pode declarar algumas das funcionalidades com antecedência e assim por diante..... Em essência, a semelhança de um com o outro. É que tais artigos são frequentemente escritos por pessoas que dominam apenas o código processual - e isto nem sequer é próximo do FP, portanto, se você não sabe quais são os ganchos e o uso vívido do mesmo, nenhum FP está fora de questão

Também muitas das "línguas moribundas" listadas no artigo suportam a funcionalidade total da PF e do OOP, por que deveriam morrer?! E algumas delas são as mais bem pagasno CIS
 
Eu estava falando de "esparguetetificação" no OOP, sem qualquer pensamento de "afogamento" no PF. Na minha opinião, o paradigma processual é realista e mais eficiente em termos de recursos do que o OOP.
 
Mikhail Mishanin:
Trata-se mais de "esparguetetificação" no OOP, sem qualquer pensamento de "afogamento" no PF. Na minha opinião, o paradigma processual é realista e mais eficiente em termos de recursos do que o OOP.

apenas que o código em si é mais longo em oop? bem, sim, existe um construtor e em alguns casos o código é geralmente mais longo em oop.... tecnicamente, a implantação da FP deve ser mais eficiente para a geração de código de máquina.... mas o código não fica mais simples e é impossível fazer invólucros normais no que diz respeito à digitação...

hoje em dia, você pode encontrar frequentemente uma mistura de um e outro - maneiras de não interferir um com o outro

 
Alexandr Andreev:

apenas que o código em si é mais longo em oop? bem, sim, existe um construtor e em alguns casos o código é geralmente mais longo em oop.... tecnicamente, a implantação da FP deve ser mais eficiente para a geração de código de máquina.... mas o código não fica mais simples e é impossível fazer invólucros normais no que diz respeito à digitação...

Hoje em dia, muitas vezes é possível ver uma mistura de um e de outro.

Sem OOP e FP tudo funciona mais fácil e rápido (sim, sem "belezas", painéis, etc.), mas às vezes é difícil de entender até mesmo seu próprio código)

 
Mikhail Mishanin:

Sem OOP e FP, tudo funciona mais fácil e rápido (sim, sem "belezas", painéis, etc.), mas às vezes é difícil de entender até mesmo seu próprio código).

Primeiro domine um ou outro, ou melhor ambos, e depois decida o que você prefere. E com uma abordagem como a de agora, você se transformará em Fedoseev que concorda com tudo o que você não entende (ou seja, quase tudo).

 
A tendência mundial da nova tecnologia é estudar algo novo por três meses, usá-lo por um mês (recolhendo um monte de insetos), depois raspá-lo, e depois estudar algo novo novamente por três meses, apenas para raspá-lo em um mês (recolhendo outro monte de insetos). Se alguém gosta de viver sua vida desta maneira - você é bem-vindo.
 

Que reação destrutiva ao tema e uma discussão destrutiva. Diga-me um seguidor de programação de procedimentos como evitar a "esparguetetização" no OOP, como analisar e se faz sentido usar o "esparguete" de outra pessoa?

Afinal, o que acontece é que o OOP é principalmente para a legibilidade e programação em equipe, ou seja, para grandes projetos. Um Expert Advisor que comercializa um símbolo em seu gráfico com o controle do risco máximo do saldo / fundos na conta, bem, não pode ser chamado de um grande projeto - é suficiente e mais rentável na memória / velocidade - programação de procedimentos.

Perguntas:

- desvantagens/vantagens do OOP(como imperativo) a partir da experiência pessoal

- desvantagens/vantagens do PF (como declarativo) a partir da experiência pessoal.

E uma opinião sobre as perspectivas é naturalmente interessante, especialmente na direção da computação paralela. Não vejo nenhum sentido em tocar no tópico quântico.

 
Mikhail Mishanin:

Diga-me, como programador de procedimentos, como evitar a "spaghettização" no OOP

A receita é dada no artigo citado: esforçar-se para escrever funções determinísticas.

Como desmontar e faz sentido usar o "spaghetti" de outra pessoa?

Bom código, sim, mas não esparguete.

Afinal de contas, o OOP é principalmente para a legibilidade e programação em equipe, ou seja, para grandes projetos.

Certo.

Uma EA comercializando um símbolo a um gráfico do qual é anexado com o máximo controle de risco do saldo/conta, bem, não pode ser chamado de um grande projeto - assim, a programação de procedimentos é suficiente e mais lucrativa em termos de memória/velocidade.

Para viajar para a Austrália, é mais conveniente usar um avião (OOP), para viajar para uma cidade vizinha, um carro ou mesmo uma bicicleta é suficiente (PP). Você só tem que escolher o meio mais conveniente para atingir o objetivo.

Razão: