Não, essa não é outra tentativa de explicar as mônadas. Não sei como fazer isso e não consigo imaginar como, por exemplo, a partir do presente, eu poderia explicar isso para mim mesma do passado.
O mesmo se aplica a outros conceitos de FP. Eu entendo o valor deles, como usá-los. Mas não sei como transmitir isso a pessoas inicialmente inclinadas negativamente para uma abordagem funcional. Eu não acho que isso seja possível. A prática resolve facilmente esse assunto, mas as pessoas raramente o alcançam.
Eu nem sei responder a perguntas mais simples. Apesar de escrever no Scala há mais de três anos, não consigo explicar nos dedos as vantagens do idioma para uma pessoa de fora. Por exemplo, há alguns meses, tive uma boa discussão.
Tudo começou com a pergunta:
"E para quem é a sua linguagem escrita?" .
Toda essa imunidade, funções de ordem superior, um ótimo sistema de tipos, efeitos colaterais e outras mônadas giravam em minha mente, mas eu entendi que isso não era tudo isso. O esclarecimento subsequente finalmente me enviou um nocaute:
"Aqui, por exemplo, Java é uma linguagem para trabalhadores de colarinho branco" . Esse diálogo terminou com algumas bobagens incoerentes sobre a incapacidade de explicar a diferença sem prática.
Não sabemos como vender FP
Isso não é apenas uma recontagem da experiência pessoal. Todos nós, usuários de linguagens funcionais, estamos aproximadamente na mesma situação. Entendemos perfeitamente a enorme diferença em comparação com os idiomas do
Blub , mas o resto do mundo não quer nos ouvir. Certamente, pode-se ficar zangado com os conservadores limitados que vendem "G", calmamente carregam bobagens, recontam mitos e contos de fadas, entram com firmeza e confiança em discussões sobre coisas nas quais eles nem sequer passaram algumas horas. Você também pode culpar grandes empresas com suas equipes de profissionais de marketing.
Mas parece-me, antes de tudo, o problema é que nós mesmos não sabemos como vender FP. Sim, essa não é uma tarefa fácil. Embora, quando me lembro de como as pessoas tomam decisões, como e quais coisas estão incluídas nas tendências, começo a pensar que isso é possível.
Sempre há algo errado com o desenvolvimento.
- Os processos são lentos! E agora, depois de alguns anos, todas as manhãs, em todos os escritórios do país, as pessoas que estão no quadro-negro arrastam adesivos de uma coluna para outra.
- A implantação é lenta! E armados com valores de devops, fazemos 10 lançamentos por dia, enquanto uma nova geração de administradores o inunda com toneladas de rubi, python e yaml.
- As aplicações são complicadas! Assim, equipes de 2 a 3 desenvolvedores estão construindo uma nova arquitetura de microsserviço, pensando nas responsabilidades de cada serviço em detalhes e fazendo 10 solicitações de pool para uma pequena revisão.
Não que eu considerasse todas essas manias da indústria ruins. Eles também têm muitas falhas também. E nem todo mundo sabia como ou como cozinhá-los corretamente. Afinação conveniente ausente ou ausente. No entanto, essas abordagens se tornaram um padrão "de fato" para o setor. E embora a discussão sobre estivador na produção para alguns pareça uma questão em aberto, tudo já aconteceu.
Estou certo de que a mesma coisa pode acontecer com linguagens funcionais. Sim, isso não está totalmente correto - comparar linguagens de programação com metodologias e abordagens. Mas temos algo a emprestar em seu posicionamento para nós mesmos. Todos eles têm um
problema estritamente definido que resolvem. E isso é velocidade: desenvolvimento, comunicação, planejamento, implantação, alterações.
Por que esquecemos de dizer a coisa mais importante?
Ao mesmo tempo, do ponto de vista do posicionamento de linguagens de programação funcionais, é difícil dizer que elas têm um objetivo claro e compreensível. Os acadêmicos de linguística “
FP vs OOP ” geralmente deslizam rapidamente para uma medida de características e conceitos cujo valor não é bem compreendido pelo campo de OOP. Artigos e relatórios do formato “
Você vê como essas mônadas são soberbamente compostas ” geralmente reforçam as pessoas na opinião de que elas não precisam disso, do que inspiram a tentar. Todas essas interações raramente respondem à pergunta “
Por que isso é tudo? " Bonito e conciso? Bem, na melhor das hipóteses, menos erros serão mencionados.
A coisa mais importante no uso de linguagens funcionais é a mesma velocidade de desenvolvimento! E essa velocidade é alcançada por todos esses termos, conceitos e propriedades entediantes e assustadores que emergem deles. Composição mais leve devido a funções de ordem superior - mais à velocidade de desenvolvimento. A imunidade, além de confiabilidade e menos erros, é equivalente a dar mais tempo para coisas úteis, em vez de gastá-la em depuração, hotfixes e suporte. Bem e assim por diante, acho que a lógica é clara.
Sim, isso parece muito simples e até óbvio.
Sim, eu não disse nada de novo aqui. Mas a importância da redação e ênfase é importante. Infelizmente, é assim que o nosso pensamento funciona. Para derrubar barreiras, explicações por si só não são suficientes. Precisa de prática! É necessário que uma pessoa ou empresa queira gastar tempo com isso. Referências a "acadêmica" ou beleza relativa inspirarão poucos a passar vários dias se sentindo um idiota.
Vale a pena parar de se formar como caras sábios, espalhando imediatamente os termos para a esquerda e para a direita, comprovando a superioridade do seu YP favorito sobre o
Blub . Em vez de provar a utilidade do recurso X, é muito mais fácil usá-lo como uma explicação de alguma propriedade mais compreensível. Se outros técnicos tiverem sucesso, talvez seja hora de assumirmos a responsabilidade e entrar com firmeza com coisas óbvias e simples.
Então, da próxima vez, com as dificuldades de responder à pergunta “
Por quê? ”, Não hesite em usar trunfos, como:
maior velocidade de desenvolvimento ,
suporte mais barato ,
menos desenvolvedores .
Ah e mais. Os eventos da comunidade também desempenham um papel significativo no posicionamento!
Portanto, aguardamos todos os que não são indiferentes ao FP na única conferência funcional na Rússia - FPURE - Kazan - de 24 a 25 de maio .
O programa inclui: Haskell, Scala, Elixir, Clojure, teoria e prática e, claro, muitas pessoas afins com as quais há algo para conversar!