Que tipo de papel a “história cultural da linguagem” desempenha com uma plataforma?

15

Recentemente, deparei com este artigo de alguns anos atrás. Argumenta que diferenças significativas na cultura em torno de VB e C #, não as diferenças reais na linguagem, contribuem para que os codificadores C # sejam geralmente mais talentosos do que os codificadores VB. Obviamente, isso causou muitas guerras pelas chamas e a questão de se C # ers ou VBers são mais burros nunca será respondida. Dito isto, os escritores afirmam que a cultura em torno de uma determinada plataforma contribui para a qualidade da equipe ainda poderia ser plausível. Por exemplo, mesmo que o Java seja mais eficiente para desenvolver aplicativos no momento, uma equipe de desenvolvedores do Google Go provavelmente terá um nível de calibre maior do que uma equipe de desenvolvedores Java, já que para aprender Go, um desenvolvedor provavelmente ser um pioneiro e um hacker de fronteira. Então, em poucas palavras, como a cultura que envolve uma plataforma ou outra afeta a qualidade do desenvolvedor médio nessa plataforma, se é que ela existe?

    
por Morgan Herlocker 04.05.2011 / 21:29
fonte

3 respostas

7

Realmente pergunta interessante. Minha opinião pessoal é que é uma que é feita com demasiada frequência e realmente não tem água alguma.

Os kiddies de script (e empresas que os contratam) permitem que o idioma de escolha determine seu status entre os escalões de "programadores". Os bons engenheiros não se importam com a linguagem escolhida, mas concentram-se em resolver os problemas dados da maneira mais ideal (obviamente ótima é uma afirmação geral e pode ser aplicada a muitos fatores diferentes). Se isso é C #, VB, C ++, Python ou assembly escrito à mão, não importa, pois há um claro benefício em usar essa tecnologia para resolver o problema.

Então, em suma, acho que é mais valioso olhar para a complexidade dos problemas que se resolve em uma base regular, em oposição à linguagem que eles usam para resolvê-los.

Apenas meus dois centavos no assunto:)

    
por 04.05.2011 / 21:46
fonte
4

A qualidade do código desenvolvida em cada uma dessas linguagens é baseada nessas filosofias fundamentais e menos nos desenvolvedores individuais

Cada idioma tem uma cultura em torno dele, porque cada idioma foi desenvolvido por uma razão por alguém com uma agenda e uma filosofia subjacente a por que sua linguagem seria melhor em algo do que existia na época foi criada.

Como as religiões, as linguagens de programação tendem a atrair pessoas que já têm a mesma predisposição para os principais princípios e filosofias do criador da linguagem.

Exemplo sobre a qualidade percebida das soluções

Em um acampamento da Microsoft você tem:

The C# philosophy is that it is more purely Object Oriented, promotes more modern idioms and requires more knowledge to do it correctly and thus should provide more higher quality solutions. This is what draws people to it over VB.

No outro campo da Microsoft:

The VB philosophy is I can quickly and with little knowledge or effort build something that will let someone click a button and do something useful and of business value, how it does it isn't so important. This is what draws people to it over C#.

Aqui estão algumas palavras que falam sobre línguas e filosofias:

Perl people tend to care about the exact opposite thing Python people care about.

Java people care about making money.

JVM languages ( Groovy, Scala ) care about the JMV and not about Java the language.

All the Microsoft specific languages (VB,C#,F#, managed C++) tend to care about making money on Windows.

Erlang people care about stuff everyone other people haven't needed to care about, and don't appreciate what they don't know.

Lisp people don't care about what anyone else thinks they care about.

O que esses grupos se preocupam em moldar a linguagem, seu desenvolvimento e sua comunidade.

As filosofias mudam com a experiência e a necessidade

Adotei o ASM e o BASIC porque em 1983 isso era tudo que você tinha. Eu queria escrever jogos e demos, essas eram as ferramentas para fazer isso. Principalmente ASM para demonstrações.

Adotei o C e depois o C ++ de volta quando era a única maneira de escrever coisas como renderização 3D e praticamente qualquer outra coisa que fosse espacial e temporal. Não foi ASM, então eu aprendi isso.

Adotei o VB para ganhar dinheiro, era o mais parecido com os ambientes de desenvolvimento Scala, Director e CanDo que eu estava acostumado no Amiga. Concordei com a filosofia de desenvolvimento rápido

Adotei Java cedo para ganhar dinheiro melhor. Eu ganhei dinheiro com a VB até 1999 e deixei para trás quando o Java 1.2 ficou estável e maduro e a web já tinha entrado em ação até então, eu tinha 4 anos de experiência em Java quando as pessoas realmente começaram a levar isso a sério. Eu concordei com o escrever uma vez, executar em qualquer lugar em que quanto mais lugares meu código funcionasse mais fácil seria capaz de vendê-lo. filosofia.

Eu adotei o Python no final de sua linha do tempo, em 2005, porque ele arranhou uma coceira que o Java não tinha. Eu precisava escrever rapidamente o código para usar algumas bibliotecas que estavam disponíveis apenas em C e também precisei criar protótipos de serviços web rápidos e rápidos Python foi mais rápido e menos código para fazer a mesma coisa em Java. Algumas coisas foram para a produção, como Java, alguns ficaram em Python, muitas coisas nunca chegaram à natureza. Eu concordei com suas baterias incluídas, filosofias idiomáticas únicas, assim como as outras.

Adotei Lua quando precisei colocar um mecanismo de script leve em meus programas C ++ e Java. Isso foi muito antes do suporte ao JSR233 em Java. Eu concordei com a inclusão de uma linguagem de script com todos os recursos, que é fácil de usar, deve ser uma filosofia Lua simples.

Adotei o Erlang em 2006 quando comecei a precisar de grande escalabilidade e execução multi-core relativamente indolor em problemas altamente paralelos e ter execução em várias plataformas. ** Concordo com o seu estado não compartilhado, passagem de mensagens, filosofia estatal imutável. * 8

Adotei o Objective-C quando comecei a precisar criar aplicativos OSX e iOS. Eu concordo com o seu adicionar apenas o direito de Orientação de Objeto para C para torná-lo melhor filosofia. Também para ganhar mais dinheiro.

Adotei o JavaScript oficialmente em 2009 porque concordei com a filosofia do CouchDB e ele usa JavaScript. Ainda não gosto de JavaScript quando tenho que lidar com o DOM.

Eu ainda não adotei o Lisp oficialmente, mas vou finalmente! Eu concordo com os seus Aqueles que não conhecem o lisp estão condenados a reinventar a filosofia .

    
por 04.05.2011 / 23:04
fonte
0

Uma questão interessante, de fato. É um daqueles em que você entende a resposta no nível subconsciente, mas se esforça para colocá-lo em palavras.

É melhor visto como um ciclo de causalidade.

A cultura é responsável pela composição "étnica" dos desenvolvedores atraídos pela plataforma. Essa composição, por sua vez, define as qualidades do programador "médio". A qualidade dos desenvolvedores que agora usam a plataforma influencia a cultura ou sua percepção externa, o que consequentemente afeta os desenvolvedores que chegam à plataforma ou a deixam. O valor da "qualidade" muda como resultado.

Estou tentando criar regras específicas, mas acho difícil generalizar. Precisamos investigar separadamente cada plataforma. Algumas observações que fiz:

  • A velocidade com que uma determinada plataforma é desenvolvida, estendida e melhorada tem uma correlação direta com a qualidade dos desenvolvedores. O fluxo constante de novos recursos e ferramentas brilhantes atrai desenvolvedores entusiastas (que, em média, são mais capazes de trabalhar com qualidade) e repele mentes conservadoras que estão irritadas com o esforço constante de aprendizado.

  • Os menores limites que uma plataforma oferece, mesmo à custa de um risco maior de se atirar no pé, atraem igualmente mentes experimentais entusiasmadas

  • Quanto mais complexas são as coisas que alguém precisa entender e dominar para usar a plataforma, igualmente atrai indivíduos resolvidos e assusta desenvolvedores preguiçosos

por 04.05.2011 / 22:14
fonte