.net - what - F#vs IronPython: ¿Cuándo se prefiere uno al otro?

ironpython c#

Question

Si bien los idiomas F # e IronPython son técnicamente diferentes, en mi opinión hay una gran superposición entre sus usos potenciales. ¿Cuándo es uno más aplicable que el otro?

Hasta ahora me parece que F # es computacionalmente más eficiente, mientras que IronPython hereda una mejor biblioteca de Python. Estoy feliz de ser corregido.

Hay una pregunta algo relevante es F # a IronPython / IronRuby como C # es para VB.NET? pero la mayoría de las respuestas son acerca de los paradigmas del lenguaje en lugar de su aplicabilidad real.

Edición : supongo que debería agregar un poco más de fondo. Tengo una buena experiencia con Python en general, y acabo de aprender F # después de algunos pasos de programación funcional vacilantes antes, principalmente en Erlang. Actualmente me siento capaz de continuar usando Python o F # en el futuro. Me gustaría decidir cuál debo usar y dónde. Por ejemplo:

1. Python tiene muy buenas estructuras de datos como parte de la biblioteca estándar. El otro día necesitaba un equivalente del módulo de heap de Python y no está disponible en la biblioteca estándar de F # / .net. Punto para IronPython.
2. F # se puede usar para construir bibliotecas más convenientes, más fácil de acceder desde otros lenguajes .Net. Así que para una biblioteca residente en .Net preferiría F #.
3. Desarrollo multiplataforma. IronPython es mejor aquí. F # / Mono es utilizable es un conjunto mucho más pequeño de plataformas y la compatibilidad con F # / OCaml no es fácil de mantener, especialmente en términos de bibliotecas.
4. El shell interactivo IronPython me parece más fácil que fsi. YMMV.

Entonces, la pregunta se reduce a: ¿hay alguna razón, aparte de una preferencia de un paradigma a otro o de algunas preferencias de equipo o corporativas, que te haga elegir F # en lugar de IronPython o viceversa? ¿Suponiendo que tiene la misma confianza en ambos? ¿O son exactamente equivalentes para todos los propósitos prácticos?

Edit : Ok, chicos, parece que han juzgado esto como una pregunta estúpida, votándola abajo y las respuestas. Pero al menos es honesto. Así que por favor sólo una pista. ¿Es imposible diferenciar entre los dos o estoy entrando en algún tabú secreto al hacer esta pregunta? Si parece un troll, ¿puede alguien informarme?

Answer 1

Entonces, la pregunta se reduce a: ¿hay alguna razón, aparte de una preferencia de un paradigma a otro o de algunas preferencias de equipo o corporativas, que te haga elegir F # en lugar de IronPython o viceversa? ¿Suponiendo que tiene la misma confianza en ambos? ¿O son exactamente equivalentes para todos los propósitos prácticos?

Como suele ser el caso, "depende de lo que estés haciendo". Pero como preguntaste, comienza aquí:

Diversidad de conjunto de herramientas

Desde mi punto de vista, IronPython es esencialmente lo mismo que C # con una sintaxis un poco diferente, lo sé, es una generalización generalizada para dos idiomas con sistemas de tipo completamente diferentes, pero no hay mucho más que pueda decir sobre otro imperativo , OO idioma. Ya sea C #, o Java, o C ++, o Python, usted resuelve los idiomas usando aproximadamente las mismas técnicas, expresiones idiomáticas, estrategias, estilo, etc. Si usted es un desarrollador de .NET, casi seguramente ha trabajado con C # o VB. NET, y ya ha estado escribiendo código en un estilo imperativo durante el tiempo que ha estado usando los idiomas.

El punto más importante a favor de F # es simplemente que fomenta estilos de programación más funcionales, minimiza las abstracciones a través de la herencia de OO a favor de la composición de funciones, la inmutabilidad como un valor predeterminado en lugar de un pensamiento posterior, y así sucesivamente. Si desea escribir un código funcional, necesita utilizar un lenguaje funcional.

Por supuesto, puede escribir estilo funcional en C # y Python, pero las características funcionales se injertan como una idea de último momento. Python carece de lambdas multilínea, y C # es demasiado detallado y ocasionalmente buggy para hacer uso del estilo funcional en los lugares donde se desea usar, C # en particular tiene un montón de errores relacionados con delegados y captura de variables locales, ambos idiomas carecen de cola. optimizaciones de llamadas en casi todos los lugares donde querría usarlas, la inferencia de tipos de C # es una broma en comparación con F #. He intentado usar C # como un lenguaje funcional con resultados hilarantemente malos :)

Ahora la mayoría de las personas pueden admitir que los problemas dificultan, pero no es imposible, programar en un estilo funcional utilizando C # o Python. Sin embargo, en mi experiencia, no son los idiomas que lo hacen imposible, son los programadores en su equipo. Si tienes 10 o 12 personas escribiendo código en un idioma imperativo, no podrás aplicar un estilo funcional por mucho tiempo: los idiomas no hacen nada para desalentar el estilo imperativo. Y como los programadores ya codifican en ese estilo, eso es lo que obtienes. A menos que tenga en su equipo a algunos entusiastas de la FP realmente duros y ligeramente masoquistas, no creo que pueda imponer un estilo de programación puramente funcional en un lenguaje imperativo durante mucho tiempo.

El mejor argumento a favor de F # no es necesariamente la programación funcional en sí misma, sino la diversidad de su conjunto de herramientas. Obtiene un emparejamiento de retorno de la inversión más grande hasta F # y C # (paradigma de programación diferente y sistema de tipo similar) que emparejar IronPython y C # (mismo paradigma de programación y sistema de tipo diferente).

Estudio de caso de mi empresa

Ok, entonces dicho esto, he estado tratando de presionar F # en mi compañía. No entraré en una gran cantidad de detalles sobre lo que hacemos, pero básicamente mi equipo guía a los usuarios a través del proceso de pedido de servicios de cable y teléfono para compañías como Time Warner, ComCast y otros proveedores de cable.

Es realmente un proceso más complicado de lo que parece. Para empezar, hay un motor de reglas complicado que determina la disponibilidad de productos, dependencias y exclusiones entre productos, etc. Caminamos por el gráfico del motor de reglas y construimos un árbol de decisión, luego le entregamos el árbol a un cliente para que puedan mostrarlo al usuario y recopilar información del usuario, la GUI de los mapas del cliente de nuevo a nuestra estructura de árbol de decisión, recorremos el árbol y validamos todo contra el motor de reglas, etc.

Yo diría que el 95% de nuestro código es simplemente navegar, manipular y procesar estructuras de datos tipo árbol. En este momento, todo lo que escribimos es C # y es un desastre. Por cierto, uno de los puntos fuertes de F # es manipular los AST y el procesamiento simbólico (ver una comparación de C # y código F # para procesar AST ), y todo es posible porque la coincidencia de patrones es asombrosa.

La coincidencia de patrones es una función realmente asesina, es exactamente lo que necesita nuestro código C # para limpiarlo, y es por eso que necesitamos F #. No tenemos ningún uso para IronPython porque no es mejor en el procesamiento simbólico que C #.

Resumen

El paradigma de programación funcional y la coincidencia de patrones son dos características que disfruto cada día con F #. Podría ir sobre el modelo de subprocesamiento async F #, las primitivas de concurrencia de pasaje de mensajes, el soporte de mónadas, características novedosas como patrones activos, etc., pero esos son todos los comentarios de viñetas. Para mí, son esas dos características asesinas que justifican F # sobre Python, al menos para mis propios proyectos.

Answer 2

¿Cuál prefiere más (dentro de los límites de sus requisitos funcionales y políticos)? ¿Cuál requiere más inversión inicial? ¿Cuál desea mantener (inversión a largo plazo)? ¿Y cuál te ayudará a resolver tu (s) problema (s) mejor?

IronPython es, bueno, Python. Eso también significa que es considerablemente más dinámico, lo que agrega una sobrecarga de tiempo de ejecución, que F #. Si prefiere Python sobre F #, y funciona lo suficientemente rápido para usted, entonces ¿por qué no usarlo? Como mencionaste, tiene un mejor soporte de ''biblioteca Python'', así que si puedes aprovechar eso para tu ventaja, entonces anota IronPython.

Por otro lado, "solo" estar restringido a las bibliotecas .NET (y F # -friendly) realmente no es tan malo para un lenguaje como F #, siempre y cuando las bibliotecas hagan lo que necesiten o puedan ser marginadas. .

Sin embargo, realmente se reduce al paradigma , así como a la preferencia y experiencia de los desarrolladores.

Personalmente evito los lenguajes dinámicos donde puedo :-)

Answer 3

La interpretación dinámica de Ironpython brilla como una alternativa a la sintaxis javascript monótona en los agentes de usuario del navegador del cliente. La comprobación de tipos estática de F # que cubre los tipos personalizados permite SI, o cualquier biblioteca portátil del sistema de medición, por lo que los datos de nivel de back-end de las nubes pueden remodelarla como información útil de manera más significativa. Si bien, como la mayoría de los lenguajes de programación, se pueden usar indistintamente para estas y más cosas, estas citas exhiben fortalezas separadas de las dos en las aplicaciones de los clientes. F # desempeña un papel fundamental en la aplicación compuesta, mientras que Ironpython juega un papel dentro de la interacción basada en el navegador usuario-agente.
La comprobación de tipos estáticos y las lambdas de F # podrían simplificar ASP.net en varias ocasiones orientadas a objetos más cerca del nivel de ASP clásico. Ironpython permite la extensibilidad de la aplicación mediante scripts modificables por el usuario que funcionan tan bien como extensiones de plug-in de terceros que han sido populares no solo con navegadores, sino también con reproductores de medios, y tejedores de sueños y otros editores.
Ironpython puede ser re-factorizado en partes puras de python y .net que prevén casos de uso de reutilización. Hasta ahora, F # sirve como paradigma funcional de .net, basado en el paradigma orientado a objetos.

Answer 4

La mayor diferencia entre F # e IronPython es que:

F # es un lenguaje estático

y

IronPython es dinámico.

Mientras que en niveles pequeños (por ejemplo, un script de 100 líneas), los lenguajes dinámicos y estáticos no tienen mucha diferencia. Cuando se trata de diseño de software / componentes, estos dos idiomas tienen dos patrones de pensamiento diferentes. El sistema de tipos en F # también es mucho más potente que el de Python.

Answer 5

Las dos principales diferencias entre F # y Iron Python son:

1. F # se escribe estáticamente, mientras que Iron Python no lo es.
2. La base de F # es la programación funcional, mientras que la base de Iron Python es la programación orientada a objetos. (Con ambos teniendo un buen soporte para otros paradigmas.)

Estas son diferencias relativamente importantes y conducen directamente a las principales razones prácticas para preferir una sobre la otra.

Como dijiste, Iron Python es más lento que F # debido a la falta de escritura estática. En los puntos de referencia del lenguaje informático, Iron Python es 25x en la mediana y 120x más lento en el peor de los casos. Entonces, si el rendimiento en tiempo de ejecución es una consideración, es probable que sea preferible F #.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ironpy&lang2=fsharp

Como ambos son .NET, cada uno puede usar las bibliotecas de la otra con solo un poco de trabajo. Así que no veo esto como un problema importante, aunque supongo que es posible utilizar SciPy en IronPython, mientras que sería tedioso desde F #, y la biblioteca gratuita correspondiente mejor para F # no es tan buena.

La programación funcional puede ser un estilo muy poderoso, y permite que F # tenga algunas características poderosas como flujos de trabajo, incluyendo flujos de trabajo asíncronos que están bien soportados por las bibliotecas de F #. Podrías emular esas cosas aproximadamente en Iron Python, pero no funcionaría tan bien, en parte debido a la falta de soporte en las bibliotecas.

La orientación a objetos es más familiar para muchos programadores, y es posible que prefieran Python por ese motivo.

La tipificación estática también permite que un IDE brinde un mejor soporte a los programadores. El tipo de cada variable se puede informar al programador (mediante el desplazamiento en VS), y se puede proporcionar información sobre los errores mientras se edita el código. Como profesor universitario, puedo decir que esta retroalimentación inmediata es extremadamente útil para mis alumnos mientras aprenden F #. Esto les permite administrar programas más complejos de lo que podrían hacerlo.

La escritura dinámica a veces permite que los programas pequeños y simples se escriban un poco más rápido. Si esta es la única codificación que estará haciendo, entonces Python puede ser preferible. Pero, si existe la posibilidad de que un programa crezca en algo más grande, entonces preferiría F #.