Quali sono i vantaggi dell'utilizzo di C # rispetto a F # o F # rispetto a C #? [chiuso]

Lavoro per un'azienda tecnologica che fa più prototipi che spedizioni di prodotti. Mi è appena stato chiesto qual è la differenza tra C # e F #, perché MS ha creato F # e quali scenari sarebbe meglio di C #.

Uso il linguaggio da un po 'di tempo e lo adoro, quindi potrei facilmente andare avanti sulle fantastiche funzionalità di F #, tuttavia mi manca l'esperienza in C # per dire perché dovremmo usarne uno sull'altro.

Quali sono i vantaggi dell'utilizzo di C # rispetto a F # o F # rispetto a C #?

Vantaggi generali della programmazione funzionale rispetto ai linguaggi imperativi:

Puoi formulare molti problemi molto più facilmente, più vicini alla loro definizione e più concisi in un linguaggio di programmazione funzionale come F # e il tuo codice è meno soggetto a errori (immutabilità, sistema di tipi più potente, algoritmi ricurivi intuitivi). Puoi codificare quello che intendi invece di quello che il computer vuole che tu dica ;-) Troverai molte discussioni come questa quando lo cerchi su Google o addirittura lo cerchi in SO.

Vantaggi speciali di F #:

• La programmazione asincrona è estremamente facile e intuitiva con async {}-expressions - Anche con ParallelFX, il codice C # corrispondente è molto più grande

• Integrazione molto semplice di compilatori di compilatori e linguaggi specifici del dominio

• Estendere la lingua in base alle tue esigenze: LOP

• Unità di misura

• Sintassi più flessibile

• Soluzioni spesso più brevi ed eleganti

Dai un'occhiata a questo documento

I vantaggi di C # sono che è spesso più accurato per applicazioni "imperative" (interfaccia utente, algoritmi imperativi) rispetto a un linguaggio di programmazione funzionale, che il .NET Framework che utilizza è progettato in modo imperativo e che è più diffuso.

Inoltre puoi avere F # e C # insieme in un'unica soluzione, così puoi combinare i vantaggi di entrambi i linguaggi e usarli dove sono necessari.

È come chiedere qual è il vantaggio di un martello su un cacciavite. Ad un livello estremamente alto, entrambi fanno essenzialmente la stessa cosa, ma a livello di implementazione è importante selezionare lo strumento ottimale per ciò che stai cercando di ottenere. Ci sono attività che sono difficili e richiedono tempo in c # ma facili in f #, come provare a battere un chiodo con un cacciavite. Puoi farlo, di sicuro, semplicemente non è l'ideale.

La manipolazione dei dati è un esempio che posso indicare personalmente dove f # brilla davvero e c # può essere potenzialmente ingombrante. D'altro canto, direi che (in generale) l'interfaccia utente con stato complessa è più facile in OO (c #) che funzionale (f #). (Probabilmente ci sarebbero alcune persone che non sono d'accordo con questo dato che è "fico" in questo momento "dimostrare" quanto sia facile fare qualsiasi cosa in F #, ma io lo sostengo). Ce ne sono innumerevoli altri.

• F # offre prestazioni migliori rispetto a C # in matematica
• È possibile utilizzare progetti F # nella stessa soluzione con C # (e chiamare da uno all'altro)
• F # è ottimo per la programmazione algoritmica complessa, le applicazioni finanziarie e scientifiche
• F # logicamente è davvero buono per l'esecuzione parallela (è più facile eseguire il codice F # su core paralleli rispetto a C #)

Per rispondere alla tua domanda come ho capito: perché usare C #? (Dici di essere già venduto su F #.)

Prima di tutto. Non è solo "funzionale contro OO". È "Funzionale + OO contro OO". Le caratteristiche funzionali di C # sono piuttosto rudimentali. I fa # non lo sono. Nel frattempo, F # fa quasi tutte le funzionalità OO di C #. Per la maggior parte, F # finisce come un superset delle funzionalità di C #.

Tuttavia, ci sono alcuni casi in cui F # potrebbe non essere la scelta migliore:

• Interop. Ci sono molte librerie che semplicemente non saranno troppo comode da F #. Forse sfruttano certe cose di C # OO che F # non fa lo stesso, o forse si basano sulle parti interne del compilatore C #. Ad esempio, Expression. Sebbene sia possibile trasformare facilmente una citazione in F # in un'espressione, il risultato non è sempre esattamente quello che creerebbe C #. Alcune biblioteche hanno un problema con questo.

  • Sì, l'interoperabilità è una rete piuttosto grande e può causare un po 'di attrito con alcune librerie.

  • Considero l'interoperabilità da includere anche se si dispone di una base di codice esistente di grandi dimensioni. Potrebbe non avere senso iniziare a scrivere parti in F #.

• Strumenti di progettazione. F # non ne ha. Non significa che non possa averne, ma al momento non puoi creare un'app WinForms con F # codebehind. Anche dove è supportato, come nelle pagine ASPX, attualmente non ottieni IntelliSense. Quindi, devi considerare attentamente dove saranno i tuoi limiti per il codice generato. Su un progetto molto piccolo che utilizza quasi esclusivamente i vari designer, potrebbe non valere la pena usare F # per la "colla" o la logica. Su progetti più grandi, questo potrebbe diventare un problema minore.

  • Questo non è un problema intrinseco. A differenza della risposta di Rex M, non vedo nulla di intrinseco in C # o F # che li renda migliori per fare un'interfaccia utente con molti campi mutabili. Forse si riferiva al sovraccarico extra di dover scrivere "mutabile" e usare <- invece di =.

  • Dipende anche dalla libreria / designer utilizzato. Ci piace usare ASP.NET MVC con F # per tutti i controller, quindi un progetto Web C # per ottenere i designer ASPX. Mescoliamo l'attuale "codice inline" ASPX tra C # e F #, a seconda di ciò di cui abbiamo bisogno in quella pagina. (IntelliSense e tipi F #.)

• Altri strumenti. Potrebbero aspettarsi solo C # e non sapere come gestire i progetti F # o il codice compilato. Inoltre, le librerie di F # non vengono fornite come parte di .NET, quindi hai qualcosa in più da distribuire.

• Ma il problema numero uno? Persone. Se nessuno dei tuoi sviluppatori desidera imparare F # o, peggio, ha gravi difficoltà a comprendere determinati aspetti, probabilmente stai brindando. (Anche se, in questo caso, direi che sei comunque un toast.) Oh, e se la direzione dice di no, potrebbe essere un problema.

Ne ho scritto qualche tempo fa: Why NOT F #?

Stai chiedendo un confronto tra un linguaggio procedurale e un linguaggio funzionale, quindi credo che la tua domanda possa trovare risposta qui: qual è la differenza tra programmazione procedurale e programmazione funzionale?

Quanto al motivo per cui MS ha creato F #, la risposta è semplicemente: la creazione di un linguaggio funzionale con accesso alla libreria .Net ha semplicemente ampliato la propria base di mercato. E visto come la sintassi è quasi identica a OCaml, non ha richiesto molto sforzo da parte loro.

F # non è ancora un altro linguaggio di programmazione se lo stai confrontando con C #, C ++, VB. C #, C, VB sono tutti linguaggi di programmazione imperativi o procedurali. F # è un linguaggio di programmazione funzionale.

Due principali vantaggi dei linguaggi di programmazione funzionale (rispetto ai linguaggi imperativi) sono 1. che non hanno effetti collaterali. Ciò semplifica notevolmente il ragionamento matematico sulle proprietà del programma. 2. che le funzioni sono cittadini di prima classe. È possibile passare funzioni come parametri ad altre funzioni con la stessa facilità con cui altri valori.

Entrambi i linguaggi di programmazione imperativi e funzionali hanno i loro usi. Sebbene non abbia ancora svolto un lavoro serio in F #, attualmente stiamo implementando un componente di pianificazione in uno dei nostri prodotti basato su C # e faremo un esperimento codificando lo stesso scheduler in F # per vedere se la correttezza del l'implementazione può essere convalidata più facilmente rispetto all'equivalente C #.

F # è essenzialmente il C ++ dei linguaggi di programmazione funzionali. Hanno mantenuto quasi tutto da Objective Caml, comprese le parti davvero stupide, e lo hanno gettato sopra il runtime .NET in modo tale da portare anche tutte le cose cattive da .NET.

Ad esempio, con Objective Caml ottieni un tipo di null, l'opzione <T>. Con F # si ottengono tre tipi di null, opzione <T>, Nullable <T> e riferimenti null. Ciò significa che se hai un'opzione devi prima controllare se è "Nessuno", quindi devi controllare se è "Some (null)".

F # è come il vecchio clone di Java J #, solo un linguaggio imbastardito solo per attirare l'attenzione. Alcune persone lo adoreranno, altri addirittura lo useranno, ma alla fine è ancora una lingua vecchia di 20 anni attaccata al CLR.

Uno degli aspetti di .NET che mi piace di più sono i generici. Anche se scrivi codice procedurale in F #, trarrai comunque vantaggio dall'inferenza del tipo. Rende facile scrivere codice generico.

In C #, scrivi codice concreto per impostazione predefinita e devi lavorare in più per scrivere codice generico.

In F # scrivi codice generico per impostazione predefinita. Dopo aver trascorso oltre un anno di programmazione sia in F # che in C #, trovo che il codice della libreria che scrivo in F # sia più conciso e più generico del codice che scrivo in C #, ed è quindi anche più riutilizzabile. Perdo molte opportunità di scrivere codice generico in C #, probabilmente perché sono accecato dalle annotazioni di tipo obbligatorie.

Ci sono tuttavia situazioni in cui è preferibile usare C #, a seconda dei gusti e dello stile di programmazione.

• C # non impone un ordine di dichiarazione tra i tipi e non è sensibile all'ordine in cui vengono compilati i file.
• C # ha alcune conversioni implicite che F # non può permettersi a causa dell'inferenza del tipo.