Quali sarebbero gli argomenti validi per convincere il management di alto livello a prendere in considerazione la programmazione funzionale? [chiuso]

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 parallellizzati. Ma la programmazione parallela è molto più difficile della programmazione sequenziale, a causa di molte nuove sfide che comporta (consulta l'articolo Wiki per una panoramica completa ).

La programmazione funzionale aiuta a sbarazzarsi di alcune di queste sfide, ad es. le condizioni di gara non si applicano se si usano 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 niente intuitiva.

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

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

Ti stai avvicinando dal lato sbagliato. Nella maggior parte delle aziende, la gestione non è responsabile della "scelta del paradigma di programmazione", è (o almeno dovrebbe essere) responsabile del funzionamento efficiente 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 i costrutti funzionali nei tuoi linguaggi di programmazione stabiliti, e tutti sono soddisfatti, non dovresti nemmeno chiedere un permesso (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 della tua squadra ha un'opinione diversa sulla FP, e iniziano a lamentarsi del tuo codice funzionale che gli altri membri del team non capiscono, potresti avere problemi con la gestione - per una buona ragione, dal momento che in tal caso, la squadra perde efficienza.

Quindi l'essenza è: convincere gli altri membri della squadra, o i vostri dirigenti di squadra, ma non la gestione di alto livello!

EDIT: a causa del tuo commento - in realtà, questo è una risposta alla tua domanda ;-). L'unica argomentazione di cui sto parlando è "l'intera squadra 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 è molto pratico Cercare di utilizzare argomenti tecnici a persone non tecniche direttamente funziona raramente, non perché sono "troppo stupidi per comprendere 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 basarsi sull'opinione di un solo esperto.

Per capire perché la programmazione funzionale non ha conquistato il mondo, devi capire il pensiero aziendale dietro la programmazione delle decisioni linguistiche. Per scegliere su Java per un momento:

1. Sono disponibili eserciti di programmatori in grado di scrivere risme di codice Java ordinario. Questo non è vero per i programmatori Lisp o Haskell (o anche per Scala).
2. Tutti gli altri usano Java, quindi deve essere buono. Correlato: i manager non devono giustificare la scelta di Java rispetto ad un linguaggio oscuro che nessuno nella struttura dei comandi ha mai sentito nominare.

Se la tua organizzazione è già trincerata nel Regno di nomi , fare un cambio all'ingrosso di Programmazione Funzionale non accadrà. 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 tua migliore scommessa è

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

Gli argomenti di Paul Graham si applicano solo alle startup e ci sono stati una serie di racconti di ammonimento sulle aziende che hanno iniziato utilizzando linguaggi puramente funzionali, ma poi sono stati acquistati da un'altra società il cui primo ordine era quello di convertire immediatamente la base del codice funzionale in un linguaggio OO in modo che i loro sviluppatori software esistenti potessero capirlo.

Nella mia (un po 'cinica) esperienza, avendo lavorato per un negozio dove usavamo la programmazione funzionale, e intervistato in molti altri:

1. C'era sempre un CTO e altri tecnici di alto livello che avevano esperienza con la programmazione funzionale e riuscivano a convincere i dirigenti non tecnici di esso. (E, per inciso, queste persone sono più qualificate per rispondere alla tua domanda di quanto lo sia io.)
2. Una volta che queste persone lasciano l'azienda e vengono sostituite da persone che non hanno questa inclinazione, le cose andranno a sud. I nuovi ragazzi daranno la colpa a tutto ciò che va storto (inclusi, e in particolare i loro fallimenti) sullo strano linguaggio di programmazione e sul paradigma usato per costruire ciò che è venuto prima. Essi marginalizzeranno le persone rimanenti con abilità di programmazione funzionale, spingendole fuori dalla compagnia. Il sistema costruito sul linguaggio funzionale si deteriora non mantenuto. Questo genere di cose, nella mia mente, è il rischio più grande che un'impresa assuma se adotta un linguaggio funzionale e non deve essere sottovalutato.
3. L'organizzazione deve avere una cultura "costruisci invece di comprare" affinché funzioni. Perché l'adozione di un linguaggio funzionale comporterà meno opzioni di "acquisto".
4. C'era quasi sempre qualche compromesso ai detrattori tecnici e non tecnici dell'idea. Il più comune di questi compromessi è che qualsiasi linguaggio non JVM era appena preso in considerazione; Clojure e Scala sono stati proposti, Haskell e O'Caml erano appena usciti di testa.

Cose da considerare per il management superiore quando / se la gestione superiore è coinvolta nella selezione dei linguaggi di programmazione (il che è strano, dovrebbero lasciarlo a persone fidate e competenti (sia esperti di tecnologia che di business):

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

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

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

Contro la comune credenza e l'autovalutazione tipica, molte decisioni sono prese sulla base del sentimento istintivo. E spesso queste decisioni sono decisioni molto buone, perché incorporano a livello subconscio molta esperienza individuale nel prendere la decisione.

Se vuoi sfidare una decisione del genere come "Ci atteniamo al linguaggio C fino alla fine di tutti i computer" devi fare molto di più che fornire alcuni argomenti.

Il primo passo è probabilmente quello di scoprire le persone e le ragioni alla base della decisione che l'alta direzione dovrebbe avere un modo di dire in tali decisioni tecniche. Ovviamente posso solo indovinare qui, ma molto probabilmente hanno una serie di decisioni prese da personale tecnico andato a male. Ammettiamolo: la maggior parte degli sviluppatori non è molto brava nel prendere decisioni (anche tecniche) a livello aziendale.

Una volta che hai trovato queste persone parlare 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 sono sfidati. Da qui potresti spostarti per coinvolgere le persone della tecnologia in questo tipo di decisione. Spesso la direzione non vuole prendere queste decisioni, ma non si fida degli altri. Quindi, se la tua squadra inizia a prendere parte alla decisione architettonica e dimostra che le decisioni che proponi sono solide, la gestione potrebbe essere disposta a fidarsi di te / del tuo team.

Importante per arrivare a decisioni architettoniche del suono è:

• Raccogli input dai portatori di interesse (Gestione, Utenti, Amministratori, Vendite, Clienti ...)
• Decisioni di base su quell'input
• Comunicare chiaramente: quali sono le (proposte) decisioni; Che rischio mirano a mitigare; Quali interessi in conflitto sono e con un certo ritardo: quanto bene hanno funzionato.

Se lavori per una grande azienda con dipendenti di 10K +, preparati a imparare alcune delle seguenti lezioni.

• la velocità di codifica non è davvero rilevante per la riga di fondo.
• cose come la manutenibilità sulla scala dei decenni è
• i problemi che pensi di poter risolvere usando i 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 il livello di fiducia che le tue argomentazioni sono state ascoltate e considerate, avrai anche stabilito un modo per raccogliere e considerare i requisiti che tu, il tuo team e il management confidano.

Se questo processo produce la raccomandazione di utilizzare un approccio funzionale in alcune aree che hai finito.

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 tu fai altrettanto.

Le cattive notizie sono: a seconda delle dimensioni e dello stile dell'azienda, questo potrebbe facilmente richiedere un paio di anni o decenni.

La buona notizia è: imparerai molto sulla strada.

Dato che il primo passo è iniziare a parlare e soprattutto ascoltare l'alta dirigenza, ti consiglio di iniziare leggendo Just Listen .

Un buon approccio sarebbe mostrare che ha mostrato buoni risultati nel settore e adottato.

Puoi ottenere alcuni dati da:

• link

• link

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

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

Stai arrivando da questa direzione sbagliata.

Stai cercando di convincere la gestione di un passaggio a un paradigma funzionale per il tuo divertimento e stai cercando di raggirare argomenti per supportare ciò che non ha nulla a che fare con il vero motivo per cui lo vuoi. Altrimenti non avresti bisogno di fare la domanda, perché saresti in grado di elencare i tuoi argomenti dalla cima della tua testa.

Piuttosto, ciò che dovresti pensare è ciò di cui l'attuale azienda ha bisogno e in che modo è meglio servirlo. Se così accade, è meglio che serva usando un paradigma funzionale - yay! - Puoi giocare. Ma se fai un'analisi corretta, tenendo conto delle esigenze operative dell'azienda, della formazione necessaria dei collaboratori, degli sfondi 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'utilizzo di paradigmi funzionali. Questo non è il loro dominio di competenza e odora la microgestione. Perché non delegano tali decisioni a persone che in realtà hanno richiesto competenze?

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

Primo caso

Se parli con persone che sanno programmare , confrontare il codice scritto senza paradigmi di programmazione funzionale e lo stesso codice scritto in stile funzionale può essere abbastanza convincente:

Esempio di codice C # che utilizza lo 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 con la programmazione funzionale in 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))
    );

Quindi chiedi loro:

1. Quanti errori può fare un programmatore nel primo campione? E il secondo?

2. Quanto è difficile individuare gli 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 ci sono molte cose tecniche che puoi dire loro. Uno dei modi per essere convincenti è mostrare l'effettivo impatto dei paradigmi funzionali sul tuo lavoro e sul lavoro dei tuoi colleghi.

Ad esempio, confronta due progetti realizzati dalla stessa squadra, uno con FP, altri non utilizzandolo. Dimostrando che il numero di bug è molto più basso o che questo è stato il primo progetto che la società ha effettivamente consegnato in tempo dovrebbe essere abbastanza convincente.