¿Cuáles son los beneficios de usar C # frente a F # o F # frente a C #? [cerrado]
93
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 #?
Me parece que ya hay muchas preguntas sobre SO que responden al menos parcialmente a su pregunta. ¿Ha intentado buscar utilizando "[F #] palabra clave" en lugar de "f # palabra clave"? ("[f #] ventajas", por ejemplo)
Benjol
Respuestas:
86
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
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.
Se combinan de formas muy extrañas. Por ejemplo, puede sobrecargar el operador> en F #. Los desarrolladores de C # pueden usarlo. Sin embargo, los desarrolladores de F # no pueden. Así es, F # puede emitir sobrecargas de operador que no puede consumir.
Jonathan Allen
El enlace "este documento" está roto ...
Eduardo Brites
36
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.
Si todo lo que tienes es un martillo, todo parece un clavo. -Maslow
Charlie Salts
20
No voy a votar esto porque no da ningún detalle real excepto por el ejemplo de un dato. Sé que son herramientas diferentes. Estoy preguntando en qué trabajos son mejores y peores estas dos herramientas en comparación entre sí. Sé que un philips es a menudo la mejor herramienta para el trabajo, aunque un cabezal plano más pequeño funcionará.
gradbot
3
Si él no te vota, lo haré. : P +1
Spencer Ruport
14
Si todo lo que tienes es un martillo, todo parece un pulgar.
Ed Power
6
Estoy de acuerdo con Gradbot, esta es una buena respuesta, por lo tanto, no tengo ningún voto negativo, sin embargo, no llega a los detalles de las preguntas originales. Esta respuesta es solo una vaga explicación conceptual, pero realmente pierde el sentido de responder la pregunta exactamente.
@Joh: inlinees un ejemplo obvio de algo que puede proporcionar mejoras de rendimiento masivas en F # que C # no puede expresar.
JD
@Jon Harrop: Me refería específicamente a la entrada del blog de Rinat. Parece que los tiempos a favor de F # que obtuvo se debieron a un código C # subóptimo.
Joh
27
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.
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.
Aunque creo que su respuesta general es correcta de que la pregunta real es sobre la comparación de paradigmas de programación y no lenguajes, siento que la respuesta en la pregunta a la que se refiere es un poco superficial.
Jeroen Huinink
No dude en sugerir otra pregunta si tiene una mejor. Ese es el mejor calificado que encontré en una búsqueda en Google.
Spencer Ruport
1
Creo que estaba tratando de ser amable con que suenas como un idiota por decir que F # no requirió mucho esfuerzo por parte de Micrsoft.
Matthew Whited
+1 para comentario de base de mercado. Simple y tiene algo de verdad.
gradbot
1
No creo en ese otro enlace que responde a mi pregunta. C # admite muchas construcciones funcionales en versiones más recientes.
gradbot
5
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 #.
-1. F # es un lenguaje de múltiples paradigmas (OO + FP). Solo los lenguajes puramente funcionales no tienen efectos secundarios (como Haskell), pero F # no es puro.
Mauricio Scheffer
5
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.
+1, esta puede ser la cruda verdad, sin embargo, todavía estoy bastante feliz de poder usar un lenguaje funcional en VS con .NET
gradbot
1
Estoy de acuerdo en que Nullable <T> debería hacer que el compilador haga un alias mágico por nosotros. No estoy seguro de que hacer que "Algunos nulos" sea equivalente a Ninguno siempre funcione; algún código de interoperabilidad podría depender de él. ¿Pero referencia nula? ¿Cómo va a solucionar un gran agujero en .NET? ¿Envolver cada tipo de referencia en una opción? En la práctica, esto solo parece ser un problema con ciertos escenarios de interoperabilidad.
MichaelGG
12
FWIW, he estado codificando profesionalmente en F # durante varios años (más que casi cualquier otra persona en el mundo) y nunca he visto este problema o el código Some nullen ningún código F # en ningún lugar. De todas las cosas por las que la gente puede quejarse, esto tiene que estar muy abajo en la lista ...
JD
1
Comparar F # con C ++ es un poco inverosímil. Muchas partes de C ++ tienen una semántica no definida o poco clara, F # es simple y está bien definido. La calidad del tiempo de ejecución de .NET no se puede comparar con F #, ya que cualquier lenguaje .NET tendrá los mismos problemas.
Joh
1
En más de 2 años de programación profesional en F #, como @Jon, nunca he visto ningún problema relacionado con 'Some null'. Por otro lado, me he beneficiado enormemente de las características del marco .Net.
Marc Sigrist
5
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.
Respuestas:
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 grandeIntegració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.
fuente
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.
fuente
fuente
inlinees un ejemplo obvio de algo que puede proporcionar mejoras de rendimiento masivas en F # que C # no puede expresar.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 #?
fuente
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.
fuente
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 #.
fuente
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.
fuente
Some nullen ningún código F # en ningún lugar. De todas las cosas por las que la gente puede quejarse, esto tiene que estar muy abajo en la lista ...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.
fuente