Le insidie del mondo reale dell'introduzione di F # in un grande gruppo di codici e team di ingegneri [chiuso]

La ricerca riprende per altri linguaggi funzionali come Scheme, Lisp o Haskell. Un sacco di gente li impara a scuola e li ha sul proprio curriculum; Sono sicuro che a molti di loro non dispiacerebbe imparare F #. Ho Scheme nel mio curriculum anche se non l'ho mai usato dopo la scuola e un lavoro che coinvolge F # probabilmente attirerà anche la mia attenzione.

Any other pitfalls I'm not considering?

In pratica, l'errore principale che vedo le persone è cercare di forzare l'uso di F # per problemi in cui è lo strumento sbagliato per il lavoro.

Or anyone care to rebut the pitfalls I've mentioned?

Sono tutte preoccupazioni ovviamente valide fino ad un certo punto, ma mi chiedo fino a che punto.

Ad esempio, dici che tutti dovrebbero imparare F # per lavorare sul codice F #. Sebbene sia vero, questo non è un grosso problema nella pratica. L'apprendimento di F # non è più significativo dell'apprendimento di WPF, Silverlight o TPL. Sto insegnando a circa 30 sviluppatori come utilizzare F # per un cliente a Londra in questo momento e circa una dozzina di persone lavoravano a tempo pieno sul codice F # dopo solo poche settimane e hanno appena spedito il loro primo prodotto (in tempo e in budget! ) scritto quasi interamente in F # dopo solo pochi mesi. In effetti, hanno avuto più difficoltà tecniche con Silverlight rispetto a F # e hanno trovato che il supporto tecnico per Silverlight è molto peggio che per F #.

Si fa riferimento al pool relativamente piccolo di programmatori F # disponibili ma, ancora una volta, considerato quanto sia facile raccogliere F #, non penso che questo sia un problema significativo. Dubito che dovrai assumerne molti, se ce ne sono. Il mio cliente ha due membri di F # per oltre 100 programmatori e il nostro compito è quello di seminare e supervisionare l'uso di F #.

La terza e ultima preoccupazione riguarda meno il supporto della community, Googling per le soluzioni C # rispetto a F # e il supporto di strumenti di terze parti. Ancora una volta, non ho trovato questi in pratica problematici. Ho inviato un messaggio di posta elettronica a fsbugs con un commento sulle unità di misura in F # e ho ricevuto una risposta entro 24 ore dal ricercatore che l'ha inventato con una spiegazione dettagliata del perché la mia interpretazione era sbagliata e perché funziona così. Non l'ho mai ricevuto da Anders Hejlsberg ;-). Io continuo a cercare soluzioni per Google e le trovo scritte in C #, VB o persino in IronPython ma, in 3 anni di utilizzo del settore F #, posso richiamare solo una singola istanza in cui tradurre la soluzione in F # non è stato banale. In effetti, di recente ho convertito il campione di serializzazione dati C # da MSDN a F # ed era 5 × più corto. Infine, hai menzionato il supporto di F # in strumenti come NUnit quando usiamo NUnit da F # senza problemi per un po 'di tempo. Questi sono strumenti .NET, non strumenti C #.

Case study : il mio attuale cliente non sta solo utilizzando NUnit per il test delle unità, ma ha costruito TickSpec in F # in alto di NUnit come alternativa tecnicamente superiore a SpecFlow per BDD. L'autore si è impegnato a mostrarmi che TickSpec è una piccola frazione delle dimensioni di SpecFlow e offre più funzionalità. Inoltre, molti degli sviluppatori che lavorano senza esperienza F # precedente (e, credo, nessuna precedente esperienza di programmazione funzionale) lo hanno raccolto e hanno iniziato a usarlo in progetti non correlati senza problemi proprio perché F # + TickSpec rende più facile la loro risoluzione problemi.

FWIW, ho dato al mio cliente un abbonamento gratuito al nostro giornale F # .NET che è andato giù bene con molti degli sviluppatori che apprendono F #.

HTH!

Come riconosci dal tuo primo punto, i tuoi programmatori che non conoscono F # non possono lavorare sulla parte F # della tua base di codice. Tuttavia, non è necessario riscrivere l'intera base di codice in F # per ottenere vantaggi dal suo utilizzo: è sufficiente riscrivere le parti in cui si vedrebbe il più grande vantaggio. Il fatto che F # funzioni davvero bene con C # dovrebbe rendere relativamente facile ritagliare alcune parti e creare assemblati F #.

Se avessi i tuoi ingegneri che lavorano su una tradizionale applicazione a 3 livelli, probabilmente non insisteresti che tutti avessero bisogno di avere una profonda conoscenza di SQL, HTML, Javascript, CSS, ecc. Invece, avresti naturalmente alcuni specialisti lavorano su diverse parti dell'applicazione. Pertanto, non penso che aggiungere una nuova lingua per una parte della tua applicazione debba essere un ostacolo troppo grande. Inoltre, puoi usare gli standard di codifica e altre pratiche per cercare di assicurarti che il tuo codice F # sia leggibile anche da ingegneri senza uno sfondo F # profondo.

Le insidie nell'aggiungere F # alle lingue che usi includono le insidie dell'introduzione di una nuova tecnologia. Indipendentemente dai vantaggi, se alcuni dei tuoi team non vogliono o non sono abbastanza flessibili da apprendere, non saranno in grado di lavorare su progetti F #. Tuttavia, se permetti ai dinosauri del tuo team di impedire l'adozione di nuove tecnologie, la tua azienda è destinata a fallire.

Le uniche trappole che ho sperimentato personalmente sono:

1. Difficoltà durante il debug. Seguire il flusso di esecuzione di un programma basato su espressioni in un debugger progettato per linguaggi basati su istruzioni può essere complicato.

2. Intellisenso frustrante. Il completamento automatico smette di funzionare esattamente quando ne hai bisogno. Microsoft deve lavorare per rendere il parser in background più tollerante ai guasti.

3. La sintassi sensibile all'indentazione rende difficile copiare o riformattare il codice.

4. Mancanza di refactoring.

5. Alcune delle convenienti estensioni VS esistenti per F # (code folding, depth color) sono un po 'lente, rendendo l'esperienza di digitazione un po' frustrante.

Secondo me, nessuno di questi problemi è un ostacolo per gli spettacoli, e per il momento posso vivere con loro. Gli strumenti sono più facili da migliorare e risolvere rispetto alle lingue.

Le tue paure che assumere nuovi programmatori in grado di scrivere in F # sarebbero difficili sono abbastanza comuni, ma a mio parere ingiustificate. Se dovessi scrivere le linee guida di codifica, ti sconsigliare o proibire una delle seguenti funzionalità in C #: yield return , LINQ agli oggetti, lambdas, il prossimo async ?

Se ritieni che queste funzioni ti aiutino a scrivere codice migliore, non c'è motivo di astenersi da F #. Il linguaggio supporta queste funzionalità in modo semplice e ben congegnato, cosa che C # non può davvero fare a causa della sua eredità.

Se la tua squadra è abbastanza intelligente da comprendere i concetti alla base delle funzionalità che ho citato, hanno tutto ciò di cui hanno bisogno per essere eccellenti programmatori in F #. Lo stesso vale per le future reclute: assumeresti qualcuno che non è in grado o non vuole utilizzare le funzionalità introdotte dopo C # 1.0?

Ho preso in considerazione questa situazione esatta.

Questo è ciò che ho in programma per il mio team:

• Combina C # con F #, questo può essere fatto usando C # per la maggior parte della base di codice. Nei casi in cui è richiesta una elaborazione dei dati intensa, scrivi le funzioni associate in F # e inseriscile in una DLL, o facendola riferimento. Esempio qui

• Riduci lentamente il tuo codice base esistente nella modalità sopra.

• Non tutto il codice deve essere funzionale.

• Fai in modo che il tuo team apprenda le nozioni di base di Haskell, LISP sui fine settimana .

• Fagli imparare F #, provando a risolvere i rompicapi Euler Project (che mi hanno aiutato molto quando stavo imparando F #) . Ancora una volta dovrebbe essere qualcosa da dire durante il fine settimana, o durante il tempo di lavoro se si desidera impostare una giornata da parte per "allenamento".

1) L'apprendimento di un linguaggio funzionale aumenterà l'abilità generale di qualcuno come programmatore, tuttavia questo si applica solo a coloro che vogliono imparare e migliorare. Non tutti i programmatori vogliono migliorare o vogliono cambiare nel loro ambiente di lavoro (conosci il tuo team.)

2) Non posso discutere con questo. Dovrai pagare la curva di apprendimento di 6 mesi di qualsiasi nuova lingua, tuttavia già sapendo che le librerie .net eliminano gli anni aggiuntivi necessari per imparare nuove librerie.

3) Il supporto per la community, sebbene più piccolo di C #, ha alcuni sviluppatori F # attivi altamente qualificati che pubblicano sul web. Non dimenticare che la maggior parte del supporto linguistico è il supporto per le librerie e offre un ottimo supporto per .NET.

Il gorilla da mille sterline qui è la gestione del rischio. "Posso essere all'avanguardia ma non all'avanguardia". Direi che F # non è all'avanguardia. È stato rilasciato con VS2010 ed è direttamente supportato da Microsoft. Bleeding edge è "beta" e un disclaimer di Microsoft che dice di non essere responsabile di nulla.

In pratica, il supporto IntelliSense è piuttosto carente, al punto che i guadagni in termini di produttività dell'inferenza di tipo sono superati dal completamento automatico meno sofisticato disponibile in C #.

Anche i messaggi di errore causati da inferenze di tipo errate richiedono tempi più lunghi per i principianti (e spesso per utenti intermedi come me), semplicemente perché sei meno incline a fornire annotazioni sul tipo di una lingua come C #.

Anche OOP manca in modi sorprendenti in F #; per esempio, non c'è supporto per tipi / classi annidati. Devi stare attento quando porti il codice, perché ci sono alcune cose che puoi fare in C # che non puoi fare in F #, purtroppo.

Ultimo ma non meno importante, sia la dimensione che la qualità della comunità F # è deludente. Molte delle informazioni di F # sul Web sono o per versioni precedenti o semplicemente non molto buone - o poco idiomatiche, prestazioni scadenti o inesatte. Poi ci sono persone che fanno pagare enormi quantità di denaro per le newsletter che sono in gran parte solo informazioni digerenti.

Io stesso uso C # per i progetti di lavoro e F # per le mie cose. Per quanto ami F #, sfortunatamente, è un po 'difficile prevedere come / quando le cose potrebbero andare in pezzi.

Il problema principale è sempre la manutenibilità.

Mi piacerebbe scrivere codice in Scheme, ma il prossimo manutentore vorrebbe probabilmente darmi la caccia e torturarmi.

Direi che la prima cosa che devi fare è chiedere ai membri del tuo team come si sentono nell'introdurre F #. Se a loro piace l'idea, tutto andrà molto più liscio se non lo fanno.