Insidie ​​del mondo reale per l'introduzione di F # in una grande base di codice e in un team di ingegneri [chiuso]

Sono CTO di una società di software con una base di codice esistente di grandi dimensioni (tutto C #) e un considerevole team di ingegneri. Vedo come alcune parti del codice sarebbero molto più facili da scrivere in F #, con conseguenti tempi di sviluppo più rapidi, meno bug, implementazioni parallele più semplici, ecc., Sostanzialmente aumenti di produttività complessivi per il mio team. Tuttavia, posso anche vedere diverse insidie ​​sulla produttività dell'introduzione di F #, vale a dire:

1) Tutti devono imparare F #, e non è banale come passare da, diciamo, Java a C #. I membri del team che non hanno appreso F # non saranno in grado di lavorare su parti F # della base di codice.

2) Il pool di programmatori F # noleggiabili, al momento (dicembre 2010) è inesistente. Cerca nei vari database di curriculum di ingegneri del software "F #", in modo che meno dell'1% dei curriculum contenga la parola chiave.

3) Il sostegno comunitario a partire da oggi (dicembre 2010) è meno disponibile. Puoi cercare su Google qualsiasi problema in C # e trovare qualcuno che ha già risolto il problema, non così con F #. Anche il supporto di strumenti di terze parti (NUnit, Resharper ecc.) È impreciso.

Mi rendo conto che questo è un po 'Catch-22, cioè se le persone come me non usano F #, la community e gli strumenti non si materializzeranno mai, ecc. Ma ho un'azienda da gestire e posso essere all'avanguardia ma bordo non sanguinante.

Altre insidie ​​che non sto prendendo in considerazione? O qualcuno si preoccupa di confutare le insidie ​​che ho citato? Penso che questa sia una discussione importante e mi piacerebbe sentire le tue contro-argomentazioni in questo forum pubblico che potrebbero fare molto per aumentare l'adozione di F # da parte dell'industria.

La ricerca riprende per altri linguaggi funzionali come Scheme, Lisp o Haskell. Molte persone imparano questi a scuola e li hanno ripresi; Sono sicuro che molti di loro non dispiaceranno imparare F #. Ho Scheme nel mio curriculum, anche se non l'ho mai usato dopo la scuola e un lavoro che coinvolge F # probabilmente attirerebbe anche la mia attenzione.

Altre insidie ​​che non sto prendendo in considerazione?

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

O qualcuno si preoccupa di confutare le insidie ​​che ho citato?

Sono ovviamente tutte preoccupazioni valide in una certa misura, ma mi chiedo in che misura.

Ad esempio, dici che tutti dovrebbero imparare F # per poter lavorare sul codice F #. Sebbene sia vero, questo non è un grosso problema in 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 stavano lavorando a tempo pieno sul codice F # dopo solo poche settimane e hanno appena spedito il loro primo prodotto (puntuale e in-budget! ) scritto quasi interamente in F # solo dopo pochi mesi. In realtà, hanno avuto più difficoltà tecniche con Silverlight rispetto a F # e hanno trovato il supporto tecnico per Silverlight molto peggiore rispetto a F #.

Ti riferisci al gruppo relativamente piccolo di programmatori F # disponibili ma, ancora una volta, vista la facilità con cui raccogli F #, non penso che questo sia un problema significativo. Dubito che dovrai assumerne molti, se ce ne sono. Il mio cliente ha due ragazzi F # per oltre 100 programmatori e il nostro compito è seminare e supervisionare l'uso di F #.

La tua terza e ultima preoccupazione riguarda meno supporto della community, ricerca su google per soluzioni C # vs F # e supporto per strumenti di terze parti. Ancora una volta, non ho trovato questi problemi nella pratica. Ho inviato un'e-mail a fsbugs con un commento sulle unità di misura in F # e ho ricevuto una risposta entro 24 ore dal ricercatore che lo ha inventato con una spiegazione dettagliata del perché la mia interpretazione era sbagliata e perché funziona nel modo in cui funziona. Non l'ho mai ricevuto da Anders Hejlsberg ;-). Io cerco continuamente soluzioni per Google e le trovo scritte in C #, VB o persino IronPython ma, in 3 anni di utilizzo del settore F #, riesco a ricordare solo una singola istanza in cui tradurre la soluzione in F # non era banale. Di fatto, di recente ho convertito il campione C # di serializzatore di dati da MSDN a F # ed era 5 volte più corto. Infine, hai menzionato il supporto di F # in strumenti come NUnit quando sto usando NUnit da F # senza problemi per qualche tempo. Questi sono strumenti .NET, non strumenti C #.

Caso di studio : il mio attuale cliente non sta solo usando NUnit per test unitari, ma ha costruito TickSpec in F # sopra NUnit come alternativa tecnicamente superiore a SpecFlow per BDD. L'autore ha sottolineato che TickSpec è una piccola frazione delle dimensioni di SpecFlow e offre più funzionalità. Inoltre, molti sviluppatori al lavoro senza esperienza F # precedente (e, credo, nessuna esperienza di programmazione funzionale precedente) l'hanno raccolto e hanno iniziato a usarlo in progetti non correlati senza problemi proprio perché F # + TickSpec rende più facile risolvere il loro i problemi.

FWIW, ho dato al mio cliente un abbonamento gratuito al nostro F # .NET Journal che è andato bene con molti sviluppatori che imparano F #.

HTH!

Come riconosci nel 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 dall'usarlo: basta riscrivere le parti in cui si otterrebbe il massimo beneficio. Il fatto che F # interagisca davvero bene con C # dovrebbe rendere relativamente facile scolpire alcune parti e creare da esse assemblaggi F #.

Se i tuoi ingegneri lavorassero su una tradizionale applicazione a 3 livelli, probabilmente non insisteresti sul fatto che tutti avevano bisogno di una profonda conoscenza di SQL, HTML, Javascript, CSS, ecc. Invece, avresti naturalmente alcuni specialisti che lavorano su diverse parti dell'applicazione. Pertanto, non penso che l'aggiunta di una nuova lingua per una parte dell'applicazione dovrebbe essere un grosso ostacolo. Inoltre, puoi utilizzare gli standard di codifica e altre pratiche per cercare di assicurarti che il tuo codice F # sia leggibile anche dagli ingegneri senza un profondo background F #.

Le insidie ​​dell'aggiunta di F # alle lingue che usi includono le insidie ​​dell'introduzione di qualsiasi nuova tecnologia. Indipendentemente dai vantaggi, se alcuni membri del tuo team non vogliono o non sono abbastanza flessibili da imparare, non saranno in grado di lavorare su progetti F #. Tuttavia, se lasci che i dinosauri nella tua squadra impediscano l'adozione di nuove tecnologie, la tua azienda è condannata.

Le uniche insidie ​​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. Intellisense frustrante. Il completamento automatico smette di funzionare esattamente quando ne hai bisogno. Microsoft deve lavorare per rendere il parser di sfondo più tollerante agli errori.

3. La sintassi sensibile al rientro rende difficile copiare e riformattare il codice.

4. Mancanza di refactoring.

5. Alcune delle pratiche estensioni VS esistenti per F # (piegatura del codice, colorazione della profondità) sono un po 'lente, rendendo l'esperienza di digitazione un po' frustrante.

Secondo me, nessuno di questi problemi è uno spettacolo, e per il momento posso convivere con loro. Gli strumenti sono più facili da migliorare e correggere rispetto alle lingue.

Le tue paure che assumere nuovi programmatori in grado di scrivere in F # sarebbero difficili sono abbastanza comuni ma a mio avviso ingiustificate. Se dovessi scrivere linee guida per la codifica, consiglieresti o proibiresti una delle seguenti funzionalità in C # yield return:, LINQ to objects, lambdas, the coming async?

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

Se il tuo team è abbastanza intelligente da comprendere i concetti alla base delle funzionalità che ho citato, hanno tutto ciò di cui hanno bisogno per essere programmatori eccellenti in F #. Lo stesso vale per le future assunzioni: assumeresti qualcuno che è incapace o non disposto a utilizzare le funzionalità introdotte dopo C # 1.0?

Ho contemplato questa situazione esatta.

Questo è quello che pianifico per il mio team:

• Mescola C # con F #, questo può essere fatto usando C # per la maggior parte della base di codice. Laddove è richiesta un'elaborazione pesante dei dati , scrivere le funzioni associate in F # e inserirlo in una dll o fare riferimento a esso. Esempio qui

• Ricodificare lentamente la base di codice esistente nel modo sopra indicato.

• Non tutto il codice deve essere funzionale.

• Chiedi al tuo team di apprendere le basi di Haskell, LISP durante i fine settimana .

• Fai in modo che imparino F #, provando a risolvere i puzzle del Progetto Euler (che mi hanno aiutato molto quando stavo imparando F #). Ancora una volta, questo dovrebbe essere qualcosa da dire durante il fine settimana o durante l'orario di lavoro se si desidera riservare un giorno per "allenamento".

1) L'apprendimento di una lingua funzionale aumenterà l'abilità generale di qualcuno come programmatore, ma ciò vale solo per coloro che vogliono imparare e migliorare. Non tutti i programmatori vogliono migliorare, né vogliono cambiare il proprio ambiente di lavoro (conoscere il proprio team).

2) Non posso discutere con questo. Dovrai pagare per la curva di apprendimento di 6 mesi di qualsiasi nuova lingua, ma già conoscendo le librerie .net elimina gli anni in più necessari per apprendere nuove biblioteche.

3) Il supporto della community, sebbene inferiore a C #, ha alcuni sviluppatori di F # attivi altamente qualificati che pubblicano sul Web. Non dimenticare che la maggior parte del supporto linguistico è il supporto delle librerie e esiste un ottimo supporto per .NET.

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

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

I messaggi di errore causati da inferenze di tipo errate richiedono anche più tempo per la correzione per i principianti (e spesso per gli utenti intermedi come me), semplicemente perché sei meno propenso a fornire annotazioni di tipo rispetto a un linguaggio come C #.

OOP manca anche in modi sorprendenti in F #; ad esempio, non esiste supporto per tipi / classi nidificati. Devi fare attenzione quando esegui il porting del codice, perché ci sono alcune cose che puoi fare in C # che non puoi fare in F #, purtroppo.

Ultimo ma non meno importante, sia le dimensioni che la qualità della comunità F # sono deludenti. Molte delle informazioni F # disponibili sul Web sono o per versioni precedenti o semplicemente non molto buone: non idiomatiche, scarse prestazioni o completamente errate. Poi ci sono persone che fanno pagare enormi somme per le newsletter che sono in gran parte solo dei digest di informazioni esistenti.

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

Il problema principale è sempre la manutenibilità.

Mi piacerebbe programmare in Scheme, ma il prossimo manutentore vorrebbe probabilmente cacciarmi 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.