¿Cuáles son los beneficios de usar C # frente a F # o F # frente a C #? [cerrado]

Trabajo para una empresa de tecnología que hace más prototipos que envío de productos. Me acaban de preguntar cuál es la diferencia entre C # y F #, por qué MS creó F # y qué escenarios sería mejor que C #.

He estado usando el lenguaje por un tiempo y me encanta, así que podría continuar fácilmente sobre las excelentes características de F #, sin embargo, no tengo la experiencia en C # para decir por qué deberíamos usar uno sobre el otro.

¿Cuáles son los beneficios de usar C # frente a F # o F # frente a C #?

Beneficios generales de la programación funcional sobre los lenguajes imperativos:

Puede formular muchos problemas mucho más fácilmente, más cerca de su definición y más concisos en un lenguaje de programación funcional como F # y su código es menos propenso a errores (inmutabilidad, sistema de tipos más poderoso, algoritmos recurrentes intuitivos). Puede codificar lo que quiere decir en lugar de lo que la computadora quiere que diga ;-) Encontrará muchas discusiones como esta cuando lo busque en Google o incluso lo busque en SO.

Ventajas especiales de F #:

• La programación asincrónica es extremadamente fácil e intuitiva con async {}-expresiones - Incluso con ParallelFX, el código C # correspondiente es mucho más grande

• Integración muy sencilla de compiladores de compiladores y lenguajes específicos de dominio

• Ampliando el idioma según lo necesite: LOP

• Unidades de medida

• Sintaxis más flexible

• A menudo, soluciones más cortas y elegantes.

Eche un vistazo a este documento

Las ventajas de C # son que a menudo es más preciso para las aplicaciones "imperativas" (interfaz de usuario, algoritmos imperativos) que un lenguaje de programación funcional, que el .NET-Framework que usa está diseñado imperativamente y que está más extendido.

Además, puede tener F # y C # juntos en una solución, por lo que puede combinar los beneficios de ambos lenguajes y usarlos donde sea necesario.

Es como preguntar cuál es el beneficio de un martillo sobre un destornillador. En un nivel extremadamente alto, ambos hacen esencialmente lo mismo, pero en el nivel de implementación es importante seleccionar la herramienta óptima para lo que está tratando de lograr. Hay tareas que son difíciles y requieren mucho tiempo en c # pero fáciles en f #, como intentar clavar un clavo con un destornillador. Puede hacerlo, seguro, simplemente no es ideal.

La manipulación de datos es un ejemplo que personalmente puedo señalar donde f # realmente brilla y c # puede ser potencialmente difícil de manejar. Por otro lado, yo diría (en términos generales) que la interfaz de usuario con estado compleja es más fácil en OO (c #) que funcional (f #). (Probablemente haya algunas personas que no estén de acuerdo con esto, ya que es "genial" ahora "probar" lo fácil que es hacer cualquier cosa en F #, pero lo mantengo). Hay muchos otros.

• F # tiene un mejor rendimiento que C # en matemáticas
• Puede usar proyectos de F # en la misma solución con C # (y llamar de uno a otro)
• F # es realmente bueno para aplicaciones científicas, financieras y de programación algorítmica compleja
• F # lógicamente es realmente bueno para la ejecución paralela (es más fácil hacer que el código F # se ejecute en núcleos paralelos que C #)

Para responder a su pregunta tal como la entiendo: ¿Por qué usar C #? (Dices que ya estás vendido en F #).

Antes que nada. No es solo "funcional versus OO". Es "Funcional + OO versus OO". Las características funcionales de C # son bastante rudimentarias. Los F # no lo son. Mientras tanto, F # hace casi todas las funciones de OO de C #. En su mayor parte, F # termina como un superconjunto de la funcionalidad de C #.

Sin embargo, hay algunos casos en los que F # podría no ser la mejor opción:

• Interop. Hay muchas bibliotecas que simplemente no se sentirán demasiado cómodas con F #. Tal vez exploten ciertas cosas de C # OO que F # no hace lo mismo, o tal vez se basan en componentes internos del compilador de C #. Por ejemplo, Expresión. Si bien puede convertir fácilmente una cita de F # en una expresión, el resultado no siempre es exactamente lo que crearía C #. Algunas bibliotecas tienen problemas con esto.

  • Sí, la interoperabilidad es una red bastante grande y puede resultar en un poco de fricción con algunas bibliotecas.

  • Considero que la interoperabilidad también se incluye si tiene una gran base de código existente. Puede que no tenga sentido comenzar a escribir partes en F #.

• Herramientas de diseño. F # no tiene ninguno. No significa que no pueda tener ninguno, pero en este momento no puede crear una aplicación WinForms con código F # subyacente. Incluso donde es compatible, como en las páginas ASPX, actualmente no obtiene IntelliSense. Por lo tanto, debe considerar cuidadosamente dónde estarán sus límites para el código generado. En un proyecto realmente pequeño que utiliza casi exclusivamente a varios diseñadores, puede que no valga la pena usar F # para el "pegamento" o la lógica. En proyectos más grandes, esto podría convertirse en un problema menor.

  • Este no es un problema intrínseco. A diferencia de la respuesta de Rex M, no veo nada intrínseco sobre C # o F # que los haga mejores para hacer una interfaz de usuario con muchos campos mutables. Quizás se refería a la sobrecarga adicional de tener que escribir "mutable" y usar <- en lugar de =.

  • También depende de la biblioteca / diseñador utilizado. Nos encanta usar ASP.NET MVC con F # para todos los controladores, luego un proyecto web C # para obtener los diseñadores ASPX. Mezclamos el "código en línea" ASPX real entre C # y F #, dependiendo de lo que necesitemos en esa página. (IntelliSense versus tipos F #).

• Otras herramientas. Es posible que solo estén esperando C # y no sepan cómo lidiar con proyectos de F # o código compilado. Además, las bibliotecas de F # no se envían como parte de .NET, por lo que tiene un poco más para enviar.

• ¿Pero el problema número uno? Personas. Si ninguno de sus desarrolladores quiere aprender F #, o peor aún, tiene serias dificultades para comprender ciertos aspectos, entonces probablemente esté tostado. (Aunque, en ese caso, diría que estás tostado de todos modos.) Ah, y si la gerencia dice que no, eso podría ser un problema.

Escribí sobre esto hace un tiempo: ¿Por qué NO F #?

Está pidiendo una comparación entre un lenguaje procedimental y un lenguaje funcional, así que creo que su pregunta puede responderse aquí: ¿Cuál es la diferencia entre la programación procedimental y la programación funcional?

En cuanto a por qué MS creó F #, la respuesta es simple: crear un lenguaje funcional con acceso a la biblioteca .Net simplemente amplió su base de mercado. Y al ver que la sintaxis es casi idéntica a OCaml, realmente no requirió mucho esfuerzo de su parte.

F # no es todavía otro lenguaje de programación si lo está comparando con C #, C ++, VB. C #, C, VB son todos lenguajes de programación imperativos o procedimentales. F # es un lenguaje de programación funcional.

Los dos principales beneficios de los lenguajes de programación funcionales (en comparación con los lenguajes imperativos) son 1. que no tienen efectos secundarios. Esto facilita mucho el razonamiento matemático sobre las propiedades de su programa. 2. que funciones son ciudadanos de primera. Puede pasar funciones como parámetros a otras funciones con la misma facilidad que con otros valores.

Tanto los lenguajes de programación imperativos como los funcionales tienen sus usos. Aunque todavía no he hecho ningún trabajo serio en F #, actualmente estamos implementando un componente de programación en uno de nuestros productos basado en C # y vamos a hacer un experimento codificando el mismo programador en F # también para ver si la corrección de la La implementación se puede validar más fácilmente que con el equivalente de C #.

F # es esencialmente el C ++ de los lenguajes de programación funcionales. Conservaron casi todo lo de Objective Caml, incluidas las partes realmente estúpidas, y lo agregaron al tiempo de ejecución de .NET de tal manera que también incluye todas las cosas malas de .NET.

Por ejemplo, con Objective Caml obtienes un tipo de nulo, la opción <T>. Con F # obtienes tres tipos de nulos, opción <T>, Nullable <T> y referencias nulas. Esto significa que si tiene una opción, primero debe verificar si es "Ninguno", luego debe verificar si es "Algunos (nulos)".

F # es como el antiguo clon de Java J #, solo un lenguaje bastardo solo para llamar la atención. A algunas personas les encantará, algunas de ellas incluso lo usarán, pero al final sigue siendo un idioma de 20 años incorporado al CLR.

Uno de los aspectos de .NET que más me gustan son los genéricos. Incluso si escribe código de procedimiento en F #, aún se beneficiará de la inferencia de tipos. Facilita la escritura de código genérico.

En C #, escribes código concreto de forma predeterminada y tienes que trabajar un poco más para escribir código genérico.

En F #, escribe código genérico de forma predeterminada. Después de pasar más de un año de programación tanto en F # como en C #, encuentro que el código de biblioteca que escribo en F # es más conciso y más genérico que el código que escribo en C # y, por lo tanto, también es más reutilizable. Pierdo muchas oportunidades para escribir código genérico en C #, probablemente porque estoy cegado por las anotaciones de tipo obligatorias.

Sin embargo, hay situaciones en las que es preferible usar C #, según el gusto y el estilo de programación de cada uno.

• C # no impone un orden de declaración entre tipos y no es sensible al orden en que se compilan los archivos.
• C # tiene algunas conversiones implícitas que F # no puede permitirse debido a la inferencia de tipos.