A quem devo perguntar sobre o F #, se não uma pessoa que tenha dedicado um site detalhado a esse idioma?
Scott Vlashin criou o recurso
"F # para diversão e lucro" , familiar a muitos moradores de Habra: de Habré eles traduziram a
série de artigos "Pensamento funcional" e o
artigo "Programação orientada a ferrovias" a partir daí.
E em novembro, ele falará em nossa conferência DotNext em Moscou com o
relatório "O poder da composição". E, antecipando esse discurso, perguntamos a ele sobre F # e programação geralmente funcional.
- Vamos desde o início: o que você fez antes da programação funcional, como chegou ao F # e como criou o site?- Eu sou um homem de idade venerável e, quando eu estava na universidade, ainda não havia programas separados de ciência da computação. Eu recebi uma educação matemática, mas não queria fazer matemática, então, depois da universidade, trabalhei por cerca de 10 anos em vários empregos, incluindo um carpinteiro.
Um belo dia, no final dos anos 80, meu pai comprou um computador, o CP / M Kaypro, com uma pequena quantidade de memória e disquetes de 5,25 polegadas para seu trabalho. Isso foi antes do Windows aparecer, então o DOS estava nele. Foi nele que comecei a programar. Eu estava envolvido em bancos de dados, inicialmente para meu pai, ele precisava disso para o seu trabalho. E então eu comecei a fazer isso profissionalmente.
Meu primeiro idioma era o Turbo Pascal e, em 1989 ou 1990, conheci o Smalltalk e realmente gostei, ainda é um dos meus idiomas favoritos. Um trabalho substituiu outro e, no final, como a maioria dos programadores, consegui um emprego em uma grande empresa para escrever aplicativos de negócios chatos (eu os chamo de "BLOBs": aplicativos de linha de negócios chatos). E por muito tempo ele estava fazendo exatamente isso.
Por um tempo eu escrevi em Python, cerca de 10 anos - em C #. E em 2011, ou seja, não faz muito tempo, decidi que estava cansado do meu trabalho e seria bom tentar algo novo; então eu queria fazer programação funcional. Acabou que o meu Visual Studio já tinha uma linguagem funcional, então tentei entender o F #. E no começo parecia muito estranho, eu não conseguia entender nada, era tão diferente de tudo com o qual trabalhei antes.
Havia vários bons blogs em F #, mas havia muito poucos deles e também não havia documentação suficiente. Como resultado, meus amigos me deram excelentes conselhos: se você deseja estudar alguma coisa corretamente, tente começar a ensinar outras pessoas sobre isso, porque isso faz você entender muito bem o assunto. Além disso, fui aconselhado a iniciar um blog, o que me permite destacar-me entre outros programadores.
Em geral, em 2012, iniciei o blog “F # por diversão e lucro” e comecei a publicar artigos toda vez que aprendia algo novo sobre o F #. Agora, existem várias centenas de páginas e ganhou grande popularidade. No começo era apenas um hobby, trabalhei nele no meu tempo livre. Há cerca de 3 ou 4 anos, decidi largar o emprego e me tornar consultor freelancer. No ano anterior, escrevi um livro, que também se mostrou bastante popular. E, assim, meu conhecimento de F # ocorreu.
- Como você trabalha como freelancer no F #, ou não apenas?- Basicamente, F #, embora de um modo geral, o que eles pagam - é por isso que aconselho
* risos * . Se eu precisar de dinheiro, mas alguém tem trabalho em C #, e parece interessante, eu aceito. E no ano passado, trabalhei com Python por três meses. O que importa para mim não é a linguagem, mas qual problema específico deve ser resolvido. Eu gosto de estudar e, quando você é contratado para resolver um problema, precisa se tornar, se não um especialista, pelo menos resolver uma nova área.
Dessa maneira, tive que estudar economia imobiliária e riscos de seguro. Acredito que um bom código só pode ser escrito quando você tiver uma boa compreensão do assunto que está fazendo e não apenas escrever o que os outros lhe dizem. Para mim, isso é o mais interessante - não é um idioma, mas um problema.
- Na Rússia, embora alguns desenvolvedores tenham interesse em F #, os negócios com esse idioma são difíceis: é mais difícil encontrar ou substituir um desenvolvedor do que com C #. E aquelas empresas com as quais você trabalha, como elas são resolvidas em F #?- Existem duas situações mais comuns. A primeira opção é quando a empresa já usa F #, geralmente eles têm algum tipo de projeto piloto. Eles me ligam e me pedem para ajudá-los a lançar este projeto e ensinar o idioma a eles. Normalmente, eles estão prontos para passar cerca de seis meses em um projeto desse tipo para descobrir se desejam fazer isso ainda mais.
Além disso, estou empenhado em ensinar às pessoas o design orientado a domínios, e aqui o F # não está em destaque, mas eu o uso como idioma. Estou mostrando aos programadores acostumados a C # quanto menor o mesmo código em F # que em C #. Ou seja, eu promovo discretamente a linguagem. Ajuda que você não precise mudar totalmente para o F #, você pode escrever um modelo de domínio em F # e tudo o mais em C #.
- Você diz que C # e F # podem ser usados juntos. Mas em C #, o Entity Framework, NHibernate ou algo semelhante é mais frequentemente usado. E entre os desenvolvedores no F # isso é muito menos popular. Como misturar esses idiomas, levando em consideração a diferença de abordagens?- Uma das empresas com quem trabalhei usa o Entity Framework. Eles tentaram mudar para a arquitetura de portas e adaptadores, ou seja, para remover todas as operações de entrada / saída do núcleo da arquitetura. Para isso, o Entity Framework é muito ruim. Nessas situações, é muito mais conveniente usar algo como o Dapper, que permite que você não lide com o SQL no meio do seu código. Entre outras coisas, isso facilita o teste.
Deixe que eles não usem programação funcional, mas a situação ainda os impele a ter um núcleo limpo do programa e mantenha o banco de dados em algum lugar na periferia. Se o pensamento mudou para esse formato, esse é um passo importante para o abandono da Entidade. Naquela empresa, eu, de fato, não teria mudado nada. Você não pode forçar as pessoas a mudarem, elas mesmas devem querer mudar. Não estou tentando me vender e impor a alguém a maneira que eu acho melhor. Normalmente, as pessoas já querem mudar, e eu apenas as ajudo a conseguir isso. Você entende o que eu quero dizer?
- Ou seja, seus clientes são empresas que já estão adotando uma abordagem mais funcional.- Mesmo que trabalhem com C #, eles alternam para um C # mais funcional, começam a usar LINQ, estruturas de dados imutáveis, ou seja, em geral, seguem nessa direção. Portanto, para eles, mudar para F # não é mais um grande salto.
As profissões de um desenvolvedor e um carpinteiro são semelhantes
- Você tem um tópico interessante no Twitter comparando o trabalho de um programador e um carpinteiro. Eu gostaria de perguntar sobre o "funcionalismo", a partir deste tópico. Mas você pode dizer a essência disso para nossos leitores?- Os desenvolvedores gostam de se comparar com os engenheiros e o desenvolvimento de software - com a construção de edifícios ou pontes. E há muito debate sobre se a programação está realmente próxima dessas atividades ou se são fundamentalmente diferentes. Como, temos requisitos para o projeto mudar todos os dias - quando você constrói uma ponte, provavelmente tudo está completamente errado? Ou é realmente tão lá também?
Mas acredito que nesta disputa não há uma única resposta correta. Nunca fui engenheiro, mas fui carpinteiro. E posso dizer que os carpinteiros têm muito trabalho diferente, muito diferente em formato, e cada um precisa de sua própria abordagem.
Por exemplo, em um dos trabalhos que fiz em armários de cozinha. Na América, todos são muito padronizados, do mesmo tamanho, adaptados um ao outro, e o trabalho está sendo feito com ferramentas elétricas. É necessário fornecer alguma qualidade, mas nos Estados Unidos, a cozinha antiga geralmente é jogada fora quando a casa muda de proprietário, ou seja, ela não serve por muito tempo. Portanto, neste trabalho, tudo está ligado à velocidade e economia de custos.
Depois, tive outra tarefa, onde precisava substituir uma grande viga de carvalho de 15 cm no meio da sala do prédio, com 400 a 500 anos de idade. Aqui tudo era o oposto: tudo era curvado, sem ângulos retos e, para substituí-lo, era necessário encaixar manualmente um novo pedaço de madeira para que ele tivesse exatamente a mesma forma do antigo. Isso exigiu muita precisão.
Finalmente, houve o terceiro trabalho em que eu fiz o cenário para o palco. Eles eram feitos de madeira compensada e madeira muito fina para adereços.
Minha ideia é que cada trabalho exija sua própria abordagem. No caso de armários de cozinha, são necessários precisão, uso de ferramentas elétricas e resultados reproduzíveis. Em uma antiga casa de madeira, você trabalha com um sistema legado; é importante ter cuidado, não se apressar, não é preciso acelerar, mas a exatidão do resultado. Por fim, no caso de decorações, você cria deliberadamente uma estrutura frágil que não precisa ser forte; geralmente é necessário cortá-la e montá-la novamente em alguns minutos; essas estruturas não duram para sempre.
Quando eles dizem que a programação é semelhante à engenharia, isso é verdade apenas para certos tipos de programação. Por exemplo, se você escreve um software que controla um avião, precisa ter muito cuidado e obter uma precisão muito alta. Uma coisa completamente diferente é um script de uma linha para procurar arquivos, é mais como criar cenários. Não faz sentido gastar 20 horas provando que esse script funciona e escrevendo 1000 testes de unidade para ele. Todo o trabalho não deve demorar mais de 5 minutos. E quando você trabalha com um sistema herdado, precisa ajustar o seu código ao existente, o máximo possível, uma refatoração grande é indesejável aqui.
Ou seja, em cada caso, o contexto é importante. Às vezes, você precisa planejar muito, pensar muito em um projeto, escrever muitos testes. Em outros casos, é suficiente para preparar alguma coisa. Muitas pessoas não têm flexibilidade a esse respeito, acreditam que, se você não usa testes de unidade ou não usa alguma linguagem de programação, então você não é um profissional. De fato, a ideia de que tudo depende do contexto é bastante óbvia. Surpreendentemente, quão teimosamente alguns programadores insistem em suas idéias, e se você pelo menos se desvia de seus ideais, você é imediatamente enviado para a lista negra. Na minha opinião, isso é estúpido.
- Você diz que, para um observador externo, a atividade parece uniforme, mas quando você a vê de dentro, casos completamente diferentes são revelados. E eu quero perguntar: é o mesmo com a programação funcional? Quem olha de fora tem um estereótipo comum, mas, de fato, existem diferenças gigantescas?Isso mesmo. Do lado de fora, pode parecer que todos os "funcionários" pensam da mesma forma, mas existem muitos grupos diferentes que discutem entre si: apoiadores de Haskell, F #, Clojure, Elm. Mesmo dentro do F #, há um forte desacordo em relação a qual direção essa linguagem deve evoluir - você deve tentar imitar Haskell ou a facilidade de uso ser uma prioridade. Então, você está certo, dentro deste campo é muito mais diverso do que os observadores externos costumam imaginar.
- Para diferenças no trabalho de um carpinteiro, você deu exemplos muito claros. Você também pode ilustrar as diferenças na programação funcional com exemplos específicos?- Existe uma escola de programação funcional, que acredita que você precisa tentar provar tudo e que tudo é matematicamente perfeito. Esta escola usa muito jargão matemático, por exemplo, "monóides" ou "mônadas". Estes são principalmente usuários Haskell, e o ambiente acadêmico é muito influente.
E há pessoas que são mais importantes para alcançar resultados. Eles estão interessados não tanto em matemática como em imutabilidade e remoção de E / S na periferia. O melhor exemplo dessa abordagem é a comunidade Elm. Eles estão envolvidos principalmente na criação de aplicativos da web. Ao contrário do primeiro grupo, aqui eles não usam conscientemente o jargão matemático e conscientemente recusam a parte da funcionalidade que está em Haskell e que os usuários de Haskell consideram vitais.
Além disso, há uma disputa entre os defensores da digitação forte e da digitação dinâmica. Na visão dos leigos, a programação funcional é algo como Haskell ou F #, mas além deles, existem linguagens como o Clojure que possuem digitação dinâmica e uma abordagem completamente diferente para resolver problemas. Se você coletar toda essa empresa heterogênea em um quarto, eles poderão lutar. Eu acho que todas as abordagens têm seu próprio motivo e, quando trabalho para alguém, não digo que a abordagem está errada.
- Muitos estão assustados com a mencionada "natureza acadêmica" ("O F # está enraizado na ML, que é para evidência científica rigorosa, mas eu resolvo problemas reais aqui"). Mas acontece que as pessoas têm medo em vão?- Em geral, parece-me estranho que tantas pessoas estejam acostumadas a considerar a acadêmica como algo negativo. Bem, isto é, como, alguns consideram negativo, outros - positivo.
O fato é que muitas das tecnologias que usamos agora em programação surgiram no ambiente acadêmico, por exemplo, coleta ou tipos de lixo. Portanto, não há nada de errado com os próprios métodos acadêmicos. Outra questão é que uma ênfase excessiva neles pode ser prejudicial, porque cientistas e programadores têm objetivos diferentes.
Embora as linguagens funcionais tenham raízes acadêmicas, parece-me a decisão consciente correta de ocultar essa lógica em linguagens como F # e Elm. Portanto, o F # é usado não para provar teoremas, mas para resolver problemas reais, é uma linguagem muito pragmática. E as universidades agora mudaram para idiomas ainda mais complexos, como Coq, F * e similares. Eles são muito mais acadêmicos e são usados para provar teoremas.
Como eu disse, cientistas e programadores fazem coisas diferentes. Os programadores passam a maior parte do tempo lendo e gravando arquivos, trabalhando com bancos de dados, exibindo dados na tela, verificando dados inseridos, convertendo-os etc. Mas os cientistas não estão interessados nessas coisas. Mas o fato é que coisas que eram puramente acadêmicas há 40 anos talvez não sejam assim hoje.
- Como você mesmo disse em relação ao trabalho de um carpinteiro, abordagens diferentes são boas em contextos diferentes, não há abordagens universais. E, especificamente, o F # também é mais adequado para determinadas tarefas. Quais são essas tarefas?- Sim, essa definitivamente não é uma linguagem universal, eu definitivamente não recomendaria usá-la para todos, seria estúpido. Mas me parece que o F # é um excelente substituto para o C # - com exceção das tarefas que exigem desempenho muito alto. A programação no F # é baseada em uma abordagem completamente diferente: imunidade, igualdade estrutural, dependências explícitas, o F # não possui valores nulos e assim por diante. E parece-me que essa abordagem é muito mais útil na resolução de problemas de programação cotidianos.
Portanto, se uma pessoa usa C #, ele definitivamente deve perguntar sobre F #, esse idioma ajudará a melhorar o código. Quanto a outras áreas de aplicação, parece-me que o F # seria adequado para muitas tarefas para as quais o Python agora é usado. F # e Python são muito semelhantes, e parece-me que o F # tem um grande potencial para processamento de dados. Por enquanto, ainda há mais trabalho a ser feito nessa área, mas talvez em alguns anos as pessoas usem o F # para várias coisas relacionadas ao big data e à ciência de dados, para as quais o Python agora é usado.
Finalmente, o F # é muito conveniente para trabalhar com JavaScript. Em geral, ninguém deseja trabalhar diretamente com JavaScript, portanto, existem muitas linguagens compiladas em JS: por exemplo, ReasonML (que roda em OCaml) e Fable (que roda em F #). Pessoalmente, prefiro trabalhar com qualquer uma dessas opções do que lidar com JavaScript; portanto, ao trabalhar no front-end, escolheria algo como Fable. Portanto, essas são as três principais áreas em que o F # mostra seu melhor lado.
- Como você observou no seu relatório “F # para desenvolvedores de C #”, o principal na linguagem não é sintaxe, mas filosofia. Mas aqui está a dificuldade para quem quer entender rapidamente "se esse idioma combina comigo". Você já pode entender se gosta da sintaxe com uma rápida introdução. Mas quanto tempo leva para entender a filosofia da linguagem?- Uma pessoa que escreve em C # pode descobrir rapidamente uma linguagem como Java ou Go, porque a maioria dessas linguagens padrão possui um modelo imperativo. Passar deles para o F # definitivamente exige muito esforço, e isso impede algumas pessoas. Na minha experiência, o F # é muito mais fácil de aprender se, por um tempo, você esquecer tudo o que sabe sobre OOP. Caso contrário, você começará a transferir todos os tipos de coisas de C # para F #.
Quanto ao tempo, em duas semanas de treinamento já é possível começar a escrever código de trabalho e levará vários meses para que mais ou menos se acostume com o idioma. Por fim, para um bom nível de propriedade, você precisa de mais tempo, 6 meses, talvez mais - isto é, se estivermos falando sobre resolver todas as bibliotecas, expressões idiomáticas e afins.
Mas, honestamente, mudar para F # não é mais difícil do que mudar para Entity ou WPF. Eles também exigem muito tempo. Não subestime os esforços necessários, mas às vezes eles dizem que essa transição leva anos. Repito: para começar a escrever código, leva várias semanas para ficar confortável - vários meses. Digo isso pela minha própria experiência e pela experiência de outras pessoas com quem conversei.
Preciso conhecer C # antes de F #
- É claro que a maioria das pessoas que usam F # veio do C #. Há muitos que chegam ao F # sem experiência em C #?- Não existem muitas pessoas, e é muito difícil para elas, porque todas as bibliotecas têm documentação para C #, então as pessoas em todos os lugares encontram exemplos de C #. Mas ainda existem essas pessoas e, além disso, o F # é ensinado em várias universidades.Há quem esteja tentando aprender F # depois do Python. O problema é que o F # depende muito do .NET e o .NET está vinculado ao C #. A mesma situação com o Visual Basic, também existem todos os exemplos em c #. Vamos torcer para que nos próximos anos essa situação seja capaz de mudar e facilitar o aprendizado da língua, agora esse é um dos problemas importantes.— C#, F#, , F# . ? LINQ , , , ?— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .
— C# , F# ?— . , . , , . , - , Python JavaScript, .
, . JavaScript , F# . , . F# — , , C#, . F# .
— F# — «F# for fun and profit»? C#?— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.
Fun and profit
— «F# » («F# for fun and profit») - , «». , -, ?— . . , F# , , . , , F#, , . F# .
- , — . , - Java . , , , . , , F# C# .
— «»: , , , .— , . , , , . .
StackOverflow , , F# , . , , , , C#. , - , , 10 . .
, , F#, F#. F#, , . , . , F# .
— , F# . ? , , F# . F# ?— , F# . , . - , . , , , . , . F# null; , ; . F# .
, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .
- . , , . , , , , , . Google Amazon — .
— , F# , — , , . ?— , . , , C# , , C#. , C#, null, , - . F# . , , , .
- - , , , . C# F#, , , . , , . , , F#, .
— , Microsoft F# ( C# ). ?— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .
, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .
— Haskell. F# — .NET-, ?— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .
Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .
— . F#, , : , , ?— , F# . , , , . , . F# , , C#. , Haskell, - , .
, , , .
F# , , . , -, .
, - , , — , ? , , , . F#, C#, , . . - , F#.
, F# , , .
DotNext «The Power of Composition». , F#: , , , . , .