Se um idioma muda rapidamente, isso é considerado uma coisa boa?

Vi alguns idiomas que mudam rapidamente (quero dizer, eles são aprimorados todos os anos, por exemplo) e outros que são aprimorados lentamente.

Minha pergunta, se um idioma muda rapidamente, isso é bom ou ruim para o programador? Os programadores gostam de aprender coisas novas no idioma ou preferem manter o que já sabem?

se um idioma muda rapidamente, isso é bom ou ruim para o programador?

Boa

• As alterações podem adicionar um bom açúcar sintático, facilitando a gravação de códigos futuros com menos bugs
• As alterações podem padronizar um padrão de idioma / design comum para o qual os programadores tiveram que se implementar ou confiar em terceiros.
• As alterações podem facilitar a integração com tecnologias com as quais o idioma é normalmente usado.
• As alterações podem ajudar a evitar erros comuns
• As alterações podem descontinuar ou eliminar práticas perigosas de programação
• As alterações podem ter adições úteis à biblioteca padrão do idioma para coisas que eu costumava ter para me implementar ou confiar em terceiros.

Mau

• A linguagem adicionou complexidade - novos recursos nem sempre funcionam bem com os recursos herdados (ou seja, o relacionamento do C ++ com o C)
• O código legado pode estar desatualizado e pode não funcionar mais na nova versão do idioma sem atualizações (Python 2.x -> 3.x)
• Compiladores e outras ferramentas para o idioma precisam ser atualizados. Agora existem várias versões potencialmente.
• Bibliotecas de terceiros podem não suportar a versão mais recente do idioma
• Apesar da existência de um padrão, pode levar tempo para encontrar uma maneira padrão / normal de implementar novos recursos e definir alguns dos casos mais obscuros de seu comportamento.

Os programadores gostam de aprender coisas novas no idioma ou preferem manter o que já sabem?

Muitos programadores gostam de satisfazer sua curiosidade jogando com os novos recursos. No entanto, isso não significa que os novos recursos sejam sempre apropriados no código de produção. Essa é uma decisão caso a caso que deve avaliar os benefícios dos novos recursos versus o custo da atualização na situação específica.

Posso me divertir ou gostar de aprender sobre novos recursos, mas no final do dia o que realmente me importa é entregar um produto útil a alguém. Tenho que escolher o conjunto de ferramentas que será moderno o suficiente para ter suporte e estabilidade razoáveis, mas não tão antigo que não possa ser razoavelmente produtivo.

As melhorias são ótimas ... se forem compatíveis com versões anteriores .

C # faz isso muito bem. Eles acrescentam expressões lamdba às coisas, melhor suporte para multithreading, linq, ... Mas seu programa C # 2.0 de cinco anos ainda funcionará bem sem a necessidade de alterações e pode ser facilmente atualizado para o C # 4.0 sem a necessidade de alterações.

Aprender coisas novas é ótimo se estiver permitindo que você execute suas tarefas de maneira mais fácil e rápida. Se gastar uma hora de aprendizado significa economizar suas horas em tempo de desenvolvimento, vale a pena.

Quero melhorias regulares, mas não quero que ele quebre uma base de código de 500 kloc e inicie um "projeto de atualização" maciço apenas para fazer o código funcionar da maneira que funciona com a versão anterior.

A estabilidade da linguagem é uma obrigação para os negócios e para os desenvolvedores. Alterações no idioma são bem-vindas se resolverem problemas ou introduzirem recursos que foram perdidos em versões anteriores, mas alterar o idioma para que fique na moda ou apenas porque você deseja conversar com um concorrente não é tão bom.

Quando o idioma é estável, com o tempo, os desenvolvedores param de concentrar esforços no aprendizado do idioma, porque eles o dominariam e começariam a concentrar seus esforços em servir os negócios com o que sabem. O resultado é um projeto mais curto, usuários finais felizes e desenvolvedores mais orgulhosos!

A mudança também vem com tempo e custo de aprendizado. Nem todos os empregadores estão dispostos a educar os desenvolvedores sobre novos recursos. Isso adiciona uma carga significativa para os desenvolvedores se treinarem ou não - isso não é trivial, cursos especializados podem ser de US $ 1500 a US $ 3500 cada!

A mudança contínua pode bloquear os desenvolvedores no software 'legado'. Veja o caso do desenvolvedor do ASP que não encontrou o MVVM daqui a dois anos ou o caso do desenvolvedor do Windows Forms que não aprendeu o WPF. Esse bloqueio pode prejudicar significativamente a carreira do desenvolvedor.

Com o tempo, a arquitetura do software em uma empresa passa a parecer uma salada de jardim. Todo o tipo de ferramentas e versões, e você encontra projetos que começam a fazer nada além de atualizar o software de uma versão para a seguinte sem nenhum ganho comercial.

Eu não acho que exista uma resposta certa.

De um modo geral, quando um idioma é relativamente jovem, há muito mais liberdade para fazer alterações relativamente grandes relativamente rapidamente. Não há uma grande base de código existente para quebrar, então as pessoas geralmente são muito mais abertas à experimentação.

À medida que o idioma envelhece, supondo que ele seja amplo o suficiente para que alguém realmente se importe, a base do código existente começa a impor restrições cada vez maiores sobre as mudanças que podem ser feitas. Não apenas há mais código fazendo uso de mais recursos, como é mais difícil adivinhar quais mudanças podem quebrar o código, mas as expectativas das pessoas mudam.

Apenas por exemplo, vamos assumir que havia aproximadamente o mesmo número de pessoas escrevendo Ruby e Fortran. Além disso, vamos assumir que havia a mesma quantidade de código em ambos. Eu diria que as chances são muito boas de que uma mudança que quebrou exatamente a mesma porcentagem de cada uma (e de uma maneira que levou o mesmo trabalho a ser corrigido) seria muito mais aceitável para os usuários de Ruby do que para os usuários do Fortran como regra geral. (pelo menos assumindo que eles viram isso como uma melhoria).

Eu acho que também depende muito da percepção das pessoas sobre o idioma para começar. As pessoas que escolhem um idioma porque é "de vanguarda" têm muito mais chances de suportar grandes mudanças que quebram muitos códigos existentes, se é isso que é necessário para mantê- lo na vanguarda.

Outro fator é o tamanho e a expectativa de vida dos projetos aos quais o idioma se destina. Um idioma que atende a projetos relativamente pequenos ou que conhecemos de antemão tem uma expectativa de vida curta (por exemplo, uma interface da web) pode acabar quebrando as coisas com relativa frequência, porque é improvável que muitas pessoas continuem usando a mesma base de código por, digamos, 10 anos de qualquer maneira. Uma linguagem (por exemplo, C ++ ou Java) que atenda mais a projetos maiores e de maior duração, que podem levar, digamos, 5 anos para chegar a um release inicial, pode estar em uso regular (e desenvolvimento contínuo) por três ou quatro décadas, obviamente, exige uma grande estabilidade muito mais.

Eu tinha um cara que me disse que gosta do C ++ e vai continuar assim. Ele não se importa ou tem interesse em D, ele não quer saber nem usar C #. Ele aprendeu java porque tinha feito muitos projetos que precisava fazer e, aparentemente, faz um bom trabalho nos idiomas que conhece

Outro ama o C # e não conhece todas as palavras-chave ou conhece as bibliotecas do .NET 4 (assíncronas e todas) e não usou as palavras-chave abstratas nem os atributos usados.

Estou simplesmente dizendo que a maioria das pessoas NÃO SE IMPORTA

Agora, os efeitos da atualização estão quebrando (para bibliotecas ou código compilado) as pessoas SE importarão.

Eu responderei pelo C # (mas essa análise também pode ser aplicada ao Scala):

Essa alteração de recurso causa alguns problemas quando você está abordando o "estilo" de um idioma:

Em 2011, o C # pode fazer muitas coisas diferentes, e isso é bom. Infelizmente, ele tem dois paradigmas diferentes (se não mais):

• OOP
• Funcional (pense em funções lambda e LINQ)

Estilos de verificação de tipo diferente

• Digitação dinâmica
• Digitação estática

Nem sempre é claro quando você deseja usar um ou outro.

Eu acho que realmente depende do idioma e do seguinte que o idioma possui. Por exemplo, acho que se C # e Java começassem a apresentar mudanças em um ritmo mais rápido, isso seria aceito (desde que sejam compatíveis com versões anteriores, como Carra disse). No entanto, se o idioma ainda não ganhou força e ainda está mudando rapidamente, sei que não me incomodaria com isso, pois há uma chance de que o que eu tento aprender hoje seja totalmente diferente do que sai em 6 meses e uma vez que a linguagem é nova / impopular, não seria prejudicial para mim (leia-se: minha carreira) que eu a transmitisse.