è F # per IronPython / IronRuby come C # è quello di VB.NET?

Question

Ho appena ascoltato Podcast di Chris Smith a parlare di F # in cui si parla di come F # è un linguaggio che permette di problemi di approccio in un modo diverso che in C # / VB.NET, cioè invece di "spingere bit intorno" tu 'a catena insieme trasformazioni di dati', e che il modo in F # sarà 'diventare come XML', qualcosa che si utilizza in aggiunta alla lingua di propria scelta (C # o VB.NET), al fine di risolvere alcuni problemi in maniera più efficiente modo.

Questo mi ha fatto pensare a circa il rapporto dei linguaggi .NET, ecco come li capisco:

• C # e VB.NET sono sintatticamente ma non sostanzialmente diverso , vale a dire un programmatore C # non sarebbe imparare VB.NET, al fine di "problemi di approccio in un modo nuovo"
• tuttavia, un C # o VB.NET programmatore avrebbe imparato F #, al fine di "problemi di programmazione approccio in modo funzionale "

Ma che dire di IronPython e IronRuby ? Chris ha detto che "F # imparato molto da Ruby e Python" così penserei che F # ha un rapporto simile a IronRuby / IronPython e C # deve VB.NET. Tuttavia, un po 'googling intorno a me che dice IronRuby e IronPython sono entrambi costruiti sulla DLR ma F # non è .

Come sono i rapporti tra F #, IronPython e IronRuby per essere meglio compresi?

Answer 1

F # e IronPython / IronRuby sono anni luce dal punto di vista linguistico. F # è un linguaggio compilato funzionale altamente digitato. IronRuby / IronPython sono dinamicamente tipizzato, interpretato lingue.

Credo IronPython ha inoltre supporta la compilazione, ma non sono sicuro al 100%, e meno di rubino.

Il rapporto tra VB.Net e C # è molto più vicino.

Answer 2

In molti modi F # e Ruby / Python sono superficialmente simile. Tutte e tre le lingue consentono di esprimere in modo conciso idee senza sporcare il codice con molti tipi. Tuttavia, F # è in realtà molto diversa da Ruby e Python, in quanto F # è un linguaggio a tipizzazione statica, mentre Ruby e Python vengono digitati in modo dinamico. Idiomatica codice F # cita raramente i tipi, ma il compilatore deduce i tipi e gli eventuali errori di tipo verrà contrassegnato dal compilatore durante la compilazione. Per Ruby e Python, utilizzando un valore al tipo sbagliato genererà solo gli errori in fase di esecuzione. Ruby e Python del dinamismo significa che entrambi sono più suscettibili di metaprogrammazione di F # è (i tipi possono essere modificati in fase di esecuzione, per esempio). D'altra parte, F # sta per essere più performante per la maggior parte delle attività (paragonabili a C #), e offre molte belle astrazioni funzionali come i sindacati discriminati con pattern matching. E 'certamente vero che l'apprendimento di una di queste lingue e vi porterà a pensare ai problemi in modo diverso di quanto si fa in C # o VB.NET, ma il tuo approccio probabilmente varierà molto tra F # e Python / Rubino pure.

Answer 3

Direi F # imparato molto di più da OCaml di quanto abbia fatto da Ruby e Python combinato. L'unico confronto reale è che F # è porta ML a .NET nello stesso modo in cui IronPython / Rubino portare Python / Ruby per .NET.

Answer 4

F # è più di una lingua "strumento", dove ci sono problemi specifici che vanno affrontati con un approccio funzionale. F # è intrinsecamente thread-safe, che dà speranza che possa essere utile per scalare un'applicazione da utilizzare più processori. Vedo F # utilizzato per costruire i componenti che verranno utilizzati in VB.NET o C # per gestire problemi specifici.

Answer 5

Ci sono aspetti di F # che sono simili ai linguaggi dinamici; tuttavia, la risposta di JaredPar riassume veramente. F # è in essa la propria categoria di programmazione funzionale dove, come IronRuby e IronPython sono linguaggi dinamici e C # / VB OO Lingue. Tutti possono fare le stesse cose e dipende solo da come si vuole farlo. Ognuno ha i suoi pro e contro per un dato problema.

Answer 6

Nota: Questa è per lo più una raccolta dei miei pensieri e osservazioni sull'argomento. Sono un programmatore C # di giorno e di notte, Python.

Si sono d'accordo con alcune delle cose che è stato detto, ma ho un po 'di tempo e si sentono come elaborare e condividere i miei pensieri.

F # è un linguaggio funzionale. Il che significa che sono in realtà più interessati con i verbi per così dire. E 'ancora staticamente tipizzato e viene eseguito sul CLR, ma si struttura il codice in modo diverso e di lavoro attraverso i problemi in modo diverso. Di solito la gente pensa che i linguaggi funzionali sono più matematica nella struttura e più facile da dimostrare formalmente. Certo che è generalmente considerata come la maggior parte accademica.

C # e altri linguaggi OO staticamente tipizzati sono davvero più concentrati sui sostantivi per promuovere la mia analogia. Così si struttura il codice e lavorare attraverso i problemi per quanto riguarda questo. Naturalmente ci sono anche problemi naturali con mantenimento dello stato e con metodi non-deterministici su oggetti che tendono a venire più spesso in linguaggi OO.

E naturalmente F # ha alcune caratteristiche e le idee prese in prestito da linguaggi OO, mentre C # ha idee e caratteristiche prese in prestito dal funzionale.

Confronto tra Python e C # è più circa la differenza tra tipizzazione dinamica e statica (anche se pitone non offre alcune caratteristiche funzionali che C # non lo fa ancora). tipizzazione dinamica essendo di norma molto più facile da maneggiare introspezione attività / riflessione e run-time modifica durante l'aggiunta del rischio di errori run-time a causa di errori di battitura o oggetti errati utilizzati in codice "regolare".

linguaggi statici di solito hanno un certo overhead sviluppatore che i linguaggi dinamici non hanno. L'overhead sembra essere solito a causa di dover creare strati di cose astratte di distanza e la creazione di gerarchie di ereditarietà e interfacce di lavorare con la necessaria / wanted astrazione. Dal momento che si sta cercando di evitare le dipendenze ai tipi.

Sembra lingue statica può essere molto più facile da gestire in squadre più grandi. Inoltre si ottiene i vantaggi di refactoring molto facilmente con tutti i controlli e gli strumenti di là fuori.