armadilhas do mundo real de introduzir F # em uma grande base de código e equipe de engenharia [fechado]

37

Sou CTO de uma empresa de software com uma grande base de código existente (todas 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 um 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 ao introduzir o F #, a saber:

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

2) O conjunto de programadores participantes do F #, a partir de agora (dez 2010), é inexistente. Pesquise vários bancos de dados de currículos de engenheiros de software para "F #", e 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 google quase qualquer problema em C # e encontrar alguém que já tenha lidado com isso, não tão com F #. O suporte a ferramentas de terceiros (NUnit, Resharper, etc.) também é incompleto.

Eu percebo que isso é um pouco Catch-22, ou seja, se pessoas como eu não usam F #, a comunidade e as ferramentas nunca se materializarão, etc. Mas eu tenho uma empresa para administrar e posso ser De ponta, mas não de ponta.

Quaisquer outras armadilhas que eu não esteja considerando? Ou alguém se importa em rebater as armadilhas que mencionei? Acho que esta é uma discussão importante e adoraria ouvir seus contra-argumentos neste fórum público que podem fazer muito para aumentar a adoção do F # pela indústria.

    
por 5 revs, 3 users 65%nganju 16.09.2015 / 16:01
fonte

9 respostas

28

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 Scheme no meu currículo, apesar de nunca tê-lo usado depois da escola e um trabalho envolvendo F # provavelmente também chamaria minha atenção.

    
por 11.01.2011 / 20:11
fonte
13

Any other pitfalls I'm not considering?

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

Or anyone care to rebut the pitfalls I've mentioned?

Elas são obviamente preocupações válidas em algum grau, mas eu questionaria até que ponto.

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

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

Sua terceira e última preocupação diz respeito a menos suporte da comunidade, pesquisando soluções C # versus F # e suporte a ferramentas de terceiros. Mais uma vez, não achei que estes fossem problemáticos na prática. Enviei um e-mail para fsbugs com um comentário sobre unidades de medida em F # e obtive uma resposta dentro de 24 horas do pesquisador que a inventou com uma explicação detalhada de por que minha interpretação estava errada e por que funciona da maneira como funciona. Eu nunca recebi isso de Anders Hejlsberg ;-). Eu busco soluções do Google o tempo todo e encontro-as escritas em C #, VB ou até IronPython mas, em 3 anos de uso do F # industry, consigo lembrar apenas uma única instância em que traduzir a solução em F # não era trivial. Na verdade, recentemente converti o exemplo de serializador de dados C # do MSDN para o F # e ele era 5 × menor. Finalmente, você mencionou o suporte ao F # em ferramentas como o NUnit quando usamos o NUnit do F # sem problemas por algum tempo. Estas são ferramentas .NET, não ferramentas C #.

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

FWIW, eu dei ao meu cliente uma assinatura de site gratuita para o nosso F # .NET Journal , que ficou bem com muitos dos devs aprendendo F #.

HTH!

    
por 29.12.2010 / 19:59
fonte
8

Como você reconhece em 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 de usá-lo - basta reescrever as partes onde você veria o maior benefício. O fato de que o F # interopera muito bem com o C # deve facilitar a criação de certas partes e criar conjuntos F # a partir delas.

Se você tivesse seus engenheiros trabalhando em um aplicativo tradicional de 3 camadas, você provavelmente não insistiria que todos eles precisavam ter um profundo conhecimento de SQL, HTML, Javascript, CSS etc. Em vez disso, você naturalmente teria alguns especialistas trabalhando em diferentes partes do aplicativo. Portanto, não acho que adicionar um novo idioma para uma parte do seu aplicativo seja um obstáculo muito grande. 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 até mesmo por engenheiros sem um fundo F # profundo.

    
por 24.12.2010 / 23:57
fonte
7

As armadilhas de adicionar o F # aos idiomas que você usa incluem as armadilhas de introduzir 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 F #. No entanto, se você permitir que os dinossauros de sua equipe evitem a adoção de novas tecnologias, sua empresa estará condenada.

As únicas armadilhas que experimentei pessoalmente são:

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

  2. Intellisense frustrante. O preenchimento automático pára 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 a recuo dificulta copiar, colar ou reformatar o código.

  4. Falta de refatoração.

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

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

Seus medos que a contratação de novos programadores capazes de escrever em F # seria difícil são bastante comuns, mas na minha opinião injustificada. Se você fosse escrever diretrizes de codificação, você aconselharia 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á razão para se abster de F #. A linguagem suporta esses recursos de uma maneira suave e bem pensada, o que o C # não pode realmente fazer devido ao seu legado.

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

    
por 03.05.2011 / 20:37
fonte
5

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 do código-base. Onde o processamento de dados pesado é necessário, escreva as funções associadas em F # e coloque-as dentro de uma dll, ou faça referência a elas. Exemplo aqui

  • Re-fatore lentamente sua base de código existente da maneira acima.

  • Nem todo código precisa estar funcional.

  • Faça com que sua equipe aprenda os princípios de Haskell, LISP nos finais de semana .

  • Faça com que eles aprendam F #, tentando resolver os enigmas Euler Project (que me ajudaram muito quando eu estava aprendendo F #) . Novamente, isso deve ser algo feito durante o final de semana, ou durante o horário de trabalho, se você quiser reservar um dia para "treinar".

por 23.05.2017 / 14:40
fonte
4

1) Aprender uma linguagem funcional aumentará a capacidade geral de alguém como programador, mas isso só se aplica àqueles que querem aprender e melhorar. Nem todo programador quer se tornar melhor nem deseja mudanças em seu ambiente de trabalho (conheça sua equipe).

2) Eu não posso discutir com isso. Você terá que pagar pela curva de aprendizado de 6 meses de qualquer novo idioma, mas as bibliotecas de .net já existentes eliminam os anos extras necessários para aprender novas bibliotecas.

3) O suporte da comunidade, embora menor que o C #, possui alguns desenvolvedores de F # ativos altamente qualificados postando na web. Não esqueça que a maioria dos suporte a idiomas é suporte a bibliotecas e há um ótimo suporte para .NET.

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

    
por 25.12.2010 / 01:04
fonte
4

Como uma questão prática, o suporte ao IntelliSense é bastante insuficiente - ao ponto em que os ganhos de produtividade da inferência de tipos são superados pelo autocomplete menos sofisticado disponível em C #.

As mensagens de erro causadas por inferências do tipo errôneas 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 faria em um idioma como C #.

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

Por último, mas não menos importante, o tamanho e a qualidade da comunidade F # é um pouco decepcionante. Muitas das informações do F # existentes na Web são para versões antigas ou simplesmente não são muito boas - não são idiomáticas, têm um desempenho ruim ou são incorretas. Depois, há pessoas cobrando imenso dinheiro por boletins informativos que são, em grande parte, apenas de informações existentes.

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

    
por 27.12.2010 / 19:01
fonte
1

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.

    
por 23.09.2011 / 21:56
fonte
0

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

    
por 23.09.2011 / 22:38
fonte