O desempenho mais lento das linguagens de programação é realmente uma coisa ruim? [fechadas]

Aqui está como eu vejo isso.

Há código de máquina e é tudo o que os computadores precisam para executar alguma coisa. Os computadores não se importam com linguagens de programação. Não importa para eles se o código da máquina vem do Perl, Python ou PHP. Linguagens de programação não servem computadores. Eles servem programadores.

Algumas linguagens de programação são mais lentas que outras, mas isso não é necessariamente porque há algo errado com elas. Em muitos casos, é porque eles fazem mais coisas que os programadores teriam que fazer (ou seja, gerenciamento de memória) e, ao fazer essas coisas, são melhores no que deveriam fazer - servir aos programadores.

Então, o desempenho mais lento das linguagens de programação é realmente uma coisa ruim?

Eu não acho que é automaticamente ruim. O Python é mais lento que o C ++, mas quando os dois são rápidos o suficiente , o Python pode ser a melhor escolha para o problema em questão, mesmo que seja mais lento .

É sempre uma troca. Para pequenas tarefas pontuais, é muito mais rápido escrever um script Python do que um aplicativo C ++ que faz o mesmo (o exemplo típico para mim seria algum tipo de processamento em lote de texto ou percorrer uma árvore de diretórios e fazer algo com os arquivos), e eu realmente não me importo se leva 10 ms ou 1000 ms, mesmo que seja 100x mais lento, porque pode levar metade do tempo para escrever e testar.

Obviamente, seria bom se o Python fosse tão rápido quanto o C ++, então nesse sentido eu concordo com a sua afirmação de que "lento = ruim". Mas então eu prefiro uma linguagem poderosa que corra o mais rápido que eu quero, sem fazer algumas coisas (por exemplo, verificação de limites de matrizes em matrizes brutas), desde que me permita decidir quando fazer essa troca (por exemplo, usando std: :vetor).

Bem simples - ser lento é uma coisa ruim

quando o programa requer um certo nível de desempenho

porque sem esse desempenho você não está cumprindo os requisitos.

Pode ser qualquer coisa, desde um aplicativo de negócios que precisa processar consultas em um período aceitável de tempo até um jogo que precisa exibir muitas informações na tela a qualquer momento. Se o programa não for rápido o suficiente, simplesmente não funcionará .

Veja desta maneira: os computadores são estúpidos . Eles seguem as instruções que qualquer idiota com uma tabela trigonométrica pode seguir. Eles insistem obstinadamente em fazer o que você disse em vez do que você quis dizer. Nem um pingo de autodireção ou intuição. É horrível.

A única coisa que um computador tem para oferecer é: é rápido. Realmente! Um knucklehead com um arquivo pode fazer o mesmo trabalho que um banco de dados. Um cara que trabalha com uma máquina de impressão pode fazer o que o Apache faz. Seriamente! E eles fizeram isso, por centenas e centenas de anos, na verdade. Por que um computador é bom para QUALQUER COISA é a sua velocidade.

Portanto, uma linguagem de programação que (comparada com outras linguagens) falha ao explorar que está perdendo a ÚNICA vantagem de usar computadores.

Uma linguagem de programação pode ser de nível muito alto, "faça muito", ainda seja muito rápida. OCaml é uma linguagem de nível superior ao PHP, mas está produzindo um código quase tão rápido quanto C. Javascript é tão dinâmico quanto PHP, mas pode ser executado muito rapidamente. Portanto, é principalmente um problema com uma implementação de linguagem, não um design. Linguagens dinâmicas são mais difíceis de implementar eficientemente, mas não são impossíveis.

A velocidade pode ser medida em termos de tempo de execução, tempo inicial de desenvolvimento e tempo de manutenção (tempo necessário para resolver problemas / bugs e produzir um novo código e implantá-lo).

As linguagens de script geralmente têm um tempo de execução mais lento, mas um tempo de manutenção mais rápido, porque muitas vezes você pode fazer uma alteração rápida e implantar sem precisar reconstruir um sistema inteiro e, às vezes, sem precisar parar e reiniciar.

Portanto, muito é um equilíbrio, dependendo da velocidade que você precisa.

O contexto também é importante. Carregar sua configuração inicial levando 0,5 segundos em vez de 0,1 segundos não é grande coisa, mas em tempo de execução, levar 0,5 segundos para executar uma consulta em vez de 0,1 segundos pode ser um grande problema se ele tiver que lidar com 100 consultas, levando 50 segundos em vez de 10)

Simples - os clientes adoram software rápido. De fato, todo o objetivo dos computadores é calcular rapidamente.

Lento é relativo. Se eu tiver um requisito para ler uma porta 10 vezes por segundo, um idioma que não pode criar um binário que possa fazer isso é muito lento. Se eu estiver escrevendo um aplicativo Web em que a sequência de solicitação / resposta entre servidor e navegador / cliente é medida em segundos e é provável que o usuário gaste minutos em uma tela antes de clicar em um botão, uma linguagem de programação que pode lidar com o processamento de solicitações em 1 segundo é provavelmente rápido o suficiente (a maioria, é claro, é muito mais rápido).

Obviamente, a linguagem de programação pode ser um fator na determinação da velocidade de execução, mas essa não será a linguagem em si, mas os compiladores e / ou tempos de execução que a acompanham. Isso fica claro no desenvolvimento do Java, onde o desempenho das JVMs (mesmo em ambientes de hardware idênticos) ao longo dos anos aumentou radicalmente. E é claro que sempre é possível escrever código terrivelmente lento em qualquer ambiente que você escolher. Como declarações como "C ++ é dez vezes mais rápido que Java" são automaticamente falsas, a menos que qualificadas e quantificadas sobre exatamente quais condições foram testadas e como. É igualmente possível criar um teste em que o Java é mais rápido que o C ++, tudo depende do que você está usando como código de teste e de como executá-lo.

Como as linguagens de programação não existem para atender aos programadores, elas existem para criar programas para atender aos usuários.

Se você só precisa de uma pequena ferramenta pessoal simples para fazer algo uma vez, ela pode ser tão lenta quanto você deseja. Mas quando você começa a implantar para os usuários, eles se preocupam com a velocidade e o dimensionamento, especialmente se eles vão usá-lo repetidamente. (Por exemplo, um instalador pode ser lento; é melhor que o programa instalado não seja.) E não é apenas o idioma; é o programa em geral. Se o seu programa estiver lento, os usuários não gostarão. E se você tem concorrência, os usuários que não gostam do seu programa são uma coisa muito ruim. Portanto, um idioma que contribui para que os usuários não gostem do seu programa (tornando-o lento) é ruim.

Faço parte de uma equipe que cria software de controle para mídia de transmissão. Há uma boa chance de que sua estação de rádio ou TV favorita esteja funcionando se você estiver nos EUA. O desempenho é uma das coisas que mais ouvimos dos clientes. Foi originalmente escrito para pequenas operações de estação única, mas agora assinamos grandes redes de transmissão e cabo com centenas de canais, e a escala começa a se tornar um problema. Se não podemos fazer as coisas correrem rápido para eles, eles levarão seus contratos de milhões de dólares para as pessoas que puderem, e nós acabaremos sem emprego. É por isso que usamos uma linguagem rápida e compilada e otimizamos o uso de nossos bancos de dados.

Porque mais rápido é melhor. Tempo é dinheiro. Se você escreve um software de servidor e usa uma linguagem de programação mais lenta, compra mais servidores. Se você escreve um software encolhido, perde clientes para os rivais mais rápidos.

Para qualquer tipo de software duradouro usado por pessoas, geralmente o queremos o mais rápido possível. No nível da Assembléia, o tempo de colocação no mercado aumenta demais e não é rentável. É tudo uma troca. Do ponto de vista comercial, pode ser mais lucrativo permitir que os programadores pobres depurem erros de memória em C ++, fazendo isso por vários meses, se isso significa que o produto é mais rápido que seus rivais.

Portanto, a velocidade é realmente importante em muitos softwares. Hoje em dia, linguagens lentas são consideradas "ruins" porque são muito lentas (o Python pode ser facilmente 50x - 100x mais lento, e isso é demais)

Existem linguagens de programação para atender aos programadores.

Não sei como você chegou a essa conclusão. Eu diria: engenheiros de software usam linguagens de programação para suas necessidades.

Algumas linguagens de programação são mais lentas que outras, mas isso não ocorre porque há algo errado com elas.

Esta é também uma declaração flakey. Defina o que você quer dizer usando a palavra 'mais lento' aqui. Mais lento pode significar:

1. Os programas finais, que alcançam a mesma coisa, são executados 'mais lentamente' em um idioma em comparação com outro.
2. O tempo necessário para criar o programa final pode ser mais longo (portanto, alguns o descreveriam como "mais lento").

Esses dois problemas que vêm à mente também estão entrelaçados, onde há algum tipo de troca entre o tempo gasto em desenvolvimento e desempenho.

Como qualquer software, ser lento pode ser um sinal de problemas subjacentes / design incorreto. É certo que o design é um pouco zeitgeist, mas isso não diminui o fato de que os princípios de design nos quais agora se baseia estão desatualizados e considerados "ruins".

Veja o ASP clássico e o ASP.net, por exemplo.

Alguém comentou que "os clientes adoram softwares que atendem aos requisitos e dentro do orçamento". Bem, isso é verdade - mas tem bastante influência no software lento, e isso, quase por definição, significa linguagens de programação mais lentas (e estruturas) e algoritmos e configuração. Uma linguagem de programação lenta é possivelmente a parte mais importante de todas as opções acima, simplesmente porque é uma base da qual você achará mais difícil mudar. Se você usa um banco de dados Oracle e precisa de mais desempenho, pode otimizar as tabelas / index / etc. Fácil. Se você tiver um algoritmo ruim no seu código, poderá escrever um código diferente. Se sua estrutura for lenta, você poderá substituí-la - isso não é tão fácil, mas é factível sem reescrever tudo. Se o seu idioma estiver muito lento, você deverá praticamente iniciar novamente.

Veja no Facebook os problemas que eles enfrentaram para fazer o PHP funcionar rápido o suficiente quando precisavam ser dimensionados.

Para o resto de nós, os 'requisitos de desempenho não funcional' geralmente são gravados em especificações, especialmente para aplicativos da Web escaláveis. O não cumprimento da página 'deve ser exibido ao usuário dentro de 2 segundos após a solicitação "e você perde o contrato (ou paga multas). Portanto, sim, os clientes adoram softwares que executam reqs - e esses reqs dizem que precisa ser rápido . (você pode não se importar quanto tempo os usuários gastam olhando para a ampulheta, mas o cliente com certeza o faz - é um custo enorme).

Por exemplo, em uma grande central de atendimento, disseram-me que eles determinaram que, a cada segundo que você poderia economizar no processo de tomada de chamadas, um atendedor de chamadas poderia ser "reduzido". De repente, é dinheiro real e um grande incentivo para os chefes obterem software mais rápido, eficiente e mais utilizável.

Passa muito tempo se preocupando com os programadores criando códigos o mais rápido possível (e depois testando e refatorando a unidade o tempo todo, risos). Descobri que isso não é um fator tão grande quanto as pessoas pensam - se você é um especialista em seu idioma, pode codificá-lo muito mais rapidamente do que se não tiver experiência. Portanto, um desenvolvedor especialista em C ++ pode escrever código com mais rapidez e precisão do que um desenvolvedor iniciante em PHP. Então, acho que me tornar um especialista é mais importante do que escolher uma linguagem 'fácil' e é por isso que não gosto do culto à 'reescrita nas coisas novas e legais' que parece estar em toda parte hoje.

Vou salientar que a maioria dos problemas de desempenho existe porque o programador fez um trabalho ruim, não porque a linguagem era muito lenta. Realmente, há muitas coisas mais relevantes para se preocupar no desempenho do que o idioma que você escolhe. Isso seria aproximadamente o número 1.203.407º da minha lista.

Então, o desempenho mais lento das linguagens de programação é realmente uma coisa ruim?

Tudo o resto é igual, ir mais rápido é uma coisa boa. Afinal, ninguém realmente quer esperar mais alguns resultados e, uma vez que esse resultado seja feito, pode liberar recursos para outras coisas.

Mas nem tudo o resto é igual. Para iniciantes, também é importante produzir o resultado certo , ou pelo menos o suficiente. (Se resultados completamente errados forem permitidos, você poderá produzi-los com muita rapidez e eles terão exatamente zero valor para qualquer pessoa.) Se uma alteração em um idioma um pouco mais lento aumentar a probabilidade de que o resultado certo seja produzido, normalmente é um ótimo trade-off. As linguagens de nível superior têm uma vantagem sobre as de nível inferior aqui, pois seu conjunto mais rico de modelos geralmente facilita a expressão de um problema complexo sem muitos detalhes explícitos.

Em geral, também é importante gerenciar o custo de produção do software, adicionar novos recursos conforme desejado e mantê-lo funcionando à medida que os sistemas subjacentes mudam. Linguagens de nível superior geralmente permitem uma recuperação mais rápida da programação e há muito valor em manter os custos da programação dentro do orçamento. De fato, manter os custos baixos permite que coisas mais diferentes sejam alcançadas em geral, o que geralmente é uma coisa boa.

O ponto chave final a ser observado é que não é necessário usar apenas um idioma e que muitos sistemas de software têm a maioria de seus componentes que não são críticos para o desempenho. É sensato usar uma linguagem de baixo nível para produzir componentes de alto desempenho para os bits críticos, enquanto deixa as partes menos críticas em uma linguagem de alto nível (para minimizar o custo de produzi-las) é eminentemente sensível. Além disso, os recursos que compõem uma boa linguagem de baixo nível (a capacidade de controlar com precisão o que a máquina faz) não são os recursos que compõem uma boa linguagem de alto nível (a capacidade de inferir os detalhes de descrições muito menores): são diametralmente opostos, portanto, ser capaz de uni-los e usá-los como força e evitar suas fraquezas, é realmente uma grande coisa.

Quais componentes devem receber o tratamento de alto desempenho? A otimização? Meça- os. Perfil deles. Encontre a verdade em vez de adivinhar. Concentre seu esforço onde ele faz mais bem.