Certa vez, tive uma discussão com o fundador de uma startup israelense desenvolvendo um banco de dados baseado em GPU com foco na velocidade. A pilha de trabalho incluía Haskell e C ++, entre outros, e o fundador estava reclamando da dificuldade de encontrar programadores competentes. O que era parte da razão pela qual ele veio a Moscou.
Perguntei cuidadosamente se eles consideravam usar algo mais popular e novo. E mesmo que a resposta tenha sido bastante educada e bem fundamentada em argumentos, ainda parecia "Vamos lá, nem traga esses brinquedos".
Até então, tudo o que ouvi sobre Haskell poderia ser resumido como "tenha MUITO cuidado ao lidar com isso". Para conhecer melhor os programadores da Haskell, eu vim para um bate-papo tópico do Telegram com algumas perguntas. No começo, fiquei com muito medo e, como se viu, estava certa.
Haskell não se presta a explicações populares, e as pessoas aparentemente nem tentam. Se o tópico for abordado, é discutido apenas em profundidade e da maneira mais objetiva possível. Alguém escreveu para mim: “Uma das características definidoras do próprio Haskell e de sua comunidade é que eles não tentaram alcançar nenhum tipo de reconhecimento convencional. Em vez disso, eles se concentraram em criar uma maneira lógica e principal de resolver problemas reais, tentando satisfazer o maior público possível ”
No entanto, algumas pessoas me contaram sobre suas experiências, que são mostradas abaixo.
Denis Mirzoev ( nolane ) : Quando eu estava na faculdade, eles me ofereceram para fazer um curso de Coursera em Haskell por crédito extra. Também tivemos um curso de programação funcional que incluía Haskell. Eu escrevi um dos meus trabalhos, mais o trabalho de graduação, no GHC. Então eu encontrei um emprego como programador Haskell.
Foi, e ainda é, difícil. Quando você começa a aprender Haskell, precisa inserir muitos conceitos novos em sua mente. É como aprender a codificar do zero novamente.
As pessoas tendem a esquecer (ou suavizar) suas memórias anteriores: como quando estavam lutando para entender o que era um "ponteiro", "função" ou "classe". Talvez seja por isso que é tão difícil para eles aprenderem Haskell: fica mais difícil aprender coisas novas com a idade.
Doctor_Ryner : Uma vez que eu falhei no meu período de teste em um emprego por causa de uma foda no Redux, tentei me sentir um pouco mais confortável assistindo vídeos do criador. Primeiro pratiquei em JavaScript, mas depois aprendi sobre Haskell, considerado a linguagem funcional "verdadeira". Fiquei fascinado por seus conceitos únicos e como era legal.
Os tutoriais não são muito fáceis de usar, porém, além de seu histórico imperativo, impede que novos conceitos surjam.
Yuri Syrovetskiy ( cblp ) : o mais difícil é aprender Haskell como sua segunda língua, quando as lembranças de aprender a primeira ainda estão frescas,
O que Haskell é bom e ruim?
Doctor_Ryner : É conciso, elegante e flexível. Não é à toa que metade das bibliotecas existem no EDSL (ou pelo menos parece).
Yuri Syrovetskiy : É (subjetivamente) fácil adaptar seus pensamentos ao código, possui um grande equilíbrio de paradigmas imperativos e funcionais. Construir abstrações de dados e algoritmos é bastante simples, o que permite pensar na tarefa em questão sem se distrair demais com pequenos aborrecimentos.
John Doe : Tipificação rigorosa e forte (até mesmo fascista).
Igor Shevnin ( interphx ) : Um ótimo sistema de tipos. Não é tão poderoso quanto em Idris ou Agda, mas ainda atinge o ponto intermediário conveniente, onde você pode descrever quase tudo, e ainda assim a inferência de tipos funciona bem. Você não precisa marcá-los manualmente todas as vezes.
Mas um sistema de tipos poderoso obriga a prestar mais atenção aos valores transmitidos. Um monte de definições de tipo pode parecer um clichê. Cada comando tem seu próprio conjunto de extensões ou não os possui. O código é "mais denso" - cada string geralmente carrega mais informações do que em outros idiomas, portanto, é mais difícil ler para um desenvolvedor inexperiente.
Doctor_Ryner : Ao aprender Haskell, você provavelmente encontrará este ditado: "Se compilar, provavelmente estará correto". Nulo não existe, o próprio paradigma funcional é muito rigoroso e mantém você dentro de certas diretrizes, que na maioria dos casos levam a um melhor design.
Por exemplo, Haskell não tem variáveis - apenas constantes. Você não precisa acompanhar o que está atribuído a onde. Haskell incentiva o uso de funções "puras", que não têm efeitos colaterais. O design funcional força o programa a funcionar como um todo, em oposição às linguagens orientadas a objetos, onde muitos objetos tentam se comunicar usando esses efeitos colaterais, transformando o aplicativo em uma bagunça imprevisível. Sofremos muito isso no C # e no Unity no trabalho.
Denis Mirzoev : Quando o idioma é naturalmente "preguiçoso", geralmente é mais expressivo. Os algoritmos ficam mais simples. Se resultados intermediários não forem usados, aumentará bastante o desempenho.
Igor Shevnin : A “preguiça” geralmente ajuda, mas quando a ordem das chamadas de função é importante, às vezes é realmente difícil entender o que está acontecendo.
Doctor_Ryner : Se estiver em conformidade, provavelmente é muito rápido.
Denis Mirzoev : Em termos de desempenho, é comparável ao Java, mas não tão rápido quanto o C.
Igor Shevnin : Possui suporte de extensão
pronto para uso, o que permite adaptar o idioma e o sistema de tipos ao seu gosto. Existem muitas extensões amplamente usadas pela comunidade e com amostras e documentação decentes.
Doctor_Ryner : A biblioteca Prelude padrão tem muitas funções ruins, como read, head, readFile, que podem lançar uma exceção e travar o aplicativo em vez de retornar Maybe. Então eu tenho que usar alternativas ou escrever as minhas.
Igor Shevnin : o maior problema é a falta de padrões, a ponto de muitas pessoas substituirem a biblioteca padrão por uma das alternativas, que não são de forma alguma compatíveis entre si. A divisão da comunidade sobre o que deveria ser a biblioteca padrão, o que deve ser incluído na distribuição principal e o que pode ser descarregado para as extensões ... Na minha opinião, isso impede o desenvolvimento da linguagem.
Denis Mirzoev : Faltam ferramentas: não há um IDE adequado, muito poucos benchmarks de desempenho, nenhuma depuração "passo a passo" - é uma questão fundamental.
Para quais projetos o Haskell é mais adequado?
YS : Para tarefas complexas, relacionadas à segurança e finanças, onde os erros são caros.
Doctor_Ryner : Para tudo onde você precisa calcular, converter e analisar. Estou surpreso que Haskell seja menos popular em aplicativos de ciência de dados do que Python.
IS : Eu não arriscaria usá-lo para sistemas embarcados (é rápido, mas ainda há sobrecarga significativa de memória devido à computação “lenta”) ou pequenos scripts (onde sua natureza estrita não é necessária). Também é importante entender o quão difícil é encontrar desenvolvedores em comparação com os idiomas comuns.
John Doe : Para escrever código industrial que será lido por outras pessoas, você precisará de toda uma equipe de desenvolvedores da Haskell. Não há muitos deles.
IS : Mas, graças à natureza concisa e estrita, você pode usar Haskell para quase tudo.
É uma boa idéia começar sua carreira de desenvolvimento na Haskell?
IS : Provavelmente não, porque a grande maioria das bases de código com as quais um desenvolvedor precisa trabalhar não está escrita nela.
John Doe : Má ideia! Idiomas não-ML - que são quase tudo em aplicações industriais - seriam um choque para você.
DS : Muitas vezes as pessoas aprendem matemática primeiro e mudam para a programação mais tarde. Então, teoricamente, aprender uma linguagem que requer muitos conceitos de matemática (tipos de dados algébricos, funções puras) deve ser mais fácil do que linguagens imperativas. Eu acho que é uma boa ideia.
Doctor_Ryner : Todos os desenvolvedores novatos com quem trabalho, apresento Haskell primeiro. As pessoas que não têm a bagagem do estilo imperativo são muito mais rápidas para aprender código funcional e, mesmo depois de trabalharem com linguagens orientadas a objetos, tendem a utilizar boas soluções de arquitetura porque estão acostumadas.
YS : É melhor começar com algumas linguagens fundamentalmente diferentes, como C, Haskell e Smalltalk, em qualquer ordem. Nenhum idioma poderia lhe dar um entendimento completo da paisagem.
Haskell é uma linguagem bastante antiga. Isso é bom ou ruim?
YS : A linguagem é desenvolvida muito ativamente, e não leva em consideração o peso da compatibilidade com versões anteriores.
John Doe : foi padronizado em 1998, mas você não notaria: até hoje, aproximadamente a cada 6 meses, há uma nova versão do compilador que pode potencialmente quebrar a compatibilidade com versões anteriores.
DS : Haskell não é velho, é simplesmente experimentado e testado. Não (e nunca) introduzirá mudanças irracionais. Portanto, provavelmente é bom para a saúde da comunidade.
Costuma-se dizer que Haskell é uma das línguas mais difíceis de aprender. É mesmo?
Doctor_Ryner : Como uma linguagem em si - não. A parte mais difícil são as abstrações que ele usa. Uma pessoa que nunca viu um código Haskell antes pode enlouquecer com a quantidade de novas informações e instruções estranhas. O que não ajuda é que a linguagem "restringe" muitas coisas que não se encaixam no seu conceito funcional.
John Doe : Levei dois meses de livros, manuais e tutoriais para dormir antes de compilar meu primeiro projeto. Pensamentos, uma vez que finalmente foi compilado, funcionou imediatamente a plena carga (média de 6k RPS, com 15k picos) por meio ano, sem alterações.
DS : Eu apostaria que, se você der um estudante universitário Haskell como primeira língua e ele for muito longe, a programação imperativa pareceria complicada e menos intuitiva para ele.
IS : É tudo relativo. Fora das linguagens convencionais, considero o C ++ o mais difícil. Linguagens que comprovam teoremas (como Agda ou Coq) são mais difíceis do que Haskell conceitualmente. Haskell não é uma linguagem difícil, mas leva tempo para aprender seu padrão e bibliotecas (padrão e de terceiros).
Sua complexidade é justificada?
IS : Padrões e um alto nível de abstração são justificados, pois tornam o código mais curto e mais durável. Mas acho que operadores, nomes de funções e muitas outras coisas poderiam ter sido um pouco mais amigáveis ao usuário.
Doctor_Ryner : Muitas vezes, a complexidade de Haskell permite criar soluções muito curtas, flexíveis e modulares.
YS : Eu diria que apenas o controle de efeitos é um pouco instável, embora ainda seja quase sempre preferível a nenhum controle. E há um projeto em andamento para simplificá-lo.
John Doe : Para pessoas acostumadas a Python / PHP / qualquer outra coisa, Haskell se sente desalojado da realidade. Para aqueles que você ainda não estava interessado na teoria das categorias, é muito difícil aprender do zero. Mas quando você o entende, encontra uma nova abordagem para resolver um problema.
Costuma-se dizer que Haskell não é uma linguagem para desenvolvedores, mas para matemáticos. É por isso que não é popular?
DS : Mostra a principal idéia dos principais desenvolvedores de Haskell - "evite o sucesso a todo custo". Não significa "evitar o sucesso", mas "evitar um sucesso muito caro".
Eles poderiam ter feito Haskell popular. Por exemplo, a Microsoft suporta o idioma. Eles poderiam ter tornado mais imperativo, sacrificar a rigidez pela popularidade. Há muitos truques sujos que eles poderiam ter usado, mas nunca usaram.
Claro, o idioma não é popular, mas isso significa que a qualidade não sofre. As vantagens de Haskell em comparação com as linguagens imperativas são óbvias para mim e todos os seus problemas podem ser resolvidos, então acredito que se popularizará mais tarde.
YS : Apenas pessoas que não sabem nada sobre isso dizem isso. Haskell é muito usado no desenvolvimento do "mundo real"; provavelmente você pode encontrar exemplos em seu mecanismo de pesquisa favorito. Em particular, nós da Kaspersky Labs estamos muito felizes com a Haskell e não a trocamos por mais nada.
IS : O que é uma "linguagem do matemático"? É o R / MatLab / Mathematica criado especificamente para estatísticas e cálculos, ou Python, porque é mais simples e não requer tanto conhecimento de engenharia. Mas não Haskell. Tem coisas de álgebra, como monóides, mas tem aplicação prática.
A razão pela qual C / C ++ / Java é tão popular é porque eles historicamente têm sido muito difundidos no espaço corporativo. Eles encheram um nicho. Atualmente, porém, muitas empresas começam a usar o Haskell e outras linguagens funcionais.
Com qual PL você compararia Haskell?
John Doe : fora dos populares, provavelmente com Erlang. Mas Erlang é mais simples de aprender e escrever.
DS : Conheço C, C ++, Java e Haskell. C ++ é horrível e não pode ser comparado a nada. C é ótimo para desenvolvimento de baixo nível. Em todas as outras aplicações, eu prefiro Haskell.
Escolher entre Java e Haskell é mais difícil, mas depende do aplicativo. Por exemplo, Java é melhor para Android, mas em aplicativos de servidor eles são quase iguais. Se o ambiente - ferramentas, bibliotecas - permitir, eu geralmente escolho Haskell.
Doctor_Ryner : Eu comparo com C #. Apenas o Google "como fazer Talvez em C # e Haskell". É estranho que uma linguagem estritamente funcional como Haskell pareça muito mais flexível e livre. Mas, na realidade, eles são os opostos polares.
C # é uma das linguagens mais orientadas a objetos e suas vantagens contrastam com Haskell. O C # sempre obriga a escrever muitas coisas extras, o que torna o código mais lento e geralmente o torna menos elegante. Após as soluções curtas e organizadas de Haskell, é difícil voltar.
IS : Com Rust, e até agora Rust provavelmente vence. É preciso muito do Haskell e de outras linguagens funcionais, mas combina abordagens funcionais e imperativas, além de os desenvolvedores terem lidado com seu desenvolvimento de maneira muito mais inteligente.
Qual a sua opinião sobre a comunidade Haskell?
John Doe : A grande maioria das pessoas é muito amigável e pronta para ajudar, o que é um bom contraste com muitas outras línguas.
Doctor_Ryner : As comunidades Haskell geralmente estão cheias de pessoas terrivelmente inteligentes. Os memes locais sobre PhDs e academia existem por uma razão. Em outras comunidades, as pessoas discutem principalmente problemas regulares de produção e estruturas de dados, enquanto em um bate-papo de Haskell as pessoas discutem mônadas, functores aplicativos, tipos malucos e coisas assim.
Você sempre aprende algo que nunca pensou antes.
Dizem que os desenvolvedores da Haskell são muito cheios de si mesmos. É verdade?
DS : Sim. Eu sinto que é porque eles realmente gostam da sua língua e estão desapontados com o quão impopular ela é.
John Doe : Nada disso.
Doctor_Ryner : As pessoas provavelmente dizem isso porque muitos desenvolvedores convencionais se irritam com um haskellist e começam a falar sobre programação funcional e suas vantagens. O Haskellist, enquanto isso, fica irritado porque ninguém o ouve e começa a usar a terminologia, e assim é rotulado como "cheio de si".
IS : É um pouco duro chamá-los assim. Provavelmente porque a programação funcional, OOP, diferenças entre classes e tipos de união OOP, o problema de extensão e muitas outras definições se desenvolvem lentamente em uma imagem coerente, e então é difícil entender as pessoas que continuam as guerras sagradas entre OOP e FP.
Por que as linguagens FP são tão específicas?
DS : Suas vantagens não são suficientes para interessar aos programadores. Ser difícil de aprender também não ajuda. As questões de ferramentas também assustam as pessoas, mesmo que esse problema provavelmente fosse resolvido se mais pessoas estivessem interessadas. É um ciclo vicioso.
IS : Bem, os conceitos de FP abrem caminho lentamente para outras línguas ...
Doctor_Ryner : Os princípios fundamentais do FP e suas línguas já são bastante difundidos. Até a Sharp possui o Linq e algumas outras bibliotecas semelhantes. Mas linguagens puramente funcionais provavelmente têm apenas muitos conceitos novos para serem populares.
Não se esqueça que, há 20 anos, o hardware ainda não era rápido o suficiente para lidar com linguagens funcionais; portanto, ele entrou no mainstream recentemente e o próprio Haskell está crescendo.