Certa vez, conversei com o fundador de uma startup israelense que estava desenvolvendo um banco de dados de GPU de alta velocidade. Haskell e C ++ estavam em sua pilha, e o fundador reclamou da dificuldade de encontrar pessoas na equipe. Ele voou para Moscou, inclusive procurando bons programadores.
Perguntei cuidadosamente se era melhor usar algo mais comum e novo. E embora a resposta tenha sido educada e construtiva, nas entrelinhas me pareceu: "Pff, nem mencione esses latidos de brinquedo".
Tudo o que ouvi sobre Haskell desde então se resumiu a uma coisa: "piadas são ruins para ele". Para conhecer melhor os haskellistas, vim ao chat do telegrama para fazer perguntas. Foi bastante assustador e, como se viu, não em vão.
Eles não querem falar sobre Haskell popularmente, e parece que contemplam tais empreendimentos com desprezo. Já estou falando - com o máximo de integridade e objetividade. “Uma das qualidades características de Haskell como idioma e comunidade é que, juntos, eles não se esforçaram para se tornar populares, dando uma resposta simples a perguntas populares. Em vez disso, eles criaram uma maneira lógica de resolver problemas reais, em vez de penetrar rapidamente no coração de um transeunte por uma pessoa interessada ”, escreveram para mim lá.
No entanto, várias pessoas compartilharam suas experiências, e eu reuni suas opiniões aqui.
Denis Mirzoev ( nolane ) : Na universidade, sobre o assunto "Linguagens de programação", fui oferecido a fazer um curso na Haskell Coursera por um ponto adicional em cem. Depois, houve um curso de programação funcional no qual Haskell ocorreu. Ele escreveu um trabalho de conclusão de curso e um diploma de bacharel em GHC. Encontrou um emprego como programador Haskell.
Foi difícil, e ainda difícil. Quando você começa a estudar Haskell, precisa entender muitos conceitos novos. Isso é trabalho duro. Você literalmente aprende a programar novamente.
Agora, será difícil para muitos lembrar como começaram sua jornada na programação, como foi difícil entender o que é um "ponteiro", o que é uma "função", o que é uma "classe". Talvez seja por isso que estudar Haskell seja tão difícil. Com a idade, fica mais difícil aprender coisas novas.
Doctor_Ryner : Uma vez em um período de teste, eu caí no Redux, então, olhando as lições de seu criador, decidi conhecer melhor todos. No início, apliquei as práticas aprendidas em JavaScript, mas depois aprendi sobre Haskell, que é considerada uma verdadeira linguagem funcional. Fui imediatamente atraído por sua elegância e um monte de novos conceitos desconhecidos para mim.
Não foi fácil com tutoriais intermináveis sobre mônadas no exemplo dos burritos, que são muito confusos. Além disso, um histórico imperativo dificulta a abertura de novos conceitos.
Yuri Syrovetsky ( cblp ) : A coisa mais difícil de aprender é Haskell em segundo, quando a síndrome do patinho não passou para o primeiro idioma.
O que é bom e o que é linguagem ruim?
Doctor_Ryner : A linguagem é muito concisa, elegante e flexível, não é à toa que metade das bibliotecas nela são EDSL (pelo menos essa impressão).
Yuri Syrovetsky ( cblp ) : alta expressividade, fácil de transferir a área de assunto para o código, a combinação ideal de paradigmas imperativos e funcionais. É fácil criar abstrações de dados e algoritmos, o que permite que você pense sobre o problema sem se distrair com pequenas coisas não relacionadas.
John Doe : Digitação estrita e forte (eu diria fascista).
Igor Shevnin ( interphx ) : Um sistema do tipo muito expressivo. Não é tão poderoso quanto Idris ou Agda, mas atinge o meio termo quando quase tudo pode ser expresso, e a inferência de tipos funciona bem. Você não precisa marcá-los manualmente em todos os lugares.
Mas um poderoso sistema de tipos faz você prestar atenção aos valores passados. Um monte de definições de tipo pode parecer um clichê. Cada equipe usa seu próprio conjunto de extensões ou não as utiliza. O código é mais "denso" - uma linha geralmente carrega mais informações do que em outros idiomas; portanto, é mais difícil para um desenvolvedor inexperiente lê-lo.
Doctor_Ryner : Quando você estuda Haskell, provavelmente encontrará o ditado "se ele compilar, provavelmente estará correto". Não há nulo, o paradigma funcional em si é muito rigoroso e obriga a seguir certas regras, que na maioria dos casos levam a um design melhor.
Por exemplo, não há variáveis no idioma - apenas constantes. Você não precisa acompanhar o que e onde atribuir. Haskell incentiva o uso de funções puras, o que resulta em nenhum efeito colateral. O design funcional simplesmente faz o programa funcionar como um todo, em oposição ao OOP, onde vários objetos são lançados ao mundo e os objetos tentam se comunicar através de efeitos colaterais, transformando o aplicativo em uma bagunça imprevisível. No trabalho, sofremos bastante disso com o C # no Unity.
Denis Mirzoev : A preguiça incorporada aumenta a expressividade da linguagem. Muitos algoritmos estão se tornando mais fáceis. Pode aumentar a produtividade se os resultados dos cálculos intermediários não forem utilizados. (Por exemplo, `head. Sort` funciona em tempo linear).
Igor Shevnin : Um modelo lento de computação geralmente ajuda, mas quando a ordem de chamada das funções é importante, pode ser difícil descobrir o que está acontecendo.
Doctor_Ryner : É compilado, o que imediatamente dá um enorme aumento na velocidade.
Denis Mirzoev : Comparado com Java em velocidade, mas não tão rápido quanto C.
Igor Shevnin : Fora da caixa, há suporte para extensões que permitem concluir o sistema de idiomas e tipos. No entanto, existem muitas extensões amplamente usadas que são familiares à comunidade, têm exemplos e documentação decentes e não são de nicho.
Doctor_Ryner : A biblioteca padrão do Prelude possui funções muito ruins, como read, head, readFile, que podem gerar uma exceção e colocar em um programa, em vez de retornar Maybe. Portanto, você precisa usar alternativas ou escrever suas próprias implementações.
Igor Shevnin : O principal problema é a falta de padronização, na medida em que muitos substituem a biblioteca padrão por uma das alternativas incompatíveis. Há discordâncias na comunidade sobre o que deve ser uma biblioteca padrão, o que deve ser incluído no núcleo da linguagem e o que deve ser complementado por extensões, e acho que isso atrasa o desenvolvimento da linguagem.
Denis Mirzoev : Não há ferramentas suficientes: não há IDE completo, há muito poucas ferramentas para medir o desempenho, não há depuração "passo a passo" - esse geralmente é um problema fundamental.
Para quais projetos o Haskell é mais adequado?
Yuri Syrovetsky : Para tarefas complexas relacionadas à segurança ou dinheiro, onde o custo do erro é alto.
Doctor_Ryner : Para tudo onde você precisa realizar cálculos, transformações e análise de dados. Muito surpreso que Haskell seja menos popular em ciência de dados do que Python.
Igor Shevnin : Eu não arriscaria usá-lo para sistemas embarcados (o desempenho não é ruim, mas ainda há uma sobrecarga significativa no consumo de memória devido a cálculos preguiçosos) e pequenos scripts (esse rigor simplesmente não é necessário). Você também precisa entender que encontrar desenvolvedores em uma equipe é muito mais difícil do que nos idiomas tradicionais.
John Doe : Para escrever o código da indústria que outros lerão, você precisará de toda uma equipe de haskellists. Poucas pessoas conseguiram coletar.
Igor Shevnin : Mas devido à sua brevidade e rigor, Haskell é adequado para praticamente qualquer tarefa.
Começar a aprender o desenvolvimento com Haskell é uma boa ideia?
Igor Shevnin: É improvável que comece, porque a grande maioria das bases de código com as quais uma pessoa terá que trabalhar não está escrita nela.
John Doe : Má, má ideia! Os idiomas não da família ML - mas dos idiomas industriais em geral - serão um choque para você.
Denis Mirzoev : Geralmente, as pessoas primeiro estudam matemática, depois passam para a programação. Portanto, aprender uma linguagem usando conceitos matemáticos (tipos de dados algébricos, funções puras) deve ser mais simples do que imperativo. Ou seja, acho que é uma boa ideia.
Doctor_Ryner : Todos os recém-chegados que eu treinar, definitivamente o apresentarei a Haskell. As pessoas que não estudaram o estilo imperativo são muito mais fáceis de navegar no código funcional e aprendem mais rápido; mesmo que trabalhem com linguagens orientadas a objetos, elas trazem boas soluções arquitetônicas e práticas funcionais.
Yuri Syrovetsky : É melhor começar imediatamente com vários idiomas fundamentalmente diferentes, por exemplo, C, Haskell e Smalltok, em qualquer ordem. Nem um único idioma em
separadamente não dará uma compreensão completa.
Haskell é uma linguagem bastante antiga. Isso é bom ou ruim?
Yuri Syrovetsky: A linguagem está se desenvolvendo muito ativamente, a carga de compatibilidade apenas por uma questão de compatibilidade não diminui.
John Doe : O padrão foi adotado em 1998, mas isso não é perceptível: até agora, novas versões do compilador, potencialmente quebrando a compatibilidade com versões anteriores, são lançadas aproximadamente a cada seis meses.
Denis Mirzoev : Haskell não é velho, mas testado pelo tempo. Mudanças impensadas nunca entrarão no idioma. Então é muito bom.
Diz-se que Haskell é uma das linguagens mais complexas. É isso mesmo?
Doctor_Ryner : Como a própria linguagem, não. O mais provável são as abstrações usadas nele. Uma pessoa que nunca viu o código Haskell pode simplesmente enlouquecer com o fluxo de novas informações e várias construções incomuns.
O petróleo acrescenta ao fogo que a linguagem impõe um monte de "restrições", não permite ou complica muito um monte de coisas que não se encaixam em um conceito funcional.
John Doe : Para que o primeiro projeto elementar fosse pelo menos compilado, levou quase dois meses para fumar livros, manuais e tutoriais à noite. É verdade que, após a compilação, o projeto imediatamente começou a funcionar e os figos em carga máxima (6k rps com picos de até 15) por seis meses, sem nenhuma alteração.
Denis Mirzoev : Aposto que se um aluno começar a estudar programação de Haskell e se
afastar o suficiente, a programação imperativa lhe parecerá mais complicada e menos intuitiva.
Igor Shevnin : A complexidade é relativa. Entre as principais linguagens, ainda acho o C ++ o mais complexo. Idiomas para provar teoremas (Agda, Coq) serão mais complicados que Haskell em um sentido conceitual. Haskell é uma linguagem simples, mas seus padrões e bibliotecas - padrão e de terceiros - podem ser aprendidos longe de imediato.
Sua complexidade é sempre justificada?
Igor Shevnin : Padrões e um alto nível de abstração são justificados, pois tornam o código mais confiável e mais curto. Mas acho que operadores, nomes de funções e muitas outras coisas podem ser mais claros.
Doctor_Ryner : Geralmente, construções complexas de Haskell permitem criar soluções muito curtas, que também se
mostram muito flexíveis e modulares.
Yuri Syrovetsky : Exceto que o gerenciamento de efeitos é complicado, embora quase
é sempre melhor do que falta de controle. Mas simplificá-lo
trabalho está em andamento.
John Doe : A linguagem para aqueles acostumados a python / php / qualquer coisa que geralmente faça parecer ortogonal à realidade. Para pessoas que inicialmente não estavam interessadas na teoria das categorias, é muito difícil obter resultados a partir do zero absoluto.
Mas quando você entende o idioma, obtém uma nova maneira de pensar sobre o problema que está sendo resolvido.
Haskell parece ser uma linguagem para matemáticos, não para desenvolvedores. Você acha que isso não é generalizado por causa disso?
Denis Mirzoev : Esta é uma demonstração do princípio que os principais desenvolvedores de Haskell seguem - "evite o sucesso a todo custo". A questão, é claro, não é evitar o sucesso, mas evitar o sucesso, cujo preço é alto demais.
Haskell poderia se tornar popular. Por exemplo, há suporte para esse idioma da Microsoft. Foi possível tornar a linguagem mais imperativa, tomar algumas decisões rápidas e mal concebidas para ganhar popularidade. Era possível usar muitos truques sujos, mas graças à posição correta dos principais desenvolvedores, não havia nada parecido com isso.
Sim, a popularidade do idioma não é muito alta, mas sua qualidade não sofre. As vantagens de Haskell sobre linguagens imperativas são óbvias para mim, a maioria dos problemas dele é solucionável, por isso estou certo de que uma grande popularidade surgirá à medida que se desenvolver.
Yuri Syrovetsky : Então ele é visto apenas por pessoas que não sabem nada sobre ele. Em
Haskell usa o desenvolvimento "real" há muito tempo; exemplos são fáceis de encontrar em
seu mecanismo de pesquisa favorito. Em particular, estamos na LC usando
Haskell está satisfeito e não vemos mais nada em seu lugar.
Igor Shevnin : O que é uma "linguagem para matemáticos" que eu realmente não conheço. Este é o R / MatLab / Mathematica para cálculos e estatísticas, ou Python, porque é simples e requer menos experiência em engenharia. Mas não Haskell. Conceitos algébricos, como monóides, são utilizados por razões práticas, e não apenas por rigor adicional.
O principal papel na popularidade foi desempenhado pela prevalência histórica de C / C ++ / Java / C # na empresa, eles ocupavam um nicho. Mas agora, muitas empresas estão começando a usar o Haskell e outras linguagens funcionais.
Com o que você compararia Haskell e a favor de quem?
John Doe : Mais ou menos comum - com Erlang. Mas Erlang ainda é mais fácil de escrever e mais fácil de aprender, parece-me.
Denis Mirzoev : Conheço bem C, C ++, Java e Haskell. C ++ nem precisa ser comparado a nada, a linguagem é terrível. C é uma boa linguagem para o desenvolvimento de baixo nível. Nesse nicho, ele ficará melhor. Caso contrário, eu preferiria Haskell.
A escolha entre Java e Haskell já é mais difícil, mas aqui você também precisa examinar uma tarefa específica. Para o Android no Haskell, provavelmente será difícil escrever, nesse caso o Java é melhor. Mas o servidor para escrever em Haskell é quase tão conveniente quanto em Java. Se o ambiente permitir - ajuste, acessibilidade das bibliotecas -, geralmente escolho Haskell.
Doctor_Ryner : Com o C #, apenas
pesquise no Google como implementar o Talvez no C # e no Haskell. É muito estranho que o Haskell ditatorial puramente funcional pareça muito mais flexível e livre. De fato, esses são dois extremos.
O C # é uma das linguagens mais orientadas a objetos, e os benefícios do Haskell estão em forte contraste com ele. No C #, você constantemente precisa escrever um monte de coisas desnecessárias, e tudo isso é muito desagradável. O uso de funções de ordem superior pode estragar o código em termos de sintaxe. Em meio a tudo isso, já é difícil recuperar as soluções curtas e elegantes de Haskell.
Igor Shevnin : Com Rust, até agora a favor de Rust. É preciso muito do Haskell e de outras linguagens FP, mas ao mesmo tempo a abordagem funcional é amigável com o imperativo, e os desenvolvedores e a comunidade são muito mais competentes e mais consistentes no desenvolvimento da linguagem desde o início.
O que você acha da comunidade Haskellist?
John Doe : A grande maioria são pessoas muito amigáveis, sempre prontas para ajudar. Uma boa diferença das comunidades de muitos outros idiomas.
Doctor_Ryner : As comunidades Haskell geralmente contêm pessoas assustadoramente inteligentes que estão sempre prontas para ajudar. Não é à toa que os memes locais sobre PhD, teoria das categorias e acadêmicos vão. Se você entrar no bate-papo em outros idiomas, verá que as pessoas estão discutindo problemas comuns de produção e estruturas de dados. Em um bate-papo com Haskell, mônadas, o lema de Yoneda, funções aplicadoras, tipos malucos e assim por diante, imediatamente aparecem na sua frente.
Você imediatamente vê tantas novidades que não conhecia antes - composições malucas, transformações e transformações elegantes, soluções para problemas que ocupam dezenas de linhas nos idiomas principais, quase em uma linha.
Eles dizem que os haskellistas são arrogantes. Certo?
Denis Mirzoev : Sim. Parece-me que a arrogância se deve ao fato de que eles realmente amam sua linguagem e ficam chateados com sua subestimação.
John Doe : Nifiga assim.
Doctor_Ryner : Provavelmente, essa opinião se foi, devido ao fato de muitos desenvolvedores mainstream ficarem muito irritados quando os haskelistas começam a falar sobre programação funcional e suas vantagens. Um terrível mal-entendido, por sua vez, pode incomodar o próprio haskelista, e ele começará a se apressar em termos, pelos quais é estigmatizado pelo FAQ.
Igor Shevnin : Arrogância é uma palavra muito forte. O ponto aqui é que FP, OOP, a diferença entre classes de OOP e tipos de união, problema de extensão e muitos outros conceitos somam uma imagem muito clara e, depois disso, torna-se difícil perceber pessoas que estão tentando se opor a OOP e FI ou imaginam problema generalizado em uma perspectiva estreita.
Por que os idiomas FP ainda são nicho?
Denis Mirzoev : Suas vantagens ainda não são suficientes para interessar um grande número de programadores. A dificuldade em aprender não é propícia à popularidade. Problemas com o ajuste também assustam muitos, mas parece-me que apenas aumentar o tamanho da comunidade poderia resolver esse problema. Acontece um círculo vicioso.
Igor Shevnin : O nicho está gradualmente passando e os conceitos funcionais estão sendo atraídos para outras línguas.
Doctor_Ryner : Os próprios princípios funcionais e as linguagens que os sustentam já são onipresentes. Mesmo para objectos cortantes, existem o Linq e algumas outras bibliotecas. Os de nicho são linguagens bastante funcionais, pois usam conceitos não padronizados.
Não se esqueça que, há 20 anos, o ferro não era suficientemente produtivo para linguagens funcionais; portanto, o funcionalismo começou a se popularizar nos últimos anos, e o interesse por Haskell está crescendo apenas.