Perché F # ha una modalità interattiva ma non C #?


32

F # viene fornito con un REPL interattivo. C # non ha nulla del genere ed è in effetti un po 'difficile da giocare senza impostare un progetto completo (sebbene LINQpad funzioni ed è anche possibile farlo tramite PowerShell).

C'è qualcosa di fondamentalmente diverso nei linguaggi che consente a F # di avere la console interattiva ma rende difficile implementarlo per C #?


Poiché molti anni dopo la gente continua a rispondere a questa domanda, dovrei notare che ora ci sono molte opzioni. Puoi usare PowerShell (preinstallato su ogni moderno computer Windows) per giocare con il framework .Net. Oppure puoi usare LINQpad per prototipare codice c # arbitrario . Oppure puoi usare ScriptCs oppure puoi usare un ambiente di tipo jsfiddle online come Complify.net o Jsil . Molte opzioni.


4
C # ha un REPL. Si chiama Finestra Immediata ed è disponibile da un po 'di tempo. Presenta alcune limitazioni, alcune delle quali sono diventate sempre più evidenti dal C # 3.0, poiché le nuove funzionalità del linguaggio non sono state supportate da esso, ma è comunque una REPL a tutti gli effetti.
Allon Guralnek,


Ricordo che la versione demo del progetto Roslyn intorno al 2012 conteneva un REPL per VS2010
James,

@DanielHakimi: Grazie per questo commento, non avevo idea che fosse incluso in VS2015, pensavo solo che potresti usare la finestra immediata durante il debug. VS2015 ora contiene la finestra dello strumento C # Interactive , accessibile tramite Visualizza -> Altre finestre -> C # Interactive, che sembra essere un REPL completo basato su Roslyn, separato dall'ambiente di debug.
Lou

Risposte:


56

C'è qualcosa di fondamentalmente diverso nei linguaggi che consente a F # di avere la console interattiva ma rende difficile implementarlo per C #?

Sì.

F # è un discendente del linguaggio di programmazione ML, che a sua volta è stato fortemente influenzato da linguaggi come Lisp e Scheme. Queste lingue sono state progettate dal primo giorno per avere tre belle proprietà.

Innanzitutto, quelle lingue non hanno davvero delle dichiarazioni nel modo in cui le pensi in C #. Piuttosto, quasi tutto è un'espressione che ha un valore , quindi un meccanismo di valutazione e stampa del valore ha senso in quasi ogni situazione.

In secondo luogo, quei linguaggi scoraggiano la programmazione con effetti collaterali, in modo da poter effettuare valutazioni senza preoccuparsi di incasinare lo stato globale.

Terzo, la maggior parte del lavoro che svolgi in quelle lingue è "al massimo livello"; in genere non esiste alcuna "classe" o "spazio dei nomi" o altro contesto.

Al contrario, C # enfatizza il flusso di controllo della programmazione con istruzioni che producono effetti collaterali e tali istruzioni si trovano sempre in più contenitori nidificati: uno spazio dei nomi, una classe, un metodo e così via.

Quindi queste sono tutte cose che rendono più difficile per C # avere un REPL, ma certamente non impossibile . Dobbiamo solo capire quale sia la semantica per le dichiarazioni e le espressioni che appaiono al di fuori del normale contesto, e quali sono le semantiche delle mutazioni che cambiano i legami dei nomi e così via.

Perché F # ha una modalità interattiva ma non C #?

Perché il team F # ha deciso che avere un ciclo REPL era uno scenario prioritario per loro. Il team C # storicamente no. Le funzionalità non vengono implementate a meno che non siano le funzionalità con la massima priorità che rientrano nel budget; fino ad ora, un REPL C # non è stato in cima alla nostra lista.

Il progetto Roslyn ha un REPL C # (e alla fine avrà anche un REPL VB, ma non è ancora pronto.) Puoi scaricare una versione di anteprima per vedere come ti piace in

http://www.microsoft.com/en-us/download/details.aspx?id=27746


7
Python ha una buona REPL e ha istruzioni, effetti collaterali e spazi dei nomi. E così anche Javascript, Bash, ecc. Molte lingue che violano i tuoi criteri hanno REPL bene.
Lie Ryan,

2
Bentornato Eric! Spero che vedremo più risposte da te.
SoluzioneYogi l'

16
@LieRyan Penso che ti sia perso l'intero punto. L'unico "criterio" per un ciclo REPL interattivo è che qualcuno si è seduto e ne ha scritto uno; in F # era alta priorità e relativamente facile, in C # era bassa priorità e relativamente difficile, quindi F # ne ottenne uno all'inizio e C # no.
KutuluMike,

Interessante. Aggiungo che l'esperienza acquisita nella creazione di così tanti compilatori per il framework .NET prima del rilascio di VS2010 (conto quattro C #, quattro VB.NET, due J # e due C ++ / CLI) deve aver influenzato il modo in cui un nuovo compilatore per è stato creato un nuovissimo linguaggio .NET. Sono sicuro che sia stato costruito in stile Roslyn con un sacco di pensieri su come abilitare lo scenario Compiler-as-a-Service, che sembra la direzione in cui svilupperai tutti i futuri compilatori .NET e le revisioni dei compilatori. A me sembra che l'era in cui è nato F # abbia inevitabilmente avuto un ruolo nel modo in cui è stato scritto il suo compilatore.
Allon Guralnek,

Bella risposta. Informazioni su Python vs C #: {} i linguaggi di sintassi non si piegano bene per i REPL, i linguaggi basati sul rientro hanno un grande progresso qui. Non avrei mai pensato di pensarlo o dirlo: la sintassi del rientro è migliore della sintassi {}. Per i REPL e per la leggibilità del codice. Quindi finché non esiste una metasintassi C # che sostituisca il rientro con {}, l'esperienza REPL non sarà mai fluida come ad esempio in F # o Python.
citykid,


2

Credo che sia principalmente una cosa storica. Gli ambienti REPL sono sempre stati associati ai linguaggi funzionali, inclusi i linguaggi della famiglia ML e F # rimane fedele a quella tradizione. Tieni presente che l'ambiente interattivo è qualcosa che gli utenti provenienti da background funzionali danno per scontato, la mancanza di una tale funzionalità sarebbe mettere VS e - per estensione - F #, in svantaggio.

D'altra parte, nessuna di queste funzionalità è stata all'ordine del giorno nella comunità OOP.

Esistono tuttavia REPL disponibili per molti linguaggi non funzionali, tra cui C, Java o C #. Inoltre, anche se è ben lungi dall'essere un vero REPL, la funzione Autos in VS mostra che è certamente fattibile con C #.


1
Questa è la spiegazione più plausibile che abbia mai visto. All'inizio c'era Fortran e c'era Lisp, e Lisps aveva i sostituti. Lisp generò ... beh, hai avuto l'idea. Le lingue del lignaggio di Lisp avevano rimpiazzi, e il lignaggio di Fortran no.
Aaron,

@Aaron LISP è del 1959 ma REPL è attribuito alle macchine LISP, 1973. A quel punto, c'erano già molte, molte lingue in giro. In particolare PASCAL e Smalltalk.
Sprague,

1

Credo che C # sia principalmente orientato agli oggetti. Per scrivere anche il codice più semplice, è necessario dividerlo in più classi. Per utilizzare REPL, è necessario scrivere un sacco di codice.

Essendo F # principalmente funzionale non ha questo problema e puoi facilmente scrivere anche codice complesso in modo semplice e convertirlo in oggetto / i in seguito.

È più semplice scrivere una singola riga di funzione piuttosto che scrivere la classe, che si estende su molte righe.


1
Non c'è nulla che ti impedisca di utilizzare funzioni / classi definite in file esterni nelle istruzioni REPL. Il fatto che OOP sia più dettagliato non ostacola la funzionalità REPL da sola.
scrwtp,

1
Python, essendo abbastanza orientato agli oggetti e caratterizzato da interruzioni di riga sintatticamente significative, ha un REPL decente. Scala, essendo staticamente tipizzato, compilato e piuttosto orientato agli oggetti, ha un REPL. REPL è molto utile per cose brevi come importare classi esistenti e chiamare alcuni metodi; la verbosità della lingua non è una preoccupazione. Ad esempio, SQL è piuttosto dettagliato ma ogni database SQL viene fornito con un REPL (uno "strumento di query").
9000,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.