Quais seriam os bons argumentos factuais para convencer o gerenciamento de alto nível a considerar a programação funcional? [fechadas]

Existem muitos argumentos "teóricos" sobre por que a programação funcional é uma boa idéia (muitos para que isso permaneça como uma questão em aberto, e corretamente).

No entanto, a maioria deles são argumentos feitos a partir de teoria ("elegância", etc ...) ou direcionados a desenvolvedores.

O problema é que a maioria deles é totalmente inútil quando o objetivo é apresentar a idéia à gerência sênior de uma grande empresa , algumas das quais nem mesmo são desenvolvedores, e todas se preocupam principalmente com argumentos de negócios : custo, gerenciamento de capital humano entrega de produtos, atendimento ao cliente e receita; bem como fatos quantitativos sobre pontos teóricos que não podem ser totalmente respaldados por fatos.

Existem argumentos convincentes a serem apresentados para abordar essas preocupações de negócios, considerando a adoção da programação funcional como um conceito (não qualquer linguagem específica), versus a combinação típica de procedimentos / OOP, por exemplo, Java / C ++ / (Perl | Python) .

De preferência, procuro argumentos quantitativos e / ou baseados em pesquisas ou estudos de caso. Por exemplo, "de acordo com essa referência, a taxa de erros dos sistemas multithread no Lisp / F # é 10% da do Java" ou "80% dos graduados expressam preferências da tecnologia desejada denominada programação funcional como um dos 3 principais interesses".

Eu sei que Graham apresentou casos de uso de programação funcional para uma iniciação e estaria aberto a alguns de seus argumentos, assumindo que eles podem ser válidos para uma empresa estabelecida maior.

_{psI estou perfeitamente ciente de que você pode fazer algo próximo à programação funcional em Perl, provavelmente Python e (possivelmente) até Java 8 ou C ++ 14. Mas isso não significa que uma organização usando Perl, C ++ ou Java endossaria funcional vs OOP / abordagens processuais mesmo nesses idiomas}

_{Para os propósitos dessa linguagem, "grande" é definido como grande o suficiente para ter um grupo dedicado de engenharia / ferramentas de desenvolvimento, que determina o que todos os desenvolvedores têm permissão para usar / fazer; e pelo menos centenas de desenvolvedores de gama baixa} .

Há um argumento muito simples, que pode pelo menos divertir a gerência.

É sabido que os computadores modernos não estão se tornando "mais rápidos" como costumavam ser, porque a escala de frequência, por enquanto, atingiu o limite. Eles aumentam sua produtividade potencial adicionando núcleos.

Isso implica que, para se beneficiarem mais dessa arquitetura, os programas precisam ser paralelizados. Mas a programação paralela é muito mais difícil que a programação seqüencial, devido a muitos novos desafios que ela traz (consulte artigo da Wiki para obter uma visão geral abrangente).

A programação funcional ajuda a se livrar de alguns desses desafios, por exemplo, condições de corrida não se aplicam se você usar apenas variáveis ​​e métodos imutáveis ​​sem efeitos colaterais. A curva de aprendizado para programação funcional geralmente é íngreme, mas a curva de aprendizado para programação paralela pode ser ainda mais acentuada e nem intuitiva.

Portanto, se o desafio é escrever programas mais eficientes de maneira mais eficiente, pode-se comparar os custos de treinar pessoas para escrever programas paralelos com os custos de treinar pessoas para aprender programação funcional e os riscos que ambas abordam.

Em relação às linguagens mistas (que suportam o estilo de programação funcional e imperativo): a partir de um ponto, elas podem ser úteis para a transição (as pessoas podem começar a usá-las da maneira "familiar" e gradualmente aprender novas abordagens). De outro ponto, isso pode ser uma bênção disfarçada, porque as vantagens potenciais que a programação funcional traz podem ser canceladas com o código desajeitado de alguém. Pode-se mitigar isso estabelecendo diretrizes claras de codificação (consulte, por exemplo, " Scala eficaz " pelo Twitter), embora seguir as diretrizes exija um certo nível de maturidade da equipe. Desse ponto de vista, linguagens funcionais puras podem ser "mais fáceis" para o desenvolvimento de software, devido às regras mais rígidas que eles impõem pelo design.

Você está abordando isso do lado errado. Na maioria das empresas, a gerência não é responsável por "escolher o paradigma de programação", é (ou pelo menos deveria ser) responsável por tornar a equipe eficiente. Se toda a sua equipe está convencida de que a programação funcional melhorará a velocidade ou a qualidade do seu trabalho, não deve ser muito difícil convencer o gerenciamento também. Além disso, se sua equipe começar a usar construções funcionais em suas linguagens de programação estabelecidas, e todo mundo estiver feliz com isso, você nem precisará pedir permissão (diabos, um não programador pode nem entender a diferença entre não- construções funcionais e funcionais, por que você quer discutir esse assunto com ele?).

Mas cuidado, se o resto da sua equipe tem uma opinião diferente sobre o FP e eles começam a reclamar do seu código funcional que os outros membros da equipe não entendem, você pode ter problemas com a gerência - por um bom motivo, pois Nesse caso, a equipe perde eficiência.

Portanto, o essencial é: convencer outros membros da equipe ou seus líderes, mas não a gerência de alto nível!

EDIT: devido ao seu comentário - na verdade, esta é uma resposta para sua pergunta ;-). O único argumento factual de que estou falando é "toda a equipe acha que a FP é útil para fazer o trabalho . IMHO é o argumento com a maior chance de ser aceito pela gerência de alto nível e é praticamente aplicável. Tentando usar argumentos técnicos para pessoas não técnicas raramente funciona diretamente, não porque elas são "burras demais para entender o raciocínio técnico", mas porque são inteligentes o suficiente para saber que decisões técnicas devem ser tomadas por especialistas técnicos e também são inteligentes o suficiente para não confiar na opinião de apenas um especialista.

Para entender por que a Programação Funcional não dominou o mundo, você precisa entender o pensamento corporativo por trás das decisões da linguagem de programação. Para escolher o Java por um momento:

1. Existem exércitos de programadores disponíveis que podem escrever resmas de código Java comum. Isso não se aplica aos programadores Lisp ou Haskell (ou mesmo Scala).
2. Todo mundo está usando Java, então deve ser bom. Corrolary: os gerentes não precisam justificar sua escolha de Java versus uma linguagem obscura da qual ninguém na estrutura de comando jamais ouviu falar.

Se sua organização já está entrincheirada no Reino dos Substantivos , fazer uma mudança geral na Programação Funcional simplesmente não acontecerá. A escolha do idioma (e todas as outras opções que o cercam) já está profundamente enraizada na cultura corporativa.

Supondo que seu objetivo seja crescer como desenvolvedor de software, sua melhor aposta é

1. Incorpore conceitos funcionais aos programas existentes, onde eles são úteis e apropriados,
2. Use novos recursos de linguagem funcional à medida que são adicionados ao idioma e
3. Aprenda padrões de design orientados a objetos, alguns dos quais existem para superar as deficiências de idioma nos idiomas OO que não estão presentes nos idiomas funcionais.

Os argumentos de Paul Graham realmente se aplicam apenas às startups, e houve várias histórias de advertência de empresas que começaram usando linguagens puramente funcionais, mas foram compradas por outra empresa cuja primeira ordem de negócios era converter imediatamente a base de código funcional para uma linguagem OO, para que seus desenvolvedores de software existentes possam entendê-la.

Na minha experiência (um tanto cínica), tendo trabalhado para uma loja onde usamos programação funcional e entrevistado em várias outras:

1. Sempre havia um CTO e outras pessoas técnicas de alto nível que tinham experiência com programação funcional e conseguiam convencer seus executivos não técnicos. (E, aliás, essas pessoas estão melhor qualificadas para responder à sua pergunta do que eu.)
2. Quando essas pessoas saem da empresa e são substituídas por pessoas que não têm essa inclinação, as coisas vão para o sul. Os novos caras culparão tudo o que der errado (incluindo, e particularmente suas próprias falhas), a estranha linguagem de programação e paradigma usado para construir o que veio antes. Eles marginalizarão o restante das pessoas com habilidades de programação funcional, empurrando-os para fora da empresa. O sistema construído na linguagem funcional se deteriorará sem manutenção. Na minha opinião, esse tipo de coisa é o maior risco que uma empresa assume se adotar uma linguagem funcional e não deve ser subestimada.
3. A organização precisa ter uma cultura "construir em vez de comprar" para que isso funcione. Porque adotar uma linguagem funcional significará menos opções de "compra".
4. Quase sempre havia algum comprometimento com os detratores técnicos e não técnicos da ideia. O mais comum desses compromissos é que qualquer linguagem que não seja da JVM estava apenas fora de consideração; Clojure e Scala foram propostos, Haskell e O'Caml estavam logo de cara.

Pontos a serem considerados para a alta gerência quando / se a alta gerência estiver envolvida na seleção de linguagens de programação (o que é estranho, eles devem deixar para pessoas confiáveis ​​e conhecedoras (tanto em tecnologia quanto em negócios):

• Produtividade
  • Funcionários atuais e futuros
  • Todas as funções (arquitetos, desenvolvedores, testadores, OPs, ...)
• Plataformas suportadas
  • Sistemas operacionais (hardware?)
• Editor do idioma / plataforma
  • Licenças
• Maturidade da língua / plataforma
  • Suporte de / pelo editor e / ou comunidade
  • Bibliotecas
• Migrando a Base de Código Atual
  • Ou integração com

Observe que eles não são específicos para linguagens de programação funcionais. Também não há argumentos, a menos que você forneça dados. Não podemos fornecer os dados, pois eles dependem completamente do ambiente da sua empresa. A única coisa que poderíamos fazer é coletar dados da Web para mostrar quanto conhecimento e interesse existe para um idioma específico. Tenha cuidado ao traduzir muitas perguntas no StackOverflow ou muitas tags no Linkedin para um idioma popular.

Não acho que argumentos ou fatos ajudem. E certamente não sem declarar os problemas que você deseja resolver.

Contra a crença comum e a auto-avaliação típica, muitas decisões são tomadas com base no pressentimento. E muitas vezes essas decisões são decisões muito boas, porque incorporam no nível subconsciente muita experiência do indivíduo que toma a decisão.

Se você quiser contestar uma decisão como "Vamos nos ater à linguagem C até o final de todos os computadores", será necessário fazer mais do que apenas fornecer alguns argumentos.

O primeiro passo é provavelmente descobrir as pessoas e os motivos por trás da decisão de que a alta gerência deve ter um ditado nessas decisões técnicas. É claro que só posso adivinhar aqui, mas é muito provável que tenham um histórico de decisões tomadas por pessoal técnico que deram errado. Vamos ser sinceros: a maioria dos desenvolvedores não é muito boa em tomar decisões (mesmo técnicas) no nível da empresa.

Depois de encontrar essas pessoas, converse com elas para ganhar confiança. Possivelmente, a melhor abordagem é: ouvi-los. Com o que eles estão preocupados, quais são os riscos e as chances que vêem. Quais são os problemas com os quais eles são desafiados. A partir daqui, você pode avançar para envolver as pessoas da tecnologia nesse tipo de decisão. A gerência geralmente não quer tomar essas decisões, mas não confia nos outros. Portanto, se sua equipe começar a se envolver na decisão de arquitetura e demonstrar que as decisões que você propõe são de boa gestão, podem estar dispostas a confiar em você / em sua equipe.

Importante para ter boas decisões arquitetônicas é:

• Reúna informações dos interessados ​​(gerência, usuários, administradores, vendas, clientes ...)
• Baseie as decisões nessa entrada
• Comunique claramente: Quais são as decisões (propostas); Que risco eles pretendem mitigar; O que são interesses conflitantes e com algum atraso: quão bem eles funcionaram.

Se você trabalha em uma grande empresa com mais de 10 mil funcionários, esteja preparado para aprender algumas das lições a seguir.

• a velocidade da codificação não é realmente relevante para os resultados.
• coisas como manutenção na escala de décadas é.
• os problemas que você acha que pode resolver usando linguagens funcionais não são realmente relevantes para os resultados
• problemas como o treinamento de 1000 desenvolvedores, a resistência natural à mudança e a manutenção de uma base de código criada por desenvolvedores com menos de 5 anos de experiência na tecnologia usada.

Depois de atingir um nível de confiança de que seus argumentos são ouvidos e considerados, você também estabelecerá uma maneira de reunir e considerar os requisitos nos quais você, sua equipe e a gerência confiam.

Se esse processo produzir a recomendação de usar uma abordagem funcional em determinadas áreas, você estará pronto.

Se esse processo produzir a recomendação para ignorar as abordagens funcionais que vão além do que a atual linguagem de programação principal oferece, você também será executado.

A má notícia é: Dependendo do tamanho e estilo da empresa, isso pode levar alguns anos ou décadas.

A boa notícia é: você aprenderá muito no caminho.

Como o primeiro passo é começar a conversar e ouvir especialmente a gerência sênior, recomendo começar lendo Just Listen .

Uma boa abordagem seria mostrar que ele mostra bons resultados no setor e é adotado.

Você pode obter alguns dados de:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

Idealmente, tente conversar com os gerentes de algumas empresas listadas, especialmente no setor, e obtenha números e depoimentos deles.

O Google tem muitos outros links semelhantes para Haskell, OCaml etc.

Você está chegando a isto da direção errada.

Você está tentando convencer o gerenciamento de uma mudança para um paradigma funcional para sua própria diversão e está tentando reunir argumentos para apoiar isso que não têm nada a ver com a verdadeira razão pela qual você deseja. Caso contrário, você não precisaria fazer a pergunta, porque seria capaz de listar seus argumentos do alto de sua cabeça.

Em vez disso, o que você deve pensar é qual é a necessidade atual dos negócios e como é melhor atendida. Se isso acontecer, é melhor servi-lo usando um paradigma funcional - sim! - você começa a jogar. Mas se você fizer uma análise justa, levando em consideração as necessidades operacionais dos negócios, o treinamento necessário de colegas de trabalho, o histórico de futuros programadores, a manutenção e assim por diante, muitas vezes não será.

A gerência sênior sem habilidades técnicas não deve se preocupar com aspectos técnicos, como o uso de paradigmas funcionais. Esse não é seu domínio de especialização e cheira a microgerenciamento. Por que eles não estão delegando essas decisões a pessoas que realmente precisam de habilidades?

Dito isto, aqui estão algumas dicas para convencer as pessoas com formação técnica (primeiro caso) e aquelas sem um (segundo caso).

Primeiro caso

Se você está conversando com pessoas que conhecem programação , comparar o código escrito sem paradigmas de programação funcional e o mesmo código escrito no estilo funcional pode ser bastante convincente:

Exemplo de código C # que usa estilo imperativo:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

O mesmo código reescrito com a programação funcional em mente:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Então pergunte a eles:

1. Quantos erros um programador pode cometer na primeira amostra? E o segundo?

2. Quão difícil é detectar erros?

3. Quão difícil é modificar o código?

Todos os três fatores influenciam a produtividade e, portanto, o custo do produto.

Segundo caso

Se você está lidando com pessoas que não conhecem programação, não há muita coisa técnica que você possa dizer a elas. Uma das maneiras de convencer é mostrar o impacto real dos paradigmas funcionais em seu trabalho e no trabalho de seus colegas de trabalho.

Por exemplo, compare dois projetos feitos pela mesma equipe, um usando FP, outro não. Mostrar que o número de bugs é muito menor ou que esse foi o primeiro projeto que a empresa realmente entregou a tempo deve ser suficientemente convincente.