¿Por qué F # tiene un modo interactivo pero no C #?


32

F # sale de la caja con un REPL interactivo. C # no tiene nada de eso y, de hecho, es un poco difícil de jugar sin configurar un proyecto completo (aunque LINQpad funciona y también es posible hacerlo a través de powershell).

¿Hay algo fundamentalmente diferente en los lenguajes que permite que F # tenga la consola interactiva pero que dificulta su implementación para C #?


Como muchos años después la gente todavía está llegando a esta pregunta, debo señalar que ahora hay muchas opciones. Puede usar powershell (preinstalado en todas las máquinas modernas de Windows) para jugar con el marco .Net. O puede usar LINQpad para crear un prototipo de código arbitrario de C # . O puede usar ScriptCs o puede usar un entorno de tipo jsfiddle en línea como Complify.net o Jsil . Muchas opciones


44
C # hace tener un REPL. Se llama la Ventana Inmediata y ha estado disponible durante bastante tiempo. Tiene ciertas limitaciones, algunas de las cuales se han vuelto cada vez más notables desde C # 3.0, ya que las nuevas características del lenguaje no eran compatibles, pero sin embargo es un REPL completo.
Allon Guralnek


Recuerdo que la versión demo del proyecto Roslyn alrededor del año 2012 tenía un REPL para VS2010
James

@DanielHakimi: Gracias por este comentario, no tenía ni idea de que esto estaba incluido en VS2015, solo pensé que podría usar la ventana Inmediato durante la depuración. VS2015 ahora contiene la ventana de herramientas interactivas de C # , accesible a través de Ver -> Otras ventanas -> C # interactivo, que parece ser un REPL completo basado en Roslyn, separado del entorno de depuración.
Lou

Respuestas:


56

¿Hay algo fundamentalmente diferente en los lenguajes que permite que F # tenga la consola interactiva pero que dificulta su implementación para C #?

Sí.

F # es un descendiente del lenguaje de programación ML, que a su vez estuvo fuertemente influenciado por lenguajes como Lisp y Scheme. Esos idiomas fueron diseñados desde el primer día para tener tres propiedades agradables.

Primero, esos lenguajes realmente no tienen declaraciones de la forma en que piensas en C #. Por el contrario, casi todo es una expresión que tiene un valor , por lo que un mecanismo de evaluar y luego imprimir el valor tiene sentido en casi todas las situaciones.

En segundo lugar, esos lenguajes desalientan la programación con efectos secundarios, por lo que puede hacer evaluaciones sin preocuparse de que vaya a estar arruinando el estado global.

En tercer lugar, la mayor parte del trabajo que realiza en esos idiomas es "en el nivel superior"; normalmente no hay una "clase" o un "espacio de nombres" encerrados u otro contexto.

Por el contrario, C # enfatiza el flujo de control de programación con declaraciones que producen efectos secundarios, y esas declaraciones siempre están en múltiples contenedores anidados: un espacio de nombres, una clase, un método, etc.

Así que estas son todas las cosas que hacen que sea más difícil para C # para tener un REPL, pero ciertamente no es imposible . Solo tendríamos que averiguar cuál es la semántica de las declaraciones y expresiones que aparecen fuera del contexto habitual, y cuál es la semántica de las mutaciones que cambian los enlaces de nombres, y así sucesivamente.

¿Por qué F # tiene un modo interactivo pero no C #?

Porque el equipo F # decidió que tener un ciclo REPL era un escenario de prioridad uno para ellos. El equipo de C # históricamente no lo ha hecho. Las características no se implementan a menos que sean las características de mayor prioridad que se ajustan al presupuesto; hasta ahora, un C # REPL no ha estado en la parte superior de nuestra lista.

El proyecto Roslyn tiene un C # REPL (y eventualmente también tendrá un VB REPL, pero aún no está listo). Puede descargar una versión preliminar para ver cómo le gusta en

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


77
Python tiene una buena REPL, y tiene declaraciones, efectos secundarios y espacios de nombres. Y también lo hacen Javascript, Bash, etc. Muchos idiomas que violan sus criterios tienen REPL muy bien.
Lie Ryan

2
Bienvenido de nuevo Eric! Espero que veamos más respuestas tuyas.
SoluciónYogi

16
@LieRyan Creo que te perdiste todo el punto. El único "Criterio" para un bucle REPL interactivo es que alguien se sentó y escribió uno; en F # era de alta prioridad y relativamente fácil, en C # era de baja prioridad y relativamente difícil, por lo tanto, F # obtuvo uno desde el principio y C # no.
KutuluMike

Interesante. Agregaría que la experiencia adquirida al construir tantos compiladores para .NET Framework antes del lanzamiento de VS2010 (cuento cuatro C #, cuatro VB.NET, dos J # y dos C ++ / CLI) debe haber afectado cómo un nuevo compilador para Se construyó un nuevo lenguaje .NET. Estoy seguro de que se construyó en un estilo al estilo de Roslyn con mucha reflexión sobre cómo habilitar el escenario Compilador como servicio, que parece ser la dirección en la que se desarrollarán todos los futuros compiladores .NET y revisiones de compiladores. Para mí, parece que la era en la que nació F # jugó inevitablemente un papel en cómo se escribió su compilador.
Allon Guralnek

Gran respuesta. Acerca de Python vs C #: {} los lenguajes de sintaxis no se combinan bien para REPL, los lenguajes basados ​​en sangría tienen un gran avance aquí. Nunca pensé que lo pensaría o lo diría: la sintaxis de sangría es mejor que la sintaxis {}. Para REPL, así como para la legibilidad del código. Por lo tanto, siempre que no haya una metantantaxis C # que sustituya la sangría con {}, la experiencia REPL nunca será tan fluida como, por ejemplo, en F # o Python.
citykid


2

Creo que es sobre todo una cosa histórica. Los entornos REPL siempre se han asociado con lenguajes funcionales, incluidos los lenguajes familiares ML, y F # se mantiene fiel a esa tradición. Tenga en cuenta que el entorno interactivo es algo que los usuarios que provienen de antecedentes funcionales dan por sentado, la falta de dicha característica pondría a VS y, por extensión, a F #, en desventaja.

Por otro lado, tal característica no ha sido común en la comunidad OOP.

Sin embargo, hay REPL disponibles para muchos lenguajes no funcionales, incluidos C, Java o C #. Además, si bien está muy lejos de un REPL completo, la función Autos en VS muestra que ciertamente es factible con C #.


1
Esta es la explicación más plausible que he visto. Al principio, estaba Fortran y Lisp, y Lisps tenía respuestas. Lisp engendró ... bueno, ya tienes la idea. Los lenguajes de linaje Lisp tenían respuestas, y el linaje Fortran no.
Aaron

@Aaron LISP es 1959, pero REPL se atribuye a las máquinas LISP, 1973. Para entonces, ya había muchos, muchos idiomas. Notablemente PASCAL y Smalltalk.
Sprague

1

Creo que C # está principalmente orientado a objetos. Para escribir incluso el código más simple, debe dividirlo en varias clases. Para usar REPL, necesitaría escribir mucho código.

F #, que es principalmente funcional, no tiene este problema y puede escribir fácilmente incluso código complejo en fasshion directo y convertirlo en objeto / s más tarde.

Es más fácil escribir una sola línea de función que escribir una clase, que abarca muchas líneas.


1
No hay nada que le impida utilizar funciones / clases definidas en archivos externos en las declaraciones REPL. El hecho de que OOP sea más detallado no obstaculiza la funcionalidad REPL por sí misma.
scrwtp

1
Python, al estar bastante orientado a objetos y presentar saltos de línea sintácticamente significativos, tiene un REPL decente. Scala, al estar estáticamente escrito, compilado y más bien orientado a objetos, tiene un REPL. REPL es más útil para cosas cortas como importar clases existentes y llamar a algunos métodos; la verbosidad del idioma no es una preocupación. Por ejemplo, SQL es bastante detallado, pero cada base de datos SQL viene con un REPL (una 'herramienta de consulta').
9000
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.