Conversando sobre a OLP no salão - página 20
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
O artigo mente!
Eu não li o resto do artigo. Muito provavelmente o absurdo do autor foi imediatamente apontado nos comentários.Continue lendo, está tudo no ponto.
Na codificação de procedimentos, é quase sempre possível personalizar a arquitetura de um programa à medida que você o escreve. Porque a flexibilidade e a liberdade é completa
+
Você pode esquecer o OOP apenas por causa disso, especialmente para algoritmos computacionais, como no comércio...
Sobre os mitos da OLP - e não para os adeptos da OLP de coração fraco.
"Tem havido vários mitos sobre o OOP desde meados dos anos 80. Um deles, o Mito da Reutilização, diz que o OOP torna o desenvolvimento mais produtivo porque permite herdar e estender o código atual em vez de ter que escrevê-lo novamente. O outro é o Mito do Design, o que implica que a análise, o projeto e a implementação seguem sem problemas um do outro, pois todos eles são objetos. É claro que nenhum desses mitos pode ser o paradigma OOP".
O tio é um teórico e tagarela, como a maioria no meio acadêmico. E não importa que ele seja professor (o título há muito tempo foi inflectido) e autor de livros.
Este lixo de frases tem andado por aí por muito tempo e ignora completamente o crescimento exponencial da complexidade dos produtos de software. O que era há 30-20-10 anos não é de forma alguma comparável à escala e complexidade dos projetos atuais. E eles ainda preferem brincar na caixa de areia, reduzindo-a a modelos.
Sente-o para fazer um produto real, que tem muitas exigências, inclusive de recursos, econômicas e competitivas. Ele se passará instantaneamente com seu raciocínio, falhando de todas as maneiras possíveis. É mais provável até mesmo que seja expulso por capitania infantil na fase de projeto da solução.
O mundo já tentou muitas balas de prata, mas todas elas provaram ser inúteis e há muito tempo foram eliminadas. Isso deixa um crescimento constante da complexidade, crescimento das bibliotecas (e há uma oop) e dos quadros (e há uma oop), o que permite pelo menos algum controle sobre a complexidade.
E não há como fugir da crescente complexidade. Haverá ainda mais complexidade, haverá mais desenvolvedores analfabetos incapazes de acompanhar as exigências de qualidade do conhecimento.
Haverá mais tentativas de criar idiomas ainda mais simples para atender ao nível de massa sempre decrescente dos programadores. Mais e mais empresas de software se encontrarão em desvantagem simplesmente por acreditarem na tecnologia errada e perderem a corrida competitiva. É que seus concorrentes utilizarão tecnologia mais pesada, mas eficaz em termos de resultados do produto.
Investir em empresas de software tem sido uma coisa mortal há muito tempo. As taxas de mortalidade e fracasso são espantosas, e a partir daqui as coisas vão piorar.
Por quê? Sim, porque é um negócio com grandes exigências econômicas, não tecnológicas. Cerca de 80% de uma empresa de software viva e permanente consiste em marketing e vendas. A tecnologia errada (e aqui a maioria das pessoas prioriza a suposta simplicidade) mata facilmente as vendas futuras. Porque sempre há concorrentes que tomaram um caminho mais difícil e obtiveram melhores resultados no final.
Agora sobre micro-projetos de até cem mil linhas. Isto permite que você crie qualquer coisa, pois tem a chance de caber na cabeça de uma pessoa e manter a ilusão de controle. Se você tentar aumentar a escala - dor, frustração e morte.
Conclusões:
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
Falando sobre OLP
Renat Fatkhullin, 2018.01.17 09:17
O tio é um teórico e tagarela como a maioria no meio acadêmico. E não importa que ele seja um professor (o título há muito tempo foi inflado) e um autor de livros.
Este lixo feito de frases já circula há muito tempo e ignora completamente o crescimento exponencial da complexidade do software. O que era há 30-20-10 anos não é de forma alguma comparável à escala e complexidade dos projetos atuais. E eles ainda preferem brincar na caixa de areia, reduzindo-a a modelos.
Sente-o para fazer um produto real, que tem muitas exigências, inclusive de recursos, econômicas e competitivas. Ele fracassará instantaneamente com seu raciocínio, falhando de todas as maneiras que puder. É mais provável até mesmo que seja expulso por capitania infantil na fase de projeto da solução.
O mundo já tentou muitas balas de prata, mas todas elas provaram ser inúteis e há muito tempo foram descartadas. Isso deixa um crescimento constante da complexidade, crescimento das bibliotecas (e há uma oop) e dos quadros (e há uma oop), o que permite pelo menos algum controle sobre a complexidade.
E não há como fugir da crescente complexidade. Haverá ainda mais complexidade, haverá mais desenvolvedores analfabetos incapazes de acompanhar as exigências de qualidade do conhecimento.
Haverá mais tentativas de criar idiomas ainda mais simples para atender ao nível de massa sempre decrescente dos programadores. Mais e mais empresas de software estarão em desvantagem, simplesmente por acreditarem na tecnologia errada e perderem a corrida competitiva. É que seus concorrentes utilizarão tecnologia mais pesada, mas eficaz em termos de resultados do produto.
Investir em empresas de software tem sido uma coisa mortal há muito tempo. As taxas de mortalidade e fracasso são espantosas, e a partir daqui as coisas vão piorar.
Por quê? Sim, porque é um negócio com grandes exigências econômicas, não tecnológicas. Cerca de 80% de uma empresa de software viva e permanente consiste em marketing e vendas. A tecnologia errada (e aqui a maioria das pessoas prioriza a suposta simplicidade) mata facilmente as vendas futuras. Porque sempre há concorrentes que tomaram um caminho mais difícil e obtiveram melhores resultados no final.
Agora sobre micro-projetos de até cem mil linhas. Isto permite que você crie qualquer coisa, pois tem a chance de caber na cabeça de uma pessoa e manter a ilusão de controle. Se você tentar aumentar a escala - dor, frustração e morte.
Conclusões:
Melhor posto do mês, ou talvez do ano! Renat, por que você ou sua empresa não escrevem artigos sobre hubra(a empresa não está nem registrada lá!)? Você tem muito a dizer, mas sua experiência só é aprendida em trechos de seus postos. Sério, muito atual e preciso. Para ilustrar seu post:https://habrahabr.ru/post/344356/
Melhor posto do mês, talvez do ano!
O que você gostou tanto deste post no contexto do tópico do OOP? Provavelmente não é muito correto generalizar também sobre coisas comerciais, os investidores não são tolos e envolvem seus especialistas para avaliar o risco dos projetos...
Este artigo de alguns, mas ainda um professor tem argumentos lógicos específicos para os quais não foram apresentados contra-argumentos adequados para discussão...
Também é claro que a simples pogramação nem sempre é um mal para os projetos...
Melhor posto do mês, talvez do ano! Renat, por que você ou sua empresa não escrevem artigos sobre hubra(a empresa não está nem registrada lá!)? Você tem muito a dizer, mas sua experiência só é aprendida em trechos de seus postos. Sério, muito atual e preciso. Como ilustração para o post:https://habrahabr.ru/post/344356/
Trabalhamos para milhões, não para os 1.000 - 5.000 leitores/visitas que os artigos sobre Habra normalmente recebem.
Fizemos um padrão industrial e estamos lançando soluções que impactam o mundo. Por que precisamos de algum tipo de Habr, e ainda mais, espremido em um nicho estreito do segmento russo.
O que você gostou tanto deste post no contexto do tópico OOP? Provavelmente não é muito correto generalizar também sobre coisas comerciais, os investidores não são tolos e envolvem seus especialistas para avaliar o risco dos projetos...
Há argumentos lógicos específicos neste artigo de alguns, mas ainda um professor, aos quais não foram apresentados contra-argumentos adequados para discussão...
Também é óbvio que a simples pogramação nem sempre é um mal para os projetos...
Pare com as balizas diletantish, por favor.
Você será simplesmente banido por ser tecnicamente analfabeto. Não precisamos de ignorantes beligerantes em nosso fórum.
...
Também é óbvio que a simplicidade de programação nem sempre é um mal para os projetos...
Existe um axioma: a complexidade não vai a lugar algum. Consequentemente, a "simplicidade de programação" para o usuário é uma transferência de complexidade para o compilador. A complexidade é como que processada pelo compilador nos bastidores e ele, o compilador, tenta esconder qualquer perversão do programador de acordo com o princípio "é melhor deixá-lo trabalhar de alguma forma do que nada". O compilador, não o programador, torna-se o proprietário do projeto. O desenvolvimento e a manutenção do código torna-se impossível, porque você não entende o que está acontecendo (o compilador o constrói de alguma forma, mas o que quer que seja).
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
Falando sobre o OOP
Renat Fatkhullin, 2018.01.17 09:17
...
E não há como fugir da crescente complexidade. Haverá ainda mais complexidade, haverá mais desenvolvedores analfabetos incapazes de acompanhar as exigências de qualidade do conhecimento.
Haverá mais tentativas de criar idiomas ainda mais simples para atender ao nível de massa cada vez menor dos programadores. Mais e mais empresas de software se encontrarão em desvantagem simplesmente por acreditarem na tecnologia errada e perderem a corrida competitiva. É que seus concorrentes utilizarão tecnologia mais pesada, mas mais eficaz em termos de resultados do produto
...
Pare com as balizas diletantish, por favor.
Você será simplesmente banido por ser tecnicamente analfabeto. Não precisamos de ignorantes beligerantes em nosso fórum.