f# - mes - frases en frances
Si ya conoce LISP, ¿por qué también querría aprender F#? (11)
Comparar Lisp directamente con F # no es realmente justo, porque al final del día con suficiente tiempo podrías escribir la misma aplicación en cualquier idioma.
Sin embargo, debe aprender F # por las mismas razones por las que un desarrollador C # o Java debe aprenderlo, ya que permite la programación funcional en la plataforma .NET . No estoy 100% familiarizado con Lisp, pero supongo que tiene algunos de los mismos problemas que OCaml en cuanto a que no hay soporte de biblioteca estelar. ¿Cómo se hace el acceso a la base de datos en Lisp? ¿Qué hay de los gráficos de alto rendimiento?
Si desea obtener más información sobre ''Why .NET'', consulte esta pregunta .
¿Cuál es el valor agregado para aprender F # cuando ya está familiarizado con LISP?
Dado que LISP está tipeado dinámicamente y F # está tipado estáticamente, encuentro tales comparaciones extrañas.
Dinero. El código F # ya es más valioso que el código Lisp y esta brecha se ampliará muy rápidamente ya que F # ve una adopción generalizada.
En otras palabras, tienes muchas más posibilidades de obtener un ingreso estable usando F # que usando Lisp.
Saludos, Jon Harrop.
F # es un lenguaje muy diferente en comparación con la mayoría de los dialectos Lisp. Así que F # te da un ángulo de programación muy diferente, un ángulo que no aprenderás de Lisp. La mayoría de los dialectos Lisp se utilizan mejor para el desarrollo incremental e interactivo del software simbólico. Al mismo tiempo, la mayoría de los dialectos Lisp no son lenguajes de programación funcional, sino más bien idiomas multi-paradigma, con diferentes dialectos que tienen diferente peso en las características FPL de apoyo (sin efectos secundarios, estructuras de datos inmutables, tipos de datos algebraicos, ...). Por lo tanto, la mayoría de los dialectos Lisp carecen de tipado estático o no le dan mucho énfasis.
Entonces, si conoces algún dialecto Lisp, entonces aprender F # puede tener mucho sentido. Simplemente no crea que gran parte de su conocimiento de Lisp se aplica a F #, ya que F # es un lenguaje muy diferente. Por mucho que una programación imperativa utilizada para C o Java necesite desaprender algunas ideas al aprender Lisp, también se necesita desaprender los hábitos de Lisp (sin tipos, efectos secundarios, macros, ...) cuando se usa F #. F # también es impulsado por Microsoft y aprovecha el framework .net.
F # tiene el beneficio de que el desarrollo de .NET (en general) es ampliamente adoptado, de fácil acceso y más mercado masivo.
Si desea codificar F #, puede obtener Visual Studio, que muchos desarrolladores ya tendrán ... en lugar de poner en marcha el entorno LISP.
Además, es mucho más probable que los desarrolladores .NET existentes miren F # que LISP, si eso significa algo para ti.
(Esto viene de un desarrollador de .NET que codificó, y amó, a LISP, mientras estaba en la universidad).
No estoy seguro si lo harías? Si encuentras F # interesante, esa sería una razón. Si tu trabajo lo requiere, sería una razón. Si crees que te haría más productivo o te aportaría un valor agregado sobre tu conocimiento actual, esa sería una razón.
Pero si no encuentras interesante F #, tu trabajo no lo requiere y no crees que te haga más productivo o te aporte un valor agregado, ¿por qué lo harías?
Si, por otro lado, la pregunta es qué F # le otorga a lisp, entonces debe considerarse la inferencia de tipos, la coincidencia de patrones y la integración con el resto del framework .NET.
Sé que este hilo es viejo, pero desde que tropecé con este, solo quería comentar mis razones. Estoy aprendiendo F # simplemente por oportunidades profesionales ya que .NET tiene mucho peso en una categoría de compañías que dominan mi campo. El paradigma funcional ha estado creciendo en uso entre las empresas más orientadas cuantitativamente y de datos y me gustaría ser uno de los primeros en llegar a esta tendencia. Actualmente no existe un lenguaje funcional sólido que se integre de manera completa y segura con la biblioteca .NET. De hecho, traté de portar algo de .NET desde el código Lisp y es realmente una b / c dolorosa, el FFI solo admite primitivas C y la interoperabilidad .NET requiere una construcción de ''interfaz'' y aunque sé cómo hacerlo en C, es realmente un enorme dolor. Sería realmente, realmente, bueno si Lisp hiciera un esfuerzo adicional en su próximo estándar y necesitara una clase de c ++ (incluidas funciones virtuales con tablas virtuales), y un tipo de interfaz de estilo C # en su FFI. Tal vez incluso incluir un estilo de estilo de interfaz Java. Esto permitiría una interoperabilidad completa con la biblioteca .NET y haría de Lisp un fuerte contendiente como un lenguaje a gran escala. Sin embargo, dicho esto, venir de un fondo Lisp hizo que aprender F # fuera fácil. Y me gusta cómo F # ha hecho un esfuerzo adicional para proporcionar tipos que comúnmente verías como un trabajo de tipo cuantitativo. Creo que F # se creó con el trabajo matemático en mente y que en sí mismo tiene valor sobre Lisp.
Si estuviera cambiando de Lisp a F #, sería únicamente porque tenía una tarea en mis manos que se benefició enormemente de alguna biblioteca .NET-only.
Pero yo no, entonces no lo soy.
Si supiera F # y Lisp, le parecerá una pregunta bastante extraña.
Como otros han señalado, Lisp se tipea dinámicamente . Más importante aún, la característica única de Lisp es que es homogéneo: el código Lisp es un tipo de datos fundamental de Lisp (una lista). El macro sistema aprovecha esto al permitirte escribir código que se ejecuta en tiempo de compilación y modifica otro código .
F # no tiene nada como esto: es un lenguaje estáticamente tipado que toma prestadas muchas ideas de ML y Haskell, y lo ejecuta en .NET
Lo que estás preguntando es similar a "¿Por qué tengo que aprender a usar una cuchara si sé cómo usar un tenedor?"
Una forma de ver esto (la pregunta original) es hacer coincidir el idioma (y las herramientas y plataformas asociadas) con la tarea inmediata. Si la tarea requiere un porcentaje abrumador de código .NET, y requeriría menos habilidad en un idioma que otro para cumplir con la tarea de frente, entonces tome el camino de menor resistencia (F #). Si no necesita las capacidades de .NET, y se siente cómodo trabajando con LISP y no hay que inclinarse para alejarse de él, continúe usándolo.
No es muy diferente de comparar un martillo con una llave inglesa. Elija la herramienta que mejor se adapte al trabajo. Tratar de elegir una herramienta objetivamente "mejor" es una tontería. Y en cualquier caso, en 20 años, todos los idiomas actualmente "calientes" podrían estar desactualizados de todos modos.
- Tipado estático (con tipo de inferencia)
- Tipos de datos algebraicos
- La coincidencia de patrones
- Combinación de patrones extensible con patrones activos.
- Currying (con una buena sintaxis)
- La programación de Monadic , llamada ''workflows'', proporciona una buena manera de hacer una programación asincrónica.
Muchos de estos son desarrollos relativamente recientes en el mundo del lenguaje de programación. Esto es algo que verá en F # que no verá en Lisp, especialmente Common Lisp, porque el estándar F # aún está en desarrollo. Como resultado, encontrará que hay mucho que aprender. Por supuesto, cosas como los ADT, la coincidencia de patrones, las mónadas y el currying se pueden construir como una biblioteca en Lisp, pero es mejor aprender a usarlos en un lenguaje en el que estén convenientemente integrados.
La mayor ventaja de aprender F # para el uso en el mundo real es su integración con .NET.