F#, Perché usarlo?

F#(Fsharp) è il linguaggio funzionale introdotto da Microsoft per la prima volta nella suite di
Visual Studio 2010. Sebbene ogni anno abbia sempre aumentato il suo share di utilizzo,
grazie anche a numerose community di supporto, di certo attualmente non gode della stessa
popolarità degli altri linguaggi del mondo .Net.

Nella seconda parte del titolo ho racchiuso il cuore di questo articolo in due parole: “Perché
usarlo?”. L’intento è proprio quello di provare a rendere una risposta che sia la più
obbiettiva possibile.
Se analizzassi il problema esclusivamente da un punto di vista conoscitivo, probabilmente
sbaglierei in partenza. Infatti la logica suggerisce di usare un approccio diverso, più deduttivo
per analizzare aspetti astratti.
Nel nostro caso infatti dobbiamo discernere perché usare o meno una tecnologia, un
linguaggio piuttosto che… nulla.
Nulla è proprio la prima considerazione: non si sta parlando di scegliere C# o VB.Net o
qualsiasi altro linguaggio piuttosto che F#. Si sta solo rispondendo alla domanda se usare o
meno questo linguaggio.
Tutti i giorni facciamo la stessa cosa: non diciamo “uso solo html o JavaScript” oppure
“questo sito web lo faccio solo con .Net senza sviluppo lato client o viceversa”.
Il primo step è proprio quello di capire che F#, come linguaggio, in quanto tale, può essere
usato benissimo insieme ad altri e non ad esclusione.
Il Framework .NET garantisce la piena interazione dei linguaggi basati su di esso, e quindi
anche di Visual F#, implementazione del linguaggio F# da parte di Microsoft.

Ad ogni modo, ragionando in termini deduttivi, ho cercato di dare una risposta a ciò.

Multi-paradigma
Fin dalla nascita e dall’evoluzione dei linguaggi a paradigma funzionale, si è capito subito
che il loro utilizzo è ricollocabile in specifici ambiti e contesti. Pensare di costruire un intero
software in solo funzionale sarebbe un’impresa ardua con costi di sviluppo molto alti e di
conseguenza rilegabile appunto a determinati contesti.
F#, invece è ibrido, multi-paradigma, pensato appunto per coesistere con .Net e quindi,
laddove servisse, uscire dal contesto funzionale per entrare in quello imperativo e\o a oggetti.
Questo è davvero un interessante aspetto. Infatti si può scegliere di uscire dal contesto
funzionale rimanendo in F# oppure cambiare completamente e scrivere in C# o VB.Net.
Un bellissimo esempio per poter dimostrare come è possibile trascrivere un comportamento
(in questo caso una funzione matematica) con diversi paradigmi è la sequenza di Fibonacci.

Prendendo spunto da vari esempi online, ho raccolto implementazioni diverse:

In C#:
private int Fibonacci(int x)
{
if (x <= 1)
return 1;
else
return Fibonacci(x - 1) + Fibonacci(x - 2);
}

In C# (utilizzando una sintassi funzionale):

private int FunctionalFibonacci(int x)
{
Func<int, int> fib = null;
fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;
return fib(x);
}

In F# (utilizzando pattern matching):

let rec Fibonacci x =
match x with
| x when x <= 1 -> 1
| _ -> Fibonacci(x - 1) + Fibonacci(x - 2)

In questi 3 esempi abbiamo visto diversi modi di scrivere il codice della sequenza di
Fibonacci utilizzando paradigmi e linguaggi diversi.
Inoltre, come già sappiamo, è sempre possibile creare una Solution in Visual Studio con
progetti in entrambi i linguaggi (anche F#) e referenziarli tra loro allo stesso modo di sempre.
In un’unica parola: interoperabilità tra progetti, ma con la possibilità di creare librerie
puramente funzionali da integrare nella nostra applicazione (anche per F# avviene la
compilazione in IL).
Immaginate quindi la possibilità di poter creare un progetto WPF, naturalmente in C# o
VB.net e aggiungerli un riferimento ad una libreria di classi in F# che fornisca ad
esempio un set di funzioni complesse in ambito matematico, piuttosto che biotecnologico o
semplicemente statistico, e così via.
Posso supporre a questo punto che non si stia più parlando solo di tecnologia, ma anche di
tecnica perché diversi paradigmi spesso significano diverse architetture e di conseguenza
stiamo parlando della possibilità di aumentare il numero di scelte tecnologiche e
architetturali.
Infatti, non a caso, molti dei punti di forza della programmazione funzionale (tecniche o
tecnologie) sono stati introdotti o migliorati nei classici linguaggi .Net. Per citarne alcuni:
Asincronia, Linq, Lambda Expression, Implicit Type, ecc… Quindi stiamo comunque
utilizzando programmazione funzionale.
Non solo, recentemente con la versione 6 del C# sono state aggiunte diversi costrutti sintattici
che permettono attraverso le lambda expression una scrittura più concisa e di natura
funzionale.
//Auto-ReadOnly Properties
public string FullNameReadOnlySemplificated => this.FirstName + this.LastName;

//Expression Method
public string FullNameMethod(string name, string secondName) => name + secondName;

public static Features operator +(Features a, Features b) => new Features(a.Name +

b.Name);

public void Print() => Console.WriteLine(this.Name);

public string this[string a] =>

typeof(Features).GetProperty(a).GetValue(this).ToString();

Nella “possibile futura versione di C#” sembrano essere previste nuove aggiunte prese
direttamente dal F#. Ad esempio il potenziamento del Switch Case come Pattern Matching,
nuove funzionalità per l’uso delle tuple e i Record Type.
Naturalmente è utile far presente che per il momento queste sono tutte ipotesi di
implementazione e si possono trovare dei riferimenti a questi link.
https://msdn.microsoft.com/en-us/magazine/mt595758.aspx
https://github.com/dotnet/roslyn/issues/2136
Seguendo il percorso intrapreso in questo articolo, i prossimi passi potrebbero essere: capire
perché, se molte di queste tecnologie vengono portate nel mondo .Net, allora avrebbe senso
usare F# e come effettivamente rende migliore (tecnologicamente parlando) sviluppare con
questo linguaggio.
In realtà questo però ricadrebbe ancora nel parlare di F# dal punto conoscitivo invece di tener
un profilo più alto e continuare ad analizzare dall’esterno piuttosto che dall’interno.
Cerchiamo quindi di fare entrambe le cose.

F# scope
Leggendo un qualsiasi articolo che parla di programmazione funzionale ci sono delle
caratteristiche comuni che sono ricorrenti anche in F#.
Queste caratteristiche sono proprie del paradigma e non si sposano facilmente con gli altri.
Quindi possiamo di nuovo supporre che sebbene sia possibile avere linguaggi ibridi, ovvero
multi-paradigma, è anche vero che vi sono caratteristiche degli eventuali paradigmi che non
possono essere implementate facilmente rispetto al paradigma predominante del linguaggio.
Potrebbe essere in parte una risposta alla domanda che ci siamo posti prima. Per sfruttare
appieno il paradigma funzionale dovrei comunque scegliere F# e viceversa.
Mi viene molto difficile pensare alla programmazione ad oggetti senza usare “null
value” e allo stesso modo come potrei usare F# in funzionale con valori nulli?
Certo è che se volessi creare l’oggetto Car con tutti i suoi membri, la programmazione OOP
sarebbe molto comoda scritta magari in C# o VB.Net con l’IDE Visual Studio e tutte le sue
commodity.
Invece se volessi scrivere una funzione f(x) che mi restituisse un valore y (y = f(x)) e allo
stesso modo vorrei sapere che per lo stesso input avrò sempre lo stesso output e magari
testare ciò senza dover ricompilare tutta l’applicazione, F# sarebbe proprio una bella scelta.
Infatti quando si dice che “la programmazione funzionale è in relazione con la matematica”, è
grazie all’immutabilità.
Soffermatevi per un attimo sull’incremento di una variabile, ad esempio x = x + 1.
In matematica, nei numeri reali, non vi è nessun valore di x che risolve questa equazione.
Mentre nell’informatica, in particolare nella programmazione ad oggetti è possibile farlo.
Contrariamente, in F# essendo di default tutto immutabile non si può modificare nessun
valore, a meno che non si dichiarare esplicitamente con la keyword mutable, uscendo dal
contesto funzionale.
Pertanto, se torniamo all’esempio precedente è facile capire che l’affermazione “per lo stesso
input avrò sempre lo stesso output” è vera. Infatti nessuna azione dall’esterno o dall’interno
(cambi di stato, incrementi, decrementi, ...) potranno influenzare il risultato della funzione
stessa.
A questo punto ecco spiegato perché è possibile testare singolarmente ogni funzione che
abbiamo generato. Inoltre, grazie a Visual Studio, è possibile farlo attraverso un tool, F#
Interactive, che ultimamente è stato implementato anche per C#(Rosilyn).
Per concludere è bene ricordare che ci sono alcune caratteristiche proprie dei paradigmi che
per ragioni di implementazione molto complesse, ad oggi sono esclusive di F#.
Una di queste sono i Type Provider.

F# Type Provider
I type provider rendono bene allo scopo di ciò che abbiamo appena parlato nei paragrafi
precedenti. Essi non sono né solamente una tecnica, né solamente una tecnologia. Infatti sono
entrambe le cose: aggiungendo a tutto questo anche una buona dose di dinamismo e di
comportamenti.
Sempre da un punto di vista analitico, interazione e multi-paradigma ci danno modo di
riflettere su un concetto altrettanto fondamentale:

Un solo linguaggio e di conseguenza le sue caratteristiche e scope non sono sufficienti per
coprire qualsiasi contesto. L’interazione tra diversi tipi di progetto e la possibilità di più
paradigmi possono quindi essere una prima risposta ad aumentare il “range di contesto”.

Infatti se questa affermazione fosse falsa non ci sarebbe tutto questo immenso mondo di
tecnologie e strumenti per costruirne.
È bene anche ribadire che per contesto si intende anche una serie di necessità che
comprendono anche aspetti di più alto concetto, come la diffusione del linguaggio stesso
piuttosto che la sua versatilità di piattaforma e hardware e non solo di tipo di applicazione
(web, server, data, app, embedded…)
Questi type provider, dalla parola stessa provider di tipi aggiungono nel linguaggio F#
un’ulteriore possibilità a tutto ciò.
Permettono di abbattere la distanza tra risorse esterne(informazioni) ed interne (codice
sorgente), attraverso la costruzione dinamico-comportamentale di membri quali oggetti, tipi,
proprietà, che agiscono in modo da poter utilizzare informazioni esterne all’interno del nostro
codice. Il tutto in chiave pseudo-dinamica attraverso set di funzioni per lo scambio continuo
tra mondo interno ed esterno e il loro utilizzo in F#.

Per semplificare attraverso vari esempi, esistono type provider per quasi tutte le tecnologie
più comuni. Uno fra tutti quello che permette l’accesso a un database SQL Server.
Passandogli alla dichiarazione del type provider corretto la stringa di connessione, avremo a
disposizione un set di tipi che permettono di fare ad esempio le operazioni di CRUD del
database, inoltre, ben più importante, avremo anche a disposizione tutti i membri che
definiscono gli oggetti del database stesso: tabelle, campi, store procedure,…

Direte che questo esiste di già in altri linguaggi del .Net Framework.
In realtà non è del tutto vero. Ciò che abbiamo è diverso.
Nel .Net, abbiamo degli oggetti che sono stati creati da risorse esterne e che sono statici,
finché noi ad esempio non riaggiorniamo il modello degli oggetti. EntityFramework è forse il
caso più noto.
Oppure, abbiamo gli oggetti dinamici dove l’interpretazione del tipo avverrà a runtime
con tutti i pro e contro del caso.
In F#, attraverso i type provider avremo entrambe le cose allo stesso momento. Quindi
deduco che attraverso il paradigma funzionale e il linguaggio stesso posso modellare
dinamicamente un set di informazioni. Non attraverso un vero e proprio meta-linguaggio che
agisce dall’esterno, ma semplicemente dall’interno utilizzando l’ambiente di sviluppo e F#.
Il come tutto questo sia fattibile e quali strumenti tecnologici e sintattici esistono in F# è
sicuramente argomento di un altro articolo.
Ad ogni modo in questo link è possibile vedere una spiegazione più in dettaglio di cosa sono i
type provider.
https://channel9.msdn.com/Events/FSharp-Events/fsharpConf-2016/Types-Properties-
Software?sf22536203=1
Mentre in questaltro, vi è un elenco di tutti quelli più importanti con relativo esempio.
https://blogs.msdn.microsoft.com/dsyme/2013/01/30/twelve-f-type-providers-in-action/

F# what and how

Fino a questo momento, esclusione fatta per type provider, abbiamo capito che usare o
meno F# dipende da noi e dalla nostra predisposizione mentale e basta. Infatti non
abbiamo ancora trovato un motivo che impone di usarlo o di non usarlo.
Certo è che ignorarlo completamente o abusarne sono scelte poco interessanti in quanto non
faremmo altro che limitare le nostre possibilità.
Inoltre abbiamo visto che dire “uso solo questo perché può fare tutto” o “non lo uso perché
non mi serve a nulla” in entrambi i casi sembra più vizio che una scelta.
In realtà non è così semplice. Sempre ragionando analiticamente ci sono degli aspetti che non
possono essere ignorati.
Questi aspetti sono ad esempio il tempo per apprendere un nuovo linguaggio e la sua sintassi,
cambiare il modo di analizzare e sviluppare il problema con un approccio più funzionale; e
non per ultimo, garantire che una volta soddisfatti i due punti appena indicati, il nostro
lavoro sia obbiettivamente migliorato rispetto a quello che avremmo fatto senza usare
F#.
Quindi posso ancora una volta supporre che se volessimo usare veramente F#, come per
qualsiasi altro linguaggio, dovremmo essere coscienti del fatto che i risultati giungeranno
col tempo in relazione alla nostra predisposizione.
A tal proposito posso constatare che sebbene possa sembrare un aspetto negativo, in realtà,
ancora una volta, non è né più né meno quello che facciamo ogni giorno.
Basti pensare a quante tecnologie e tecniche abbiamo dovuto apprendere per poter accedere e
utilizzare i dati.

F# end to start
Per concludere questo articolo, il preciso scopo è di mettere in luce che scegliere di usare F#
è molto interessante.
Non solo per tutti gli aspetti tecnici o tecnologici che possono essere:
• I tipi sono immutabili, non esiste il concetto di “null value”, la concorrenza non
esiste (con paradigma funzionale) e l’approccio è intrinsecamente multi-processor
attraverso l’immutabilità come abbiamo spiegato nel paragrafo F# scope.

let x = 5 // Dichiarazione default

let mutable x = 5 // Dichiarazione per assegnare un valore diverso.

• Le variabili sono tipizzate a write-compiled time e ogni dichiarazione è una funzione

in termini matematici e quindi può essere dichiarata e testata singolarmente
(attraverso F# interactive) o anche parzialmente. (Vedi commenti)

let somma a b = a + b
let sommaParziale5 = somma 5 // Dichiarazione parziale. Manca il secondo
paramentro che potrà essere passato in un secondo momento.
let result = sommaParziale5 3 // result = 8.

• La possibilità di avere strumenti come le unità di misura che nella realtà di tutti i
giorni sono alla base della risoluzione dei problemi di qualsiasi materia scientifica.

[<Measure>]
type celsius

let temp1 = 23.9<celsius>

 • Il linguaggio è pensato tecnologicamente per essere più conciso possibile riducendo
di molto le righe di codice e a volte anche di comprensione dello stesso. (Questo è
una caratteristica che possiamo riscontrare anche nelle specifiche del C#6)

//Dichiarazione di un classe, costruttore e proprietà

type CustomerName(firstName : string, middleName, lastName) =
member __.FirstName = firstName
member __.MiddleName = middleName
member __.LastName = lastName

• I Type Provider, utilizzabili soltanto nel F#.

• Essendo di natura funzionale ci mette a disposizione ulteriori architetture e costrutti
(Pattern Matching, Tail Recursion, Active Patterns, Record Type, …) che non
possiamo facilmente utilizzare in altri paradigmi.

//Record Type
type ContactCard =
{ Name : string;
Phone : string;
Verified : bool }

let contact1 = { Name = "Alf" ;

Phone = "(206) 555-0157";
Verified = false }

//Discriminated Unions
type Employee =
| Engineer of Person
| Manager of Person * list<Employee>
| Executive of Person * list<Employee> * Employee

//Pattern Matching and tail recursion

let rec Fibonacci x =
match x with
| x when x <= 1 -> 1
| _ -> Fibonacci(x - 1) + Fibonacci(x - 2)

//Active Pattern
let (|Even|Odd|) input = if input % 2 = 0 then Even else Odd

Questi sono soltanto gli aspetti tecnici che logicamente è vero che definisco il linguaggio F#,
e quindi ci permetto di rispondere alla prima parte del titolo: “F#”, altrimenti
potremmo riferirci a questo articolo anche per altri linguaggi funzionali.
Ma perché è una scelta, un approccio diverso al problema, una possibile predisposizione, un
ulteriore modo di sviluppare software, di migliorare il nostro know-how, di offrire soluzioni
migliori.
Credo che ormai, giunti a questo punto, siamo pronti per il passo successivo, infatti siamo
coscienti di poter scegliere se continuare o meno nell’approfondire questo linguaggio.
F# Pro e Contro
In questo ultimo paragrafo, vorrei invece focalizzarmi sugli aspetti più tecnici e tecnologici
del linguaggio in questione.
È importante capire quanto sia difficile discernere tra obbiettività e soggettività quanto si
espongono le caratteristiche tecnologiche di qualsiasi cosa.
Prendendo spunto appunto da una delle caratteristiche principali della programmazione
funzionale, la sintassi concisa, ovvero la possibilità di ridurre la scrittura di una determinata
porzione di codice in poche istruzioni, è subito possibile verificare quanto questo aspetto
possa essere soggettivo.
Alcuni potrebbero vederlo come un aspetto positivo altri invece il contrario.
Aspetto positivo:
meno codice = statisticamente meno possibilità di creare errori.
Aspetto negativo:
meno codice = comprensione del codice insufficiente e di conseguenza meno adatto alle
modifiche.
Naturalmente questi sono solo esempi, ma potremmo allungare questa lista all’infinito.
Dal mio punto di vista e dalla mia esperienza cercherò di descrivere cosa ho visto di positivo
e cosa invece di negativo.

Pro
Compositional Thinking
Sicuramente il primo punto che ho inserito in questa lista di caratteristiche positive è
l’implementazione per composizione.
Quando abbiamo la necessità di lavorare su un progetto di notevoli dimensioni è praticamente
obbligatorio applicare dei modelli (Design Pattern) e “fare delle buona architettura”.
Questo avviene per una serie di motivi tecnici, tecnologi, di contesto, di sviluppo, di team,
ecc; ma in .Net e in generale nella programmazione OOP sia abituati, o meglio è facile
riapplicare diversi modelli comuni.
Al contrario, nella programmazione funzionale, molti dei design pattern che usiamo sono
semplicemente delle funzioni. Pertanto, ciò che è veramente importante è come vengono
composite(unite) tra loro. La “main key” è il fatto che ci costringono a ragionare su ciò che
realmente dobbiamo fare per ottenere ciò che è necessario.
Essendo quasi esclusivamente funzioni ed espressioni di calcolo(Monads) mentre i tipi e dati
possono essere visti secondariamente come dei descrittori di dati(immutabili), in F# non mi
devo preoccupare di descrivere come è fatto il contesto, ma piuttosto di come esso dovrà
funzionare.
Per tanto, se volessimo creare un servizio che gestisce le transazioni bancarie e il loro flusso
di esecuzione, avere la possibilità di concentrarsi esclusivamente sul funzionamento è sotto
molti aspetti la scelta adeguata.
Per fare un esempio in F#, di quanto sia intrinseco nel linguaggio il concetto di composizione
basta pensare all’operatore di composizione (>>). Alla base di questo operatore vi è la
possibilità di concatenare n funzioni senza però essere eseguite all’istante.
type Result<'TSuccess,'TFailure> =
| Success of 'TSuccess
| Failure of 'TFailure

let bind inputFunc =

function
| Success s -> inputFunc s
| Failure f -> Failure f

type Account = { UserName : string; IsLogged : bool; Email : string }

let validateAccount account =

match account with
| account when account.UserName = "" -> Failure "UserName is not valid"
| account when account.Email = "" -> Failure " Email is not empty"
| _ -> Success account

let checkLogin account =

if(account.IsLogged) then
Success account
else
Failure "User is not logged"

let LogIn account =

if(account.IsLogged) then
Failure "User has already Logged"
else
Success {account with IsLogged = true}

let LogOut account =

if(account.IsLogged) then
Success {account with IsLogged = false}
else
Failure "User has already Logged"

let ProcessNewAccount =
let checkLogin = bind checkLogin
let login = bind LogIn
validateAccount >> login >> checkLogin

let NewFakeAccount = { UserName = ""; Email = ""; IsLogged = false }

let AccountLogged = { UserName = "User"; Email = "user@user.net"; IsLogged = true
}
let NewAccount = { UserName = "User1"; Email = " user1@user.net "; IsLogged =
false }

ProcessNewAccount NewFakeAccount |> printfn "Result = %A"

ProcessNewAccount AccountLogged |> printfn "Result = %A"
ProcessNewAccount NewAccount |> printfn "Result = %A"

In questo esempio è veramente interessante vedere come è possibile dichiarare delle funzioni
che sono composte da diverse funzioni in ordine e numero variabile che descrivono appunto
il flusso di esecuzione una volta chiamate.
È inoltre un buon esempio di Railway Oriented Programming che in poche parole riduce
un insieme di espressioni di calcolo(Monads) in flusso di success o failure. In realtà è molto
più di questo, ma anche in questo caso meriterebbe un articolo a parte.
Per concludere vorrei sottolineare quanto in un mondo che si sta spostando verso i Servizi
(Paas, Saas, Iaas, …) sia strettamente legato a ragionare per composizione.
Reactive System
Un altro buon esempio di quanto sia potente F# è dato dalla semplicità con cui si possa
applicare Reactive Programming.
Se prendiamo in considerazione il Tipo Event in F#, che deriva dall’assembly Fsharp.Core.dll
è diverso da quello classico del .Net che siamo abituati ad usare in C# e VB.net.
Event, implementa l’interfaccia IEvent che a sua volta implementa l’interfaccia
IDelegateEvent, ma grazie al Modulo Control.Event implementa anche l’interfaccia
IObservable fornendo un set di metodi che permettono di gestire il flusso di eventi.
Questo è davvero interessante perché grazie ad F# ho praticamente implementato un
aspetto della programmazione reattiva intrinsecamente.
Nell’esempio sottostante, preso e leggermente modificato da MSDN per via di un errore è
possibile vedere come usare questo flusso di esempi per cambiare colore allo sfondo di una
finestra WinForm tramite il movimento del mouse e limitarne il comportamento stesso.
let form = new Form(Text = "F# Windows Form",
Visible = true,
TopMost = true)
form.MouseMove
|> Event.filter ( fun evArgs ->
evArgs.X > 0 && evArgs.Y > 0 &&
evArgs.X < 255 && evArgs.Y < 255)
|> Event.add ( fun evArgs ->
form.BackColor <- System.Drawing.Color.FromArgb(
evArgs.X, evArgs.Y, evArgs.X ^^^ evArgs.Y))

.Net ed Nuget.
Per concludere la lista degli aspetti positive vorrei menzionare che F# rispetto ad altri
linguaggi funzionali fa parte del .Net Framework.
Questo è davvero fondamentale dal mio punto di vista perché permette di poter accedere
ed utilizzare tutti gli assembly, oggetti e membri di cui è composto il framework.
Per accedere ad un file, come per l’esempio precedente, posso aggiungere il riferimento alla
libreri System.IO e usare tutti i suoi membri aprendo un file in lettura o scrittura.
Sembra un aspetto banale, ma non lo è affatto perché se non fosse possibile utilizzare il
framework allora F# diventerebbe un linguaggio per uso iper-specialistico per la mancanza
di API adeguate.
Infine una nota speciale va anche alle librerie scaricabili da nuget che permetto di usare F#
in diversi ambiti.
FsLab ne è un esempio (http://fslab.org/getting-started/), fornisce tutto ciò che è necessario
per rappresentare dati con un set di oggetti molto semplici da usare e di immediata
visualizzazione tramite F# Interactive. Utilissimo in unione con il Type Provider R nei
contesti di Data Science e Machine Learning.
Suave (https://suave.io/) è invece un’implementazione di un server web attraverso uno
sviluppo orientato alla Task composition e al Route Flow. Può essere eseguito su Linux, OS X
e Windows.
Xamarin e Cross-Platform
Un altro punto interessante e di crescente interesse è sicuramente la sua estesa
implementazione nella programmazione Cross-Platoform ed in particolare in Xamarin.
Attualmente è uscita da poco la versione Xamarin Studio 6 ed è pienamente supportata la
programmazione con F# 4.

Contro
Dopo aver parlato di alcuni dei tanti aspetti positivi del linguaggio è giunto il momento di
parlare di quelli che sono negativi.
In questo caso, secondo il mio parare, è meglio riflettere più ad alto livello che mostrare
degli esempi negativi. Anche perché, se pensiamo al fatto che possiamo accedere al
framework interamente, risulta difficile spulciare tutto ciò che effettivamente non è
supportato. Piuttosto è molto più utile vedere perché non utilizzarlo.
Una degli aspetti che ritengo negativi è senz’altro l’integrazione.
In realtà suona più come un monito. F# non è né C# né Vb.net, sebbene abbia una forte
community che lo tiene sempre aggiornato l’integrazione con i sistemi di sviluppo come
Visual Studio è diversa da ciò che siamo abituati ad usare.
Per intenderci, molti plug-in, snippet, tipi di progetto, metriche, ecc non sono supportati in
questo linguaggio e di conseguenza dobbiamo arrangiarci. Questo in vista di piccole realtà o
sviluppatori singoli può essere visto come un punto a sfavore.

In realtà, questo si ricollega al secondo punto.

Anche per grosse realtà il costo di cambiare ulteriormente strumenti di lavoro e modalità,
paradigma e in generale anche per tutto quello che riguarda il ciclo di vista del software
possono risultare da un’analisi approfondita insoddisfacenti.
Con questo non voglio dire che ci sono realtà in cui non sia possibile, anzi, vi sono casi in cui
è stato davvero utile cambiare completamente paradigma ed utilizzare F#
(http://fsharp.org/testimonials/), ma spesso i costi-benefici sono a favore dei primi.
Infine ribadisco ancora che pensare in funzionale è pensare con una modalità molto più
astratta e se vogliamo vicina alla matematica, mentre ad oggetti è più semplice immaginare
cosa stiamo descrivendo, di conseguenza potrebbe essere più complesso.

Conclusioni
Dopo questa analisi che si è conclusa con gli aspetti negativi è doveroso ricordare che avere
la possibilità di conoscere un nuovo paradigma nella sua interezza e poter intraprendere
questo studio attraverso degli strumenti e il .Net Framework che già conosciamo nella sua
interezza è davvero interessante perché limita il costo di apprendimento.
Dal mio punto di vista il solo fatto di avvicinarsi alla matematica e alla funzionalità è davvero
molto utile in quanto permette di “dimenticarsi” per un attimo della forma e concentrarsi
sulla sostanza.