Todos escuchamos de películas, juegos, libros o composiciones musicales icónicas que son elogiadas con vehemencia por la comunidad de sofisticados, profesionales y críticos, pero que nunca parecen atraer el éxito comercial tangible o la atención de una audiencia más amplia. Tales situaciones me dejan profundamente frustrado.
Cuando se trata de desarrollo, la buena tecnología también a veces nunca entra en el centro de atención. Tome F # por ejemplo. Todo lo que sé es que es un lenguaje súper genial, pero totalmente impopular, que dificulta que los desarrolladores, al conocerlo, vuelvan a los idiomas a los que están acostumbrados.
Traté de averiguar cuál es la historia detrás de esto. De hecho, ¿quiénes son las personas que lo usan y por qué lo hacen si el idioma no tiene demanda en los negocios? Para encontrar respuestas, me uní a la comunidad F # de habla rusa en Telegram, nuestra mesa redonda para la discusión.
¿Cómo empezaste a aprender F #?
Ayrat Hudaygulov (
Szer ): Originalmente
migré aquí desde C #. Una vez tuvimos un trabajo que tenía que ver con Akka.NET, un puerto Scala de Akka. El puerto en sí estaba bien, pero carecía de ejemplos de casos raros en el manual del usuario, aunque siempre se proporcionaron en el manual de Scala. Mientras leía ese manual, me preguntaba: ¿por qué solo se necesitan un par de líneas para escribirlo en Scala, mientras que me cuesta tanto hacer lo mismo en C #?
Vi la solución al cambiar a F #. Nunca tuve dudas desde entonces.
Roman Liman (
kagetoki ): Resultó que era una herramienta poderosa para resolver los problemas cotidianos reales que cualquier desarrollador puede enfrentar. Los obstáculos que solían ser vistos como la norma inevitable de OOP en el mundo de C # y Java, en realidad no son tan inevitables y pueden evitarse fácilmente en lugar de superarse.
Phil Ranzhin (
fillpackart ): Una vez leí una larga entrevista con Vagif Abilov sobre Habr. En aquel entonces simplemente no podía entender el paradigma de la programación funcional, por lo que cualquier información relacionada me molestaría seriamente. Esa entrevista no fue la excepción.
Vagif Abilov (
VagifAbilov ):
Aquí está el enlace al artículo en cuestión . Lo hice poco después de dar una charla en la conferencia DotNext en Moscú. En pocas palabras, comencé a aprender F # como un intento de hacer que mi código sea más conciso (menos código equivale a menos maldad) y utilizar estructuras de datos persistentes. Claro, nada detiene a un desarrollador de C # o Java para declarar sus estructuras de datos como persistentes, pero la capacidad de mutar estructuras de datos es una característica fundamental de los lenguajes OOP, y una que siempre será inherente a ellos. La programación funcional le ahorra el esfuerzo que generalmente se dedica a proteger los datos contra mutaciones inapropiadas en un entorno de varios subprocesos: los datos se ocuparán de sí mismos, ya que son inmutables.
Phil Ranzhin : Vagif siguió diciendo que después de C # y Java estrictamente formales, F # parecía algo mucho más favorable para el desarrollo. Entonces no sabía quién era Vagif, pero naturalmente pensé que el tipo no tenía la menor idea. C # no es demasiado formal, C # es exactamente como debería ser. Es poderoso y hermoso. Decidí escribir un artículo sobre cuán absurda era la programación funcional después de todo. Tomé un problema simple y comencé a implementarlo tanto en C # como en F # para probar mi punto. Pero mientras estaba trabajando en ello, me gustó tanto F # que abandoné el artículo. En cambio, comencé a profundizar en la tecnología.
Roman Liman : Muchas de las cosas que C # verifica en tiempo de ejecución ahora se resuelven en tiempo de compilación, por lo que se siente como jugar con la escritura estática por primera vez, una verdadera revelación.
Sin exagerarlo, donde necesita siete líneas de código en F #, necesitará 200-300 líneas para escribir el código equivalente en C # (para tener en cuenta solo el código útil). El compilador hará toda la generación repetitiva por usted, como la igualdad estructural.
Phil Ranzhin : Nunca he depurado mi código F # porque en mi código F #, todos los errores se cortan durante la compilación. No estoy bromeando.
¿Es difícil aprender F #?
Roman Liman : ¿Qué tan difícil es aprenderlo? Yo diría que no es nada difícil. Puede resultarle difícil abordarlo al principio si nunca antes ha tratado con el paradigma funcional y los tipos inmutables. Pero este problema tiene que ver con cambiar entre paradigmas, no idiomas.
La sintaxis no es obvia al principio, así que domestique su arrogancia y lea sobre este lenguaje, no espere que se salga con su conocimiento de C #.
Ayrat Hudaygulov : F # admite todo lo que C # hace, excepto goto (ya que el lenguaje está completamente basado en expresiones, parecería extraño hacer un salto imperativo en una expresión computable) y la palabra clave protegida (fue así por diseño, como aparentemente agregarlo sería obvio). El resto de todo lo que amamos de OOP: las clases abstractas, las interfaces, las propiedades implementadas automáticamente, el uso, try-catch, etc. - Todo está ahí, por supuesto. Los entusiastas del conteo de bytes también estarán satisfechos, con los parámetros de ref / out, mutabilidad, tramos, no administrado, punteros, stackalloc.
Todas las funciones de C # se agregan con un retraso de un par de años en comparación con F # (genéricos, asíncrono / espera + tarea, LINQ, coincidencia de patrones y muchos otros). Además, muchas características probablemente nunca llegarán al lenguaje (tipos de suma como uniones discriminadas, currificación de funciones nativas). Se espera que el próximo C # 8.0 se mejore con registros y coincidencia de patrones recursivos. La pregunta es, ¿por qué esperar?
Otra pregunta es: ¿por qué aprender un nuevo idioma para usarlo en las viejas formas? Para aprovechar realmente las ventajas de F # que faltan en C #, tendrás que comprender el otro lado de la Fuerza. Nadie dijo que fuera fácil.
John Doe : Como desarrollador de C #, estoy agradecido con los creadores de F # por la programación genérica y asíncrona con rostro humano en C #. Para aquellos que no sabían, esas mega características llegaron a C # gracias a F #.
Vagif Abilov : el autor del popular desarrollo pragmático recomienda que los desarrolladores aprendan un nuevo lenguaje de programación cada año. No puedo decir que me adhiera religiosamente a este consejo, pero creo que los autores realmente querían decir que los desarrolladores siempre deben estar preparados para revisar los principios en los que escriben su código.
Muchas personas veneran los lenguajes de programación como sus creencias. Algunos tratarán un cambio de Java a Clojure como una conversión del cristianismo al Islam. ¿Por qué demonios debería ser tan importante? Aprender nuevos lenguajes de programación a menudo nos dará la oportunidad de reconsiderar nuestras viejas formas de trabajar con los idiomas que ya conocemos. Familiarizarse con F # hace que las personas escriban código C # de una manera nueva.
Roman Melnikov (
neftedollar ): la parte OOP de F # es más adecuada (aunque es completamente compatible con la versión C # de OOP), ya que lo alienta a programar utilizando interfaces abstractas en lugar de clases explícitas.
¿Qué opinas de los diseñadores de este lenguaje?
Nikolay Matyushin : Una vez ayudé a presentar el soporte de proveedores de tipos de datos a .NET Core. No funcionarían durante bastante tiempo, así que, después de alistar a otro miembro de nuestra comunidad de habla rusa, decidí averiguar qué estaba exactamente mal. Después de investigar un poco, descubrimos que .NET Core carece de una función para guardar el objeto de ensamblaje en un archivo; esta función era necesaria para los proveedores de tipos.
Pasamos una o dos semanas desarrollando un prototipo que pudiera hacerlo. Armamos un truco desordenado, pero funcionó (al menos en cierta medida). Todo ese tiempo, seguimos publicando en los problemas de Github hasta que apareció Don Syme, dijo que eran "unas pocas horas de trabajo" y reparamos los proveedores de tipos.
Vagif Abilov : El diseñador de idiomas Don Syme es accesible y de mente abierta. Espero que algún día se aventure hasta una conferencia rusa para conocer a los desarrolladores rusos en persona.
Roman Liman : Syme es un genio. Es increíble que estuviera completamente solo detrás de este hermoso diseño.
Pavel Smirnov : Él es mi modelo a seguir en el mundo de la programación.
Ayrat Hudaygulov : Por cierto, Don Syme fue el que introdujo los genéricos en .NET, de lo contrario todavía estaríamos echando todo desde y hacia los objetos en C #, como era (y es parcialmente) el caso en Java. Syme hace crecer el lenguaje con una mirada hacia atrás a C #, a la compatibilidad con sus nuevas características, que probablemente sea lo correcto desde el punto de vista estratégico. Sin embargo, significa que el regusto de malas decisiones en C # también puede filtrarse en F #. También se opone a la introducción de características FP nerd (¡hola Scala!) Y a la complicación excesiva del lenguaje, ya que todo eso puede asustar a otras personas e inflar la biblioteca estándar (¡hola C ++!).
Creo que Syme es un héroe. Estoy de acuerdo con él en su visión del lenguaje como un paradigma múltiple, sin embargo, probablemente agregaría más características al lenguaje.
¿Por qué el idioma no es muy popular?
Roman Liman : Diría que el lenguaje no es popular porque FP es generalmente menos popular que OOP. Además, está la curva de aprendizaje empinada. El resto es una situación de captura 22. Pocos proyectos están codificados en F # porque el mercado carece de programadores F #, mientras que los programadores no aprenden este lenguaje porque el mercado carece de proyectos relevantes.
Phil Ranzhin : No conozco a nadie que practique la programación funcional y al mismo tiempo prefiera el modelo orientado a objetos. En ese sentido, F # es especialmente desafortunado, ya que funciona bien solo para aquellos que creen en la unión simbiótica de ambos paradigmas.
Pavel Smirnov : Muchos lo consideraron un niño nacido muerto debido a la política de Microsoft de hacer de F # solo una plataforma para jugar con funciones destinadas a C #. Sin embargo, el lenguaje originalmente estaba dirigido a la ciencia de datos más que al desarrollo industrial.
Roman Melnikov : ReSharper. Es algo esencial para C #, y muchas personas ya han invertido en él. Escribir código C # sin ReSharper es un trabajo duro, teniendo en cuenta la cantidad de configuración manual, como resaltar las asignaciones. Por lo tanto, ReSharper alivia mucho dolor en el culo para los desarrolladores de C #. F # no inflige este dolor en primer lugar, pero aquellos que usan ReSharper realmente no pueden apreciar toda la belleza de un lenguaje que no depende de las herramientas.
Vagif Abilov : En mi opinión, la razón por la que va a la zaga del éxito de Scala radica en la posición dominante de Microsoft, que aún dicta las prioridades en la plataforma Windows. A pesar de que F # se desarrolló en Microsoft Research, la compañía siempre lo ha posicionado como un lenguaje para entusiastas. Microsoft tiene sus propias métricas para la viabilidad económica de desarrollar una tecnología en particular basada en el rendimiento de ventas actual, por lo que seguramente, de acuerdo con esas métricas, proyectos como SharePoint parecen mucho más atractivos que F #. Sin embargo, pequeños golpes cayeron grandes robles.
Phil Ranzhin : Estoy seguro de que despegará. El poder de .NET combinado con la sintaxis más moderna y el concepto idiomático sin precedentes están obligados a despegar.
Roman Melnikov : El futuro parece increíblemente prometedor. F # está allanando su camino hacia el análisis de datos, gracias a los proveedores de tipos, por ejemplo. También hay compiladores js y la biblioteca magic elmish (que en realidad es Elm para .NET).
Miguel de Icaza es un ávido defensor de F #, por lo que Xamarin siempre ha tenido el mismo nivel de soporte de F # que C #. También hay un compilador en ErlangCore, que también es bastante impresionante. F # se puede usar para codificar tanto el backend como el frontend. SAFE-Stack es algo alucinante, con llamadas de API escritas, envoltorios de socket web (Elmish. Bridge) y toneladas de otras cosas.
Vagif Abilov : Me alegra saber que F # se usa en la práctica. Trabajo en un proyecto de una compañía de radiodifusión noruega en la que el sistema carga archivos multimedia de televisión y radio a la nube para que estén disponibles para reproducirlos desde computadoras y dispositivos móviles. El sistema está escrito en F # y aprovecha Akka.NET. Este no es el único proyecto de nuestra organización en F #, y lo que es aún más prometedor es que la cantidad de dicho proyecto aumenta, al igual que la cantidad de desarrolladores dispuestos a cambiar a ese idioma.
¿Para qué sirve F #?
Phil Ranzhin : F # es perfecto para el desarrollo de IA. Este lenguaje está literalmente diseñado para separar mi mente de cualquier problema y para centrarme en las cosas importantes. Cuando trabajas en IA, tu tarea es ajustar tu mentalidad al comportamiento de la máquina. En tales casos, su código es su lenguaje intermedio que es incapaz de describir ideas que son demasiado complicadas. Pero F # es capaz de ser lo suficientemente abstracto como para que usted y su máquina puedan hacer historia.
Vagif Abilov : se puede usar para resolver cualquier problema y es especialmente bueno para el diseño basado en dominios. En mi entrevista del año pasado sobre Habr, fui tonto al afirmar que los lenguajes funcionales eran aplicables a algoritmos y backend en mayor medida de lo que eran aplicables a la programación de interfaces de usuario y páginas web.
Luego, alguien mencionó en la sección de comentarios que había un lenguaje funcional Elm que fue diseñado específicamente para programar páginas web. La persona que dejó el comentario tenía toda la razón. Desde entonces, comencé a usar Fable que permite escribir aplicaciones web en F # y compilarlas en JavaScript. El efecto fue sobresaliente: la combinación de F # más Fable (y la biblioteca Fable-Elmish) abre el acceso a la programación web para desarrolladores con desafíos CSS como yo.
Pavel Smirnov : Desarrollo basado en datos: es un lenguaje FP conciso con el soporte de type. Su modelo de actor MailboxProcessor, como parte de la biblioteca estándar, es una delicia.
Roman Melnikov : resuelve problemas web perfectamente y se integra bien con componentes de reacción. Resuelve problemas de análisis de datos y aprendizaje automático (fslab.org), problemas de ETL, problemas de diseño de lógica de negocios: su sistema de tipos permite codificar de tal manera que se eviten estados incorrectos.
Funciona muy bien para el análisis (Fparsec). Es genial para diseñar e interpretar tus propios idiomas. Simplemente tome TypeScript: originalmente se escribió en F #. Se puede usar para escribir código GPU.
Yo mismo uso F # en lugar de bash y Python para codificar scripts fsx para mi computadora.
Es cierto que no puede usarlo para programar microcontroladores. Pero supongo que bastantes personas pueden prescindir de esto.
Dónde obtener información
Libros
Internet
Telegrama
fsharp_news
fsharp_chat
Una breve descripción de la comunidad.
Roman Liman : La comunidad es fabulosa: está impulsada por el deseo de codificar en F # comercialmente, por lo que los novatos son bienvenidos y se les ofrece un gran apoyo en un intento por hacer crecer la comunidad y aumentar las posibilidades de los miembros de encontrar trabajo.
Phil Ranzhin : ¡Esos peligrosos seguidores de culto! Pero tienen razón.
Pavel Smirnov : La comunidad F # de habla rusa es un lugar agradable. Lo que más me gusta es que realmente se preocupan por su idioma favorito, al igual que las personas en otros ecosistemas más conocidos.
Nikolay Matyushin : Eso es probablemente porque el idioma no es muy popular, por lo que las personas tóxicas no se quedan.
Roman Melnikov : La comunidad tiene una gran cantidad de dramas que no afectan el lenguaje en sí pero que hacen la vida más emocionante.