Armadilhas do mundo real da introdução de F # em uma grande base de código e equipe de engenharia [fechado]

Sou CTO de uma empresa de software com uma grande base de código existente (toda em C #) e uma equipe de engenharia considerável. Eu posso ver como certas partes do código seriam muito mais fáceis de escrever em F #, resultando em tempo de desenvolvimento mais rápido, menos bugs, implementações paralelas mais fáceis, etc., basicamente ganhos gerais de produtividade para minha equipe. No entanto, também vejo várias armadilhas de produtividade da introdução do F #, a saber:

1) Todo mundo precisa aprender F #, e não é tão trivial quanto mudar de, digamos, Java para C #. Os membros da equipe que não aprenderam F # não poderão trabalhar nas partes F # da base de código.

2) O conjunto de programadores F # contratáveis ​​a partir de agora (dez / 2010) é inexistente. Pesquise em vários engenheiros de software retomar bancos de dados para "F #", assim como menos de 1% dos currículos contêm a palavra-chave.

3) O apoio da comunidade a partir de agora (dezembro de 2010) está menos disponível. Você pode pesquisar no Google quase qualquer problema em C # e encontrar alguém que já tenha lidado com isso, não com F #. O suporte a ferramentas de terceiros (NUnit, Resharper etc.) também é superficial.

Percebo que isso é um pouco complicado, ou seja, se pessoas como eu não usam F #, a comunidade e as ferramentas nunca se materializam etc. Mas, eu tenho uma empresa para administrar, e posso ser de ponta, mas borda não sangrando.

Quaisquer outras armadilhas que eu não estou considerando? Ou alguém quer refutar as armadilhas que mencionei? Penso que esta é uma discussão importante e gostaria de ouvir seus contra-argumentos neste fórum público que podem fazer muito para aumentar a adoção de F # pela indústria.

A pesquisa é retomada para outras linguagens funcionais, como Scheme, Lisp ou Haskell. Muitas pessoas aprendem isso na escola e as têm em seus currículos; Tenho certeza que muitos deles não se importariam em aprender F #. Eu tenho o Scheme no meu currículo, embora nunca o tenha usado depois da escola e um trabalho envolvendo F # provavelmente também chamaria minha atenção.

Quaisquer outras armadilhas que eu não estou considerando?

Na prática, o principal erro que vejo as pessoas cometem é tentar forçar o uso de F # para problemas em que é a ferramenta errada para o trabalho.

Ou alguém quer refutar as armadilhas que mencionei?

Todas são obviamente preocupações válidas até certo ponto, mas eu questionaria até que ponto.

Por exemplo, você diz que todos teriam que aprender F # para trabalhar no código F #. Embora seja verdade, isso não é grande coisa na prática. Aprender F # não é mais significativo do que aprender WPF, Silverlight ou TPL. Estou ensinando a cerca de 30 desenvolvedores como usar o F # para um cliente em Londres no momento e cerca de uma dúzia estavam trabalhando em tempo integral no código F # após apenas algumas semanas e eles acabaram de lançar seu primeiro produto (dentro do prazo e do orçamento! ) escrito quase inteiramente em F # depois de apenas alguns meses. De fato, eles tiveram mais dificuldades técnicas com o Silverlight do que o F # e consideraram o suporte técnico do Silverlight muito pior do que o do F #.

Você se refere ao pool relativamente pequeno de programadores de F # disponíveis, mas, novamente, dado o quão fácil é pegar o F #, não acho que essa seja uma preocupação significativa. Duvido que você precise contratar muitos, se houver. Meu cliente tem dois funcionários do F # para mais de 100 programadores e nosso trabalho é propagar e supervisionar o uso do F #.

Sua terceira e última preocupação diz respeito a menos suporte da comunidade, pesquisar no Google soluções para C # versus F # e suporte a ferramentas de terceiros. Mais uma vez, não achei que isso seja problemático na prática. Enviei um e-mail para fsbugs com um comentário sobre unidades de medida em F # e recebi uma resposta em 24 horas do pesquisador que o inventou com uma explicação detalhada de por que minha interpretação estava errada e por que funciona da maneira que funciona. Eu nunca recebi isso de Anders Hejlsberg ;-). Eu procuro por soluções o tempo todo e as encontro escritas em C #, VB ou até IronPython, mas, em três anos de uso do setor de F #, consigo lembrar apenas uma única instância em que traduzir a solução em F # não era trivial. De fato, recentemente converti a amostra C # do serializador de dados do MSDN para F # e era 5 × mais curta. Por fim, você mencionou o suporte ao F # em ferramentas como o NUnit quando uso o NUnit do F # sem problemas há algum tempo. Essas são ferramentas .NET, não ferramentas C #.

Estudo de caso : Meu cliente atual não está apenas usando o NUnit para testes de unidade, mas eles criaram o TickSpec em F # sobre o NUnit como uma alternativa tecnicamente superior ao SpecFlow para BDD. O autor fez questão de me mostrar que o TickSpec é uma fração minúscula do tamanho do SpecFlow e oferece mais recursos. Além disso, vários desenvolvedores que trabalham com nenhuma experiência anterior em F # (e, acredito, nenhuma experiência anterior em programação funcional) o adquiriram e começaram a usá-lo em projetos não relacionados sem problemas, precisamente porque o F # + TickSpec facilita a solução de problemas. problemas

FWIW, dei ao meu cliente uma assinatura de site gratuita do nosso F # .NET Journal, que caiu bem com muitos dos desenvolvedores que aprendiam F #.

HTH!

Como você reconhece no seu primeiro ponto, seus programadores que não conhecem o F # não podem trabalhar na parte F # da sua base de código. No entanto, você não precisa reescrever toda a sua base de código em F # para obter vantagens com o uso - basta reescrever as partes em que você obteria o maior benefício. O fato de o F # interoperar muito bem com o C # deve tornar relativamente fácil esculpir determinadas peças e criar montagens F # a partir delas.

Se você tivesse seus engenheiros trabalhando em um aplicativo tradicional de três camadas, provavelmente não insistiria que todos precisassem ter um conhecimento profundo de SQL, HTML, Javascript, CSS etc. Em vez disso, naturalmente, alguns especialistas trabalhariam. em diferentes partes do aplicativo. Portanto, não acho que adicionar um novo idioma para uma parte do seu aplicativo seja um grande obstáculo. Além disso, você pode usar padrões de codificação e outras práticas para tentar garantir que seu código F # seja legível, mesmo por engenheiros sem um profundo conhecimento de F #.

As armadilhas da adição de F # aos idiomas usados ​​incluem as armadilhas da introdução de qualquer nova tecnologia. Independentemente dos benefícios, se alguns de sua equipe não quiserem ou não forem flexíveis o suficiente para aprender, eles não poderão trabalhar em projetos de F #. No entanto, se você permitir que os dinossauros de sua equipe impeçam a adoção de novas tecnologias, sua empresa estará condenada.

As únicas armadilhas que experimentei pessoalmente são:

1. Dificuldades ao depurar. Seguir o fluxo de execução de um programa baseado em expressão em um depurador projetado para linguagens baseadas em instruções pode ser complicado.

2. Intellisense frustrante. A conclusão automática para de funcionar exatamente quando você precisa. A Microsoft deve trabalhar para tornar o analisador de segundo plano mais tolerante a falhas.

3. A sintaxe sensível ao recuo torna difícil copiar e colar ou reformatar o código.

4. Falta de refatoração.

5. Algumas das convenientes extensões VS existentes para F # (dobra de código, coloração profunda) são um pouco lentas, tornando a experiência de digitação um pouco frustrante.

Na minha opinião, nenhuma dessas questões é um impeditivo, e eu posso viver com elas por enquanto. As ferramentas são mais fáceis de melhorar e corrigir do que os idiomas.

Seus medos de que contratar novos programadores capazes de escrever em F # seriam difíceis são bastante comuns, mas na minha opinião são injustificados. Se você escrevesse diretrizes de codificação, desaconselharia ou proibiria qualquer um dos seguintes recursos em C # yield return:, LINQ para objetos, lambdas, o próximo async?

Se você acredita que esses recursos ajudam a escrever um código melhor, não há motivo para não usar o F #. A linguagem suporta esses recursos de maneira suave e bem pensada, o que o C # não pode realmente fazer devido ao seu legado.

Se sua equipe é inteligente o suficiente para entender os conceitos por trás dos recursos que mencionei, eles têm tudo o que precisam para serem excelentes programadores em F #. O mesmo vale para futuros recrutas: você contrataria alguém incapaz ou pouco disposto a usar os recursos introduzidos após o C # 1.0?

Eu contemplei essa situação exata.

É isso que planejo para minha equipe:

• Misture C # com F #, isso pode ser feito usando C # para a maioria da base de código. Onde for necessário processamento pesado de dados , escreva as funções associadas em F # e coloque-as em uma dll ou faça referência a elas. Exemplo aqui

• Redefina lentamente sua base de código existente da maneira acima.

• Nem todo o código precisa estar funcional.

• Faça com que sua equipe aprenda o básico de Haskell, LISP nos fins de semana .

• Faça com que eles aprendam F #, tentando resolver os quebra-cabeças do Projeto Euler (que me ajudaram muito quando eu estava aprendendo F #). Novamente, isso deve ser algo feito, digamos no final da semana ou durante o horário de trabalho, se você deseja reservar um dia para o "treinamento".

1) O aprendizado de uma linguagem funcional aumentará a capacidade geral de alguém como programador; no entanto, isso se aplica apenas àqueles que desejam aprender e melhorar. Nem todo programador deseja melhorar, nem deseja mudanças no ambiente de trabalho (conheça sua equipe).

2) Não posso discutir com isso. Você terá que pagar pela curva de aprendizado de 6 meses de qualquer novo idioma, no entanto, já conhecendo as bibliotecas .net, elimina os anos extras necessários para aprender novas bibliotecas.

3) O suporte da comunidade, embora menor que C #, tem muitos desenvolvedores ativos de F # altamente qualificados postando na web. Não esqueça que a maior parte do suporte a idiomas é de biblioteca e há um ótimo suporte para o .NET.

O gorila de mil libras aqui é gerenciamento de riscos. "Eu posso ser de ponta, mas não de ponta." Eu diria que o F # não é uma vantagem. Foi lançado com o VS2010 e é diretamente suportado pela Microsoft. O sangramento é "beta" e um aviso da Microsoft dizendo algo sobre não ser responsável por nada.

Por uma questão prática, o suporte ao IntelliSense é bastante escasso - a ponto de os ganhos de produtividade da inferência de tipo serem superados pelo preenchimento automático menos sofisticado disponível em C #.

As mensagens de erro causadas por inferências errôneas de tipo também demoram mais para serem corrigidas para iniciantes (e geralmente para usuários intermediários como eu), simplesmente porque você está menos inclinado a fornecer anotações de tipo do que em um idioma como C #.

OOP também está faltando de maneiras surpreendentes em F #; por exemplo, não há suporte para tipos / classes aninhados. Você precisa ter cuidado ao portar código, porque, infelizmente, há algumas coisas que você pode fazer em C # que não pode fazer em F #.

Por último, mas não menos importante, tanto o tamanho quanto a qualidade da comunidade F # são decepcionantes. Muitas informações do F # disponíveis na Web são para versões antigas ou simplesmente não são muito boas - não-idiomáticas, desempenho ruim ou incorretas. Depois, há pessoas cobrando muito dinheiro por boletins informativos, que são basicamente apenas um resumo das informações existentes.

Eu mesmo uso C # para projetos de trabalho e F # para minhas próprias coisas. Por mais que eu goste de F #, infelizmente, é um pouco difícil prever como / quando as coisas podem desmoronar.

O principal problema é sempre a manutenção.

Eu adoraria codificar em Scheme, mas o próximo mantenedor provavelmente iria querer me caçar e me torturar.

Eu diria que a primeira coisa que você precisa fazer é perguntar aos membros da sua equipe como eles se sentem sobre a introdução do F #. Se eles gostarem da ideia, tudo ficará muito mais suave, se não gostarem.