Quali sarebbero buoni argomenti concreti per convincere il management di alto livello a considerare la programmazione funzionale? [chiuso]

Ci sono tonnellate di argomenti "teorici" sul perché la programmazione funzionale sia una buona idea (troppi per essere rimasti come una domanda aperta, e correttamente così).

Tuttavia, la maggior parte di essi sono argomenti tratti dalla teoria ("eleganza", ecc ...) o rivolti agli sviluppatori.

Il problema è che la maggior parte di essi sono del tutto inutili quando l'obiettivo è quello di presentare l'idea al senior management di una grande azienda , alcuni dei quali non sono nemmeno sviluppatori, e tutti a cui interessano principalmente argomenti di business : costo, gestione del capitale umano , consegna del prodotto, servizio clienti e entrate; così come fatti quantitativi su punti teorici di cui non si può del tutto sostenere fatti.

Ci sono argomenti convincenti da presentare per affrontare tali problemi aziendali per quanto riguarda l'adozione della programmazione funzionale come concetto (non un linguaggio specifico), rispetto al tipico mix di procedurale / OOP, ad esempio Java / C ++ / (Perl | Python) .

Preferibilmente, sto cercando argomenti quantitativi e / o basati su ricerche o casi di studio. Ad esempio "secondo questo riferimento, il tasso di bug dei sistemi multithread in Lisp / F # è del 10% quello di Java" o "L'80% dei migliori laureati che esprimono le preferenze della tecnologia desiderata denominata programmazione funzionale come uno dei primi 3 interessi".

So che Graham ha presentato casi d'uso di programmazione funzionale per una starup e sarebbe aperto ad alcuni dei suoi argomenti supponendo che possano essere validi per un'azienda più grande.

_{psSono perfettamente consapevole che puoi fare qualcosa di simile alla programmazione funzionale in Perl, probabilmente Python e (forse) anche Java 8 o C ++ 14. Ma ciò non significa che un'organizzazione che utilizza Perl, C ++ o Java approverebbe funzionale vs OOP / approcci procedurali anche in quelle lingue}

_{Ai fini di questo linguaggio, "grande" è definito abbastanza grande da avere un gruppo dedicato di ingegneria / strumenti di sviluppo, che determina ciò che tutti gli sviluppatori sono autorizzati a utilizzare / fare; e almeno centinaia di sviluppatori di fascia bassa} .

C'è un argomento molto semplice, che potrebbe almeno divertire la gestione.

È noto che i computer moderni non stanno diventando "più veloci" come una volta, perché il ridimensionamento della frequenza, per ora, ha raggiunto il limite. Aumentano la loro potenziale produttività aggiungendo core.

Ciò implica che per beneficiare maggiormente di questa architettura, i programmi devono essere parallelizzati. Ma la programmazione parallela è molto più difficile della programmazione sequenziale, a causa di molte nuove sfide (consulta l' articolo Wiki per una panoramica completa).

La programmazione funzionale aiuta a sbarazzarsi di alcune di queste sfide, ad esempio le condizioni di gara non si applicano se si utilizzano solo variabili e metodi immutabili senza effetti collaterali. La curva di apprendimento per la programmazione funzionale è spesso ripida, ma la curva di apprendimento per la programmazione parallela potrebbe essere ancora più ripida e per nulla intuitiva.

Quindi, se la sfida è scrivere programmi più efficienti in modo più efficiente, si possono confrontare i costi di formazione delle persone a scrivere programmi paralleli con i costi di formazione delle persone per apprendere la programmazione funzionale e i rischi che entrambi gli approcci potrebbero comportare.

Per quanto riguarda i linguaggi misti (che supportano lo stile di programmazione sia funzionale che imperativo): da un punto di vista potrebbero essere utili per la transizione (le persone potrebbero iniziare a usarli in modo "familiare" e apprendere gradualmente nuovi approcci). Da un altro punto, questa potrebbe essere una benedizione sotto mentite spoglie, perché i potenziali vantaggi apportati dalla programmazione funzionale potrebbero essere annullati con il codice goffo di qualcuno. Si può mitigare ciò stabilendo chiare linee guida per la codifica (vedere ad esempio " Scala efficace " di Twitter), sebbene seguire le linee guida richieda un certo livello di maturità della squadra. Da questo punto di vista, i linguaggi funzionali puri potrebbero essere "più facili" per lo sviluppo del software a causa delle regole più severe che impongono in base alla progettazione.

Ti stai avvicinando dalla parte sbagliata. Nella maggior parte delle aziende, il management non è responsabile della "scelta del paradigma di programmazione", sono (o almeno dovrebbero essere) responsabili di rendere efficiente il lavoro del team. Se tutto il tuo team è convinto che la programmazione funzionale migliorerà la velocità o la qualità del tuo lavoro, non dovrebbe essere troppo difficile convincere anche il management. Inoltre, se il tuo team inizia a utilizzare costrutti funzionali nei linguaggi di programmazione stabiliti e tutti ne sono soddisfatti, non dovresti nemmeno chiedere un'autorizzazione (diamine, un non programmatore potrebbe non capire nemmeno la differenza tra non- costrutti funzionali e funzionali, quindi perché vuoi discutere di questo problema con lui?).

Ma attenzione, se il resto del tuo team ha un'opinione diversa su FP e iniziano a lamentarsi del tuo codice funzionale che altri membri del team non comprendono, potresti avere dei problemi con la gestione - per una buona ragione, dal momento che in un caso, il team perde efficienza.

Quindi l'essenza è: convincere gli altri membri del team, o i leader del tuo team, ma non una gestione di alto livello!

EDIT: a causa del tuo commento - in realtà, questa è una risposta alla tua domanda ;-). L'unico argomento fattuale di cui sto parlando è "tutto il team pensa che FP sia utile per fare il lavoro . IMHO è l'argomento con la più alta possibilità di essere accettato da un management di alto livello ed è praticamente applicabile. Cercare di usare argomenti tecnici alle persone non tecniche lavorano raramente direttamente, non perché sono "troppo stupide per capire il ragionamento tecnico", ma perché sono abbastanza intelligenti da sapere che le decisioni tecniche dovrebbero essere prese da esperti tecnici, e sono anche abbastanza intelligenti da non fare affidamento secondo l'opinione di un solo esperto.

Per capire perché la programmazione funzionale non ha preso il controllo del mondo, è necessario comprendere il pensiero aziendale alla base delle decisioni relative al linguaggio di programmazione. Per scegliere Java per un momento:

1. Esistono eserciti di programmatori che possono scrivere risme del normale codice Java. Questo non è vero per i programmatori Lisp o Haskell (o persino Scala).
2. Tutti gli altri usano Java, quindi deve essere buono. Corricolo: i gestori non devono giustificare la scelta di Java rispetto a un linguaggio oscuro di cui nessuno nella struttura di comando ha mai sentito parlare.

Se la tua organizzazione è già radicata nel Regno dei sostantivi , non sarà possibile apportare una modifica globale alla programmazione funzionale. La scelta della lingua (e tutte le altre scelte che la circondano) è già profondamente radicata nella cultura aziendale.

Supponendo che il tuo obiettivo sia crescere come sviluppatore di software, la soluzione migliore è farlo

1. Incorporare concetti funzionali nei programmi esistenti dove sono utili e appropriati,
2. Utilizzare le nuove funzionalità del linguaggio funzionale man mano che vengono aggiunte alla lingua e
3. Impara modelli di progettazione orientati agli oggetti, alcuni dei quali esistono per superare le carenze linguistiche nei linguaggi OO che non sono presenti nei linguaggi funzionali.

Le argomentazioni di Paul Graham si applicano solo alle startup, e ci sono state diverse storie di ammonimento di aziende che hanno iniziato usando linguaggi puramente funzionali, ma poi sono state acquistate da un'altra società il cui primo ordine di attività era convertire immediatamente la base di codice funzionale in un linguaggio OO in modo che i loro sviluppatori di software esistenti possano capirlo.

Nella mia (in qualche modo cinica) esperienza, avendo lavorato per un negozio in cui abbiamo usato la programmazione funzionale e intervistato in molti altri:

1. C'era sempre un CTO e altre persone tecniche di alto livello che avevano esperienza con la programmazione funzionale e sono riusciti a convincere i dirigenti non tecnici di esso. (E per inciso, queste persone sono più qualificate per rispondere alla tua domanda di me.)
2. Una volta che queste persone lasciano la compagnia e vengono sostituite da persone che non hanno questa inclinazione, le cose andranno a sud. I nuovi ragazzi daranno la colpa di tutto ciò che va storto (compresi, e in particolare i loro stessi fallimenti) allo strano linguaggio di programmazione e paradigma utilizzato per costruire ciò che è accaduto prima. Emargineranno le persone rimaste con capacità di programmazione funzionale, spingendole fuori dalla compagnia. Il sistema basato sul linguaggio funzionale si deteriorerà senza essere mantenuto. Questo genere di cose, secondo me, il più grande rischio che un'azienda corre se adotta un linguaggio funzionale e non deve essere sottovalutata.
3. L'organizzazione deve avere una cultura "costruisci invece di comprare" per farlo funzionare. Perché l'adozione di un linguaggio funzionale significherà meno opzioni di "acquisto".
4. C'era quasi sempre qualche compromesso per i detrattori tecnici e non tecnici dell'idea. Il più comune di questi compromessi è che qualsiasi linguaggio non JVM era appena preso in considerazione; Furono proposti Clojure e Scala, Haskell e O'Caml erano appena usciti dalla mazza.

Aspetti da considerare per il vertice aziendale quando / se il vertice aziendale è coinvolto nella selezione dei linguaggi di programmazione (il che è strano, dovrebbero lasciarlo a persone fidate e competenti (sia tecnologicamente che esperti di business):

• Produttività
  • Dipendenti attuali e futuri
  • Tutti i ruoli (architetti, sviluppatori, tester, OP, ...)
• Piattaforme supportate
  • Sistemi operativi, (hardware?)
• Editore della lingua / piattaforma
  • licenze
• Maturità della lingua / piattaforma
  • Supporto di / da parte dell'editore e / o della community
  • biblioteche
• Migrazione della base di codice corrente
  • O integrazione con

Si noti che questi non sono specifici dei linguaggi di programmazione funzionale. Anche questi non sono argomenti a meno che tu non fornisca dati con questi. Non possiamo fornirti i dati poiché dipendono completamente dall'ambiente aziendale. L'unica cosa che potremmo fare è raccogliere dati dal web per mostrare quanta conoscenza e interesse ci sia per una lingua specifica. Fai attenzione quando traduci molte domande su StackOverflow o molti tag su Linkedin in una lingua molto popolare.

Non credo che argomenti o fatti possano essere d'aiuto. E certamente non senza indicare i problemi che vuoi risolvere.

Contro la credenza comune e l'autovalutazione tipica, molte decisioni vengono prese in base al sentimento intestinale. E spesso queste decisioni sono ottime decisioni, perché incorporano a livello subconscio molta esperienza dell'individuo che prende la decisione.

Se vuoi contestare una decisione del genere come "Ci atterremo al linguaggio simile a C fino alla fine di tutti i computer" devi fare di più che semplicemente fornire alcuni argomenti.

Il primo passo è probabilmente quello di scoprire le persone e le ragioni dietro la decisione che l'alta dirigenza dovrebbe avere voce in capitolo in tali decisioni tecniche. Ovviamente posso solo indovinare qui, ma molto probabilmente hanno una buona reputazione di decisioni prese da personale tecnico andato male. Ammettiamolo: la maggior parte degli sviluppatori non è molto brava a prendere decisioni (anche tecniche) a livello aziendale.

Una volta che hai trovato queste persone, parla con loro per guadagnare fiducia. Forse l'approccio migliore è: ascoltali. Di cosa sono preoccupati, quali sono i rischi e le possibilità che vedono. Quali sono i problemi con cui vengono messi alla prova. Da qui potresti muoverti per coinvolgere le persone tecnologiche in questo tipo di decisione. Il management spesso non vuole davvero prendere queste decisioni, ma non si fida degli altri. Quindi, se il tuo team inizia a essere coinvolto nella decisione architettonica e dimostra che le decisioni che proponi sono una sana gestione potrebbe essere disposto a fidarti di te / del tuo team.

Importante per prendere decisioni sull'architettura solida è:

• Raccogliere input dai portatori di interessi (gestione, utenti, amministratori, vendite, clienti ...)
• Basare le decisioni su quell'input
• Comunicare chiaramente: quali sono le decisioni (proposte); Quali rischi mirano a mitigare; Quali sono gli interessi contrastanti e con qualche ritardo: quanto hanno funzionato bene.

Se lavori per una grande azienda con circa 10.000 dipendenti, preparati a imparare alcune delle seguenti lezioni.

• la velocità di codifica non è realmente rilevante per la linea di fondo.
• cose come la manutenibilità su scala decennale è.
• i problemi che pensi di poter risolvere usando linguaggi funzionali non sono realmente rilevanti per la linea di fondo
• problemi come la formazione di 1000 sviluppatori, la naturale resistenza al cambiamento e il mantenimento di una base di codice scritta da sviluppatori con meno di 5 anni di esperienza nella tecnologia utilizzata.

Una volta raggiunto un livello di fiducia nel fatto che i tuoi argomenti siano ascoltati e considerati, avrai anche stabilito un modo per raccogliere e considerare i requisiti di cui tu, il tuo team e il management vi fidate.

Se questo processo produce la raccomandazione di utilizzare un approccio funzionale in determinate aree, il problema è stato risolto.

Se questo processo produce la raccomandazione di ignorare gli approcci funzionali che vanno al di là di ciò che offre l'attuale linguaggio di programmazione principale, anche voi siete fatti.

La cattiva notizia è: a seconda delle dimensioni e dello stile dell'azienda, ciò potrebbe richiedere facilmente un paio d'anni o decenni.

La buona notizia è: imparerai molto sulla strada.

Dal momento che il primo passo è iniziare a parlare e soprattutto ascoltare i dirigenti, ti consiglio di iniziare a leggere Just Listen .

Un buon approccio sarebbe quello di dimostrare che ha mostrato buoni risultati nel settore e adottato.

Puoi ottenere alcuni dati da:

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

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

Idealmente, prova a parlare con i dirigenti di alcune società quotate, soprattutto se nel tuo settore, e ottenere numeri e testimonianze da loro.

Google ha molti altri collegamenti simili per Haskell, OCaml, ecc.

Ci stai arrivando dalla direzione sbagliata.

Stai cercando di convincere la gestione di un passaggio a un paradigma funzionale per il tuo divertimento e stai cercando di raccogliere argomenti per sostenere questo che non hanno nulla a che fare con il vero motivo per cui lo vuoi. Altrimenti non dovresti porre la domanda, perché potresti elencare i tuoi argomenti dalla cima della tua testa.

Piuttosto, ciò a cui dovresti pensare è qual è l'esigenza aziendale attuale e come viene servita al meglio. Se succede che è meglio servirlo usando un paradigma funzionale, allora - yay! - puoi giocare. Ma se si esegue un'analisi equa, tenendo conto delle esigenze aziendali operative, della formazione necessaria per i colleghi, delle esperienze dei futuri programmatori, della manutenzione e così via, e così via, spesso non lo sarà.

Il senior management senza competenze tecniche non dovrebbe preoccuparsi di aspetti tecnici come l'uso di paradigmi funzionali. Questo non è il loro dominio di competenza e profuma di microgestione. Perché non stanno delegando quelle decisioni a persone che hanno effettivamente le competenze richieste?

Detto questo, ecco alcuni suggerimenti per convincere le persone con background tecnico (primo caso) e quelle senza (secondo caso).

Primo caso

Se stai parlando con persone che conoscono la programmazione , confrontare il codice scritto senza paradigmi di programmazione funzionale e lo stesso codice scritto in stile funzionale può essere abbastanza convincente:

Codice di esempio C # che utilizza uno stile 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);
}

Stesso codice riscritto pensando alla programmazione funzionale:

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))
    );

Quindi chiedi loro:

1. Quanti errori può fare un programmatore nel primo campione? E la seconda?

2. Quanto è difficile individuare errori?

3. Quanto è difficile modificare il codice?

Tutti e tre i fattori influenzano la produttività e quindi il costo del prodotto.

Secondo caso

Se hai a che fare con persone che non conoscono la programmazione, non c'è molto materiale tecnico che puoi dire loro. Uno dei modi per essere convincente è mostrare l'impatto reale dei paradigmi funzionali sul tuo lavoro e sul lavoro dei tuoi colleghi.

Ad esempio, confronta due progetti realizzati dallo stesso team, uno che utilizza FP, l'altro che non lo utilizza. Mostrare che il numero di bug è molto più basso o che questo è stato il primo progetto che l'azienda ha effettivamente consegnato in tempo dovrebbe essere abbastanza convincente.