2008-09-27 14 views

Respuesta

19

Iré por Haskell. HackageDB es una gran colección de bibliotecas escritas específicamente para el idioma. En el caso de F #, tendría que utilizar principalmente bibliotecas que no están escritas con un lenguaje funcional en mente, por lo que no serán tan "elegantes" de usar. Pero, por supuesto, depende en gran medida de la cantidad de programación funcional que desea hacer y las limitaciones del proyecto que desea utilizar. Incluso 'propósito general' no quiere decir que se debe utilizar en todos los casos;)

8

depende de lo que desea hacer:

Haskell es el idioma más puramente funcional de los dos.

F # es más un lenguaje híbrido, y no es puramente funcional, pero tiene un gran conjunto de bibliotecas de clases base que puede usar para hacer cosas modernas fácilmente en Windows o Mono.

+0

F # también funciona en Mono. – TraumaPony

+1

Pero eso es con una plataforma diferente, él no merece un voto negativo. – Rayne

+0

F # es un lenguaje para la CLI; por lo tanto, es la misma plataforma. – TraumaPony

9

Yo diría F #, ya que puede acceder a todo el framework .Net. Sin embargo, eso es más una cosa de la biblioteca.

2

Yo diría que depende de por qué lo estás aprendiendo. Si lo hace por la experiencia de un lenguaje funcional puro, vaya por Haskell. Pero si definitivamente va a utilizar el idioma por más que eso, F # podría ser la mejor opción.

4

Usted puede encontrar esta entrada del blog de Neil Mitchell informativo:

F# From a Haskell Perspective

Los comentarios también son esclarecedores.

+1

Neil comienza afirmando que él sabe muy poco acerca de ML y luego dibuja varias comparaciones erróneas entre F # y ML, concluyendo que F # hereda sus defectos de ML. Eso es una tontería sin valor. Si quieres saber acerca de ML, pregúntale a alguien que sepa ML (es decir, no Neil). –

25

Prefiero Haskell.

La afirmación de Jon Harrop de que Haskell tiene herramientas deficientes me hizo pensar un poco, ya que no estoy de acuerdo con esto. Creo que el problema aquí es en parte uno de estilo de desarrollo. Vamos a comparar algunas características relacionadas con herramientas de-F # y GHC:

  1. F # tiene amplias herramientas visuales y GHC no tiene ninguno. Para mí, la falta de herramientas visuales es irrelevante: trabajo con vi, una línea de comando de Unix y un sistema de compilación muy personalizado. La falta de apoyo para mi estilo de desarrollo en F # sería muy difícil para mí. Por otro lado, si prefiere trabajar en un entorno de tipo Visual-Studio, tendría la opinión inversa.

  2. F # y/o .NET Entiendo que tiene un depurador muy bueno. GHC solo tiene un depurador limitado que se ejecuta en el intérprete. No he usado un depurador en años (gran parte de esto debido al uso de desarrollo basado en pruebas) y cuando trabajas principalmente con funciones puras, como en Haskell, un depurador es mucho menos necesario. Entonces, para mí, la falta de esta herramienta es bastante irrelevante.

  3. Bibliotecas. Esto depende principalmente de las bibliotecas que necesita, ¿no? Muchos de los buenos no ayudan si el que necesita no está allí, y tener muchas bibliotecas mal diseñadas puede no ser tan útil. Haskell ciertamente tiene menos librerías que .NET, pero tiene una selección razonable, y la calidad del diseño API en muchas de ellas es muy, muy alta.

No sé qué interfaz F # 's en las bibliotecas de código nativo es similar, pero GHC es ideal para esto, por ese estupendo FFI. Escribí un servidor Windows DDE en su totalidad en Haskell (sí — no una línea de C, ni siquiera para hacer frente a las devoluciones de llamada a partir de las bibliotecas de Windows C) y tardó mucho menos tiempo y era considerablemente más simple que hacer lo mismo en C o C++. Si necesita interfaces de código nativo, Haskell es sin duda la mejor opción.

El "imprevisibilidad" de uso de la memoria y el rendimiento es un buen punto. Haskell me parece razonablemente predecible si sabes lo que estás haciendo, pero no sabrás lo que estás haciendo cuando comiences, y tendrás mucho que aprender. F # es mucho más similar a otros lenguajes .NET.

En general, esta pregunta probablemente se deba más a la plataforma que al idioma: la enorme diferencia entre el "mundo Unixy" de GHC generando código nativo y el "mundo Windowsy" de F # ejecutándose en .NET no es un problema de lenguaje .

+2

Todos los puntos justo. Sin embargo, creo que Windows Presentation Foundation es un contraejemplo obvio en el contexto de las bibliotecas: está mucho mejor diseñado y es más poderoso que cualquier otro disponible de Haskell (por ejemplo, Qt). También aconsejaría a los usuarios técnicos que consideren seriamente cambiar de plataforma solo para usar F #. Yo prefiero Linux a Windows .NET, pero es sólo muy por delante de cualquier cosa disponible en Linux o Mac OS X ahora ... –

+2

"No sé qué interfaz F # 's en las bibliotecas de código nativo es similar, pero ... Si necesitas interfaces de código nativo, Haskell es sin duda la mejor opción ". Suena injustificado –

6

creo que Jon Harrop tiene un bajón serio en Haskell por alguna razón. Simplemente no es cierto que no se use fuera de la academia, de hecho, se usa ampliamente en banca de inversión y mucho más que F # y OCaml, y por una buena razón. Si desea una programación funcional de trabajo, aprenda Haskell ya que hay muchos más anuncios anunciados para programadores de Haskell que F # o OCaml. Estoy seguro de que F # ganará popularidad, ya que tiene a Microsoft detrás y está comenzando desde cero, pero por el momento Haskell tiene una clara ventaja.

Probablemente hace 2 o 3 años, OCaml lideró el campo en prácticos lenguajes funcionales, pero desde entonces Haskell lo ha superado con más bibliotecas, más funciones, mejor rendimiento y un uso comercial más amplio.

+0

"Creo que Jon Harrop tiene una decepción seria con Haskell por alguna razón". Tengo una decepción en mierda. "... es ampliamente utilizado en banca de inversión y mucho más que F # y OCaml son y por una buena razón". Mierda como esa. –

+1

"OCaml lideró el campo en prácticos lenguajes funcionales, pero desde entonces Haskell lo ha superado con más bibliotecas, más funciones, mejor rendimiento y un mayor uso comercial". Más bibliotecas, sí. Más características, tal vez. Mejor rendimiento, de ninguna manera. Uso comercial más amplio, ¿dónde está el equivalente Haskell de XenSource (recientemente vendido a Citrix por $ 500,000,000)? –

Cuestiones relacionadas