Se uma linguagem muda rapidamente, isso é considerado uma coisa boa?

14

Eu tenho visto alguns idiomas que mudam rapidamente (quero dizer, eles são melhorados a cada ano, por exemplo) e outros que são melhorados lentamente.

Minha pergunta, se uma linguagem muda rapidamente, isso é uma coisa boa ou ruim para o programador? Os programadores gostam de aprender coisas novas na língua ou preferem ficar com o que já sabem?

    
por Simon Smith 21.10.2011 / 02:46
fonte

8 respostas

16

if a language changes quickly is this a good thing or a bad thing for the programmer?

Bom

  • As alterações podem adicionar um pouco de açúcar sintático tornando o código futuro mais fácil de escrever com menos erros
  • As alterações podem padronizar um padrão de idioma / design comum que os programadores tiveram que implementar ou confiar em terceiros para.
  • As alterações podem facilitar a integração com tecnologias em que a linguagem é normalmente usada com
  • As alterações podem ajudar a evitar erros comuns
  • As alterações podem invalidar ou eliminar práticas de programação perigosas
  • As alterações podem ter adições úteis à biblioteca padrão da linguagem para coisas que eu costumava ter para me implementar ou confiar em terceiros para.

Ruim

  • A linguagem aumentou a complexidade - novos recursos nem sempre funcionam bem com os recursos legados (ou seja, o relacionamento do C ++ com o C)
  • O código legado pode estar desatualizado e 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 potencialmente várias versões.
  • As bibliotecas de terceiros podem não suportar a versão mais recente do idioma
  • Apesar da existência de um padrão, pode levar algum tempo para encontrar uma maneira padrão / normal de implementar novos recursos e definir alguns dos casos mais obscuros de seu comportamento

Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?

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 ponderar os benefícios dos novos recursos em comparação com o custo de atualização em uma situação específica.

Eu posso me divertir ou gostar de aprender sobre novos recursos, mas no final das contas, o que realmente me interessa é entregar um produto útil a alguém. Eu tenho que escolher o conjunto de ferramentas que será moderno o suficiente para ter razoável suporte e estabilidade, mas não tão antigo que eu não possa ser razoavelmente produtivo.

    
por 21.10.2011 / 03:08
fonte
11

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

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

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

    
por 21.10.2011 / 09:33
fonte
5

Eu quero melhorias regulares, mas não quero que isso quebre uma base de código e & 500 kloc acionar um "projeto de atualização" massivo apenas para fazer o código funcionar da maneira que faz com a versão anterior.

    
por 21.10.2011 / 03:07
fonte
4

A estabilidade do idioma é obrigatória para empresas e desenvolvedores. Mudanças na linguagem são bem-vindas se elas resolverem problemas ou introduzirem recursos que foram perdidos em versões anteriores, mas mudar de idioma de modo que esteja na moda ou apenas porque você quer alcançar um concorrente não é tão bom assim.

Quando o idioma é estável, com o tempo, os desenvolvedores param de concentrar esforços no aprendizado do idioma, porque o teriam dominado e começarão a concentrar seus esforços em servir o negócio 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 o custo e o tempo de aprendizado. Nem todos os empregadores estão dispostos a educar os desenvolvedores em novos recursos. Isso adiciona uma carga significativa aos desenvolvedores para se treinarem ou então - isso não é trivial, os cursos especializados podem custar entre US $ 1.500 e US $ 3.500 cada!

Mudanças contínuas podem bloquear desenvolvedores em softwares 'legados'. Tomemos o caso do desenvolvedor de ASP que não pegou com o MVVM daqui a 2 anos ou o caso de um desenvolvedor do Windows Forms que não aprendeu o WPF. Esse bloqueio pode prejudicar significativamente a carreira do desenvolvedor.

Horas extras, a arquitetura do software em um negócio torna-se uma salada de jardim. Todos os tipos de ferramentas e versões e você encontra projetos começando a fazer nada além de atualizar o software de uma versão para outra sem nenhum ganho comercial.

    
por 21.10.2011 / 06:00
fonte
2

Eu não acho que haja uma resposta certa.

De um modo geral, quando uma linguagem é relativamente jovem, há muito mais liberdade para fazer mudanças relativamente grandes com relativa rapidez. 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 a língua envelhece, supondo que ela se torne um usuário suficientemente amplo para qualquer um se importar, a base do código existente começa a restringir cada vez mais as mudanças que podem ser feitas. Não só há mais código fazendo uso de mais recursos, como também é mais difícil adivinhar quais alterações podem quebrar o código, mas as expectativas das pessoas mudam.

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

Acho que também depende muito da percepção das pessoas sobre o idioma para começar. As pessoas que escolhem uma linguagem porque é "de ponta" têm muito mais probabilidade de suportar grandes alterações que quebram muitos códigos existentes, se isso for necessário para manter na aresta de corte.

Outro fator é o tamanho e a expectativa de vida dos projetos para os quais a linguagem é pretendida. Uma linguagem que atende a projetos relativamente pequenos ou aqueles que conhecemos antecipadamente tem uma expectativa de vida curta (por exemplo, uma interface web) pode acabar quebrando 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 jeito. Uma linguagem (por exemplo, C ++ ou Java) que atende mais a projetos maiores e mais duradouros que podem levar, digamos, 5 anos para chegar a um lançamento inicial, pode estar em uso regular (e desenvolvimento contínuo) por três ou quatro décadas um ótimo oferece mais estabilidade.

    
por 21.10.2011 / 06:57
fonte
2

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

Outro adora o C # e não conhece todas as palavras-chave ou conhece as bibliotecas do .NET 4 (async e todas) e não usou as palavras-chave abstratas ou 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 libs ou código compilado) as pessoas se importarão.

    
por 21.10.2011 / 09:43
fonte
0

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

Essa mudança de recurso causa alguns problemas quando você está se aproximando de um "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)

Diferentes estilos de verificação de tipos

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

Nem sempre fica claro quando você quer usar um ou outro.

    
por 21.10.2011 / 12:21
fonte
0

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

    
por 21.10.2011 / 15:01
fonte