Escolhendo uma linguagem de programação sistematicamente [fechado]

Estou procurando uma metodologia para escolher um idioma. Não estou pedindo opiniões sobre idiomas. Fui encarregado do processo de comparar o idioma atual da nossa loja com outros que estão disponíveis. Somos uma loja de desenvolvimento web btw.

Nosso CEO gostaria de um white paper completo sobre todas as linguagens disponíveis na Web, de que idioma pai elas derivam (por exemplo, jsp é de java que é de c / c ++). Eu preciso criar uma matriz com todos os fatores-chave de um idioma específico e as deficiências desse idioma. A linguagem é limitada pela plataforma, é projetada para programação funcional, processual ou OO ou pode ser usada com qualquer paradigma de programação?

Também preciso ter informações menos técnicas, como o tamanho do pool de talentos para um determinado idioma e o salário médio nesse pool. Como o mercado verá nossa escolha?

Começamos a procurar um consultor para nos ajudar a entender todas essas coisas, mas o que descobrimos é que a maioria dos consultores tem experiência em desenvolvimento e, muitas vezes, parece que a resposta é " xxx é a melhor linguagem porque é a que eu utilizaram mais nos últimos n anos e isso nunca me decepcionou. Você pode complementá-lo com aaaa para front end e usar a biblioteca zzz "

Estou me sentindo sobrecarregado com essa tarefa e sinto que o melhor curso de ação, dado o que nosso CEO está procurando, é procurar no mundo da academia e contratar um professor sem experiência real de desenvolvimento para nos "ensinar" sobre todos os idiomas possíveis.

Alguém mais teve que passar por esse exercício? Se você tem, pode compartilhar as etapas e / ou metodologia que costumava seguir no processo?

O @FrustratedWithFormsDesigner sugeriu isso acima, vou ser mais direto: você foi acusado de uma tarefa cara, mas inútil.

Suspeito que o CEO esteja procurando evidências objetivas e irrefutáveis ​​que possam apoiar sua escolha de idioma. O problema é que a preferência pela linguagem é carregada com muitos fatores subjetivos e extrínsecos para que o white paper seja significativo e muito menos útil.

Dito de outra forma, se houvesse uma linguagem ideal, todos estariam usando-a, em vez dessas línguas "objetivamente" defeituosas. Também indica um grau de microgerenciamento que deve ser a província dos engenheiros que terão que fazê-lo funcionar. Erlang pode ser o "objetivamente o melhor", mas se ninguém souber, adicione um custo inicial de 6 meses / engenheiro e mais 6 meses / engenheiro para ganhar competência.

Como não tenho seu emprego, não estou preocupado em perdê-lo, embora você possa. Eu daria ao CEO um artigo sobre a Tese da Igreja Física-Turing. Eu, então, me reunia com os engenheiros seniores e obtinha sua opinião não rigorosa e não objetiva sobre o que deveria ser usado e dizia ao CEO que é isso que você deve usar. Em troca, você promete que os engenheiros ficarão fora das reuniões do conselho, CFOs, métodos de contabilidade, seleção de vice-presidentes e assim por diante. Há uma razão pela qual nos especializamos, e ele não tem mais lugar nas preferências de engenharia do que você no domínio dele.

Algumas pinceladas amplas a serem consideradas:

Popularidade do idioma

Isso realmente não deveria importar, porque a popularidade não equivale necessariamente à produtividade, expressividade ou a qualquer outra qualidade linguística que importa mais, mas essa consideração geralmente supera todas as outras considerações porque:

1. É mais fácil encontrar desenvolvedores de software em um idioma popular.
2. É mais fácil encontrar ferramentas e bibliotecas em um idioma popular.
3. Os tomadores de decisão não entendem as trocas de idiomas, portanto tomam a decisão segura ("muitas empresas usam esse idioma, portanto deve ser bom").

Aplicabilidade ao domínio do problema

Qualquer programa pode ser escrito em qualquer linguagem de programação completa de Turing, mas algumas linguagens são mais adequadas para determinados domínios de problemas do que outras. Se você estiver escrevendo aplicativos da Web, provavelmente gravitará em linguagens e ferramentas adequadas para isso, e provavelmente serão linguagens orientadas a objetos.

Por outro lado, se você estiver escrevendo um software baseado principalmente em pesquisas ou em matemática, provavelmente gravitará em linguagens que adotam paradigmas funcionais .

E, claro, há tudo no meio. Muitas linguagens suportam múltiplos paradigmas, e alguns padrões de software existem apenas para superar limitações nessas linguagens que carecem de certos recursos ou paradigmas.

Expressividade e produtividade

Alguns idiomas são mais expressivos que outros. O que pode ser escrito em um idioma usando mil linhas de código pode ser escrito em um idioma mais expressivo usando cem linhas de código. A desvantagem é que as centenas de linhas de código provavelmente são escritas em um idioma menos popular, por pessoas com maior experiência.

Muitas das linhas de código presentes nas linguagens orientadas a objetos usadas para escrever aplicativos de linha de negócios são cerimônias. Essa cerimônia, apesar de custar tempo e esforço para se desenvolver, também fornece uma estrutura visível que de outra forma não seria prontamente aparente em uma linguagem mais expressiva. Ele permite que pessoas com menos experiência do que precisariam trabalhar no código com uma quantidade reduzida de risco.

A era de vários idiomas

Concluirei afirmando que o desejo de decidir sobre um único idioma pode ser um dilema falso. Hoje, os aplicativos geralmente são escritos, não em um, mas em vários idiomas. Cada idioma tem suas próprias forças e (em teoria) é projetado especificamente para a tarefa que está sendo usada. Alguns domínios problemáticos (como lógica do navegador da Web ou acesso ao banco de dados) requerem idiomas específicos.

Existem motivos comerciais para escolher um idioma, e motivos de engenharia para escolher um idioma, e os dois nem sempre se encontram. Jogar por razões acadêmicas provavelmente tornará as coisas piores. Duvido que um professor possa ajudá-lo da maneira que você precisa.

Os fatos sobre a ancestralidade e os recursos de um idioma são bastante fáceis de encontrar. Você provavelmente poderia passar um dia na wikipedia para preencher a maior parte disso. O tamanho e o salário dos talentos são mais difíceis, porque a maioria das pessoas não se considera programadora em um único idioma. As empresas que usam idiomas menos populares como o Scala esperam contratar bons programadores gerais que não têm experiência específica em idiomas. A julgar pelas apresentações que vi, essa estratégia parece ter funcionado bem.

Mesmo sabendo dos fatos, você ainda tem uma escolha bastante subjetiva. Seu CEO deseja que ele se reduz a uma métrica aproximada, como dólares por recurso. Para obter uma imagem precisa, você terá que fazer alguns protótipos e depois falar sobre o quão fácil foi aprender, quão rápido foi escrever um protótipo depois que você aprendeu o básico, o quão fácil você acha que seria manter e quão amplamente aplicável você acha que seria para o tipo de trabalho que você normalmente faz.

Em vez de tentar abranger todas as linguagens, eu procuraria obter representantes dos diferentes paradigmas de programação e tipos de estruturas e implementar um protótipo em cada uma.

Aqui está uma lista aproximada de categorias de back-end:

• Microsoft (Pode ter subcategorias. Não sei nada sobre elas.)
• OOP pesado, como Drupal.
• OOP leve, como uma garrafa de python.
• Tocar / levantar / scalatra usando Scala.
• Jogar / levantar usando Java.
• Primavera.
• Struts-like.
• Rails-like.
• Baseado em Haskell.
• Node.js

No front end:

• JavaScript no estilo OOP
• JavaScript de estilo funcional, como no Underscore
• JavaScript de estilo reativo, como o Bacon
• Google Web Toolkit
• Olmo

Passar um dia ou dois em cada categoria, implementando um protótipo simples, levaria alguns meses, após os quais você teria uma idéia muito melhor dos pontos fortes e fracos de cada um. Talvez você possa descartar algumas coisas mais rapidamente com base na cultura ou na experiência da sua empresa.

Como este é um relatório comercial, também levaria algum tempo pesquisando coisas como "Qual idioma a <empresa> usa", substituindo várias empresas que você admira. Muitos deles escreveram seus próprios whitepapers sobre por que fizeram escolhas específicas de idioma, o que faria excelentes referências para você incluir.

Identifique e custe as deficiências inerentes ao seu processo de desenvolvimento existente como $ A. Identifique o custo da mudança para qualquer outro processo de desenvolvimento como $ B.

Se $ A for menor que $ B, pare.

Se suas deficiências conhecidas superam o custo da mudança (e isso é um grande se!), Analise as deficiências em detalhes e comece a procurar por mudanças no processo de linguagem / ambiente de desenvolvimento / desenvolvimento que as resolvam, uma que não apresentará outros problemas mais caros.

Para ser honesto, a menos que você esteja tentando desenvolver aplicativos da Web no Fortran, o único impacto que o idioma que você usar terá será sobre o custo dos contratados que você usa para preencher as lacunas. O fluxo principal e os processos / ferramentas / desenvolvimento maduros já resolveram a maioria dos problemas que você provavelmente enfrentará, onde as ferramentas mais quentes, mais recentes e mais sexy vêm com os treinadores e contratados mais caros, mas com as soluções menos maduras. E se você tiver deficiências que justifiquem essa alteração, é improvável que sua escolha de idioma os atenda totalmente.

No entanto, se a lucratividade não é o objetivo principal aqui, você precisa levar em consideração o estigma de ser considerado antiquado e os elogios de ser de vanguarda. Peça ao seu chefe os valores em dólares a serem usados ​​nesta parte da equação.