¿A quién debo preguntar sobre F #, si no es una persona que ha dedicado un sitio web detallado a este idioma?
Scott Vlashin creó el recurso
"F # para la diversión y el beneficio" , familiar para muchos residentes de Habra: de Habré tradujeron una
serie de artículos "Pensamiento funcional" y
un artículo "Programación orientada al ferrocarril".
Y en noviembre, hablará en nuestra conferencia DotNext en Moscú con el
informe "El poder de la composición". Y en anticipación de este discurso, le preguntamos sobre F # y la programación generalmente funcional.
- Vayamos desde el principio: ¿qué hiciste antes de la programación funcional, cómo llegaste a F # y cómo creaste el sitio?- Soy un hombre de edad venerable, y cuando estaba en la universidad, todavía no había programas de informática por separado. Recibí una educación matemática, pero no quería hacer matemáticas, así que después de la universidad trabajé durante unos 10 años en una variedad de trabajos, incluido un carpintero.
Un buen día a fines de la década de 1980, mi padre compró una computadora, CP / M Kaypro, con una pequeña cantidad de memoria y disquetes de 5,25 pulgadas para su trabajo. Esto fue antes de que apareciera Windows, por lo que DOS se puso de pie sobre él. Fue allí donde comencé a programar. Estaba involucrado en bases de datos, al principio para mi padre, él necesitaba esto para su trabajo. Y luego comencé a hacerlo profesionalmente.
Mi primer idioma fue Turbo Pascal, y en 1989 o 1990 conocí a Smalltalk, y realmente me gustó, sigue siendo uno de mis idiomas favoritos. Un trabajo reemplazó a otro, y al final, como la mayoría de los programadores, conseguí un trabajo en una gran empresa para escribir aplicaciones de negocios aburridas (los llamo "BLOB": aplicaciones de línea de negocios aburridas). Y durante mucho tiempo estuvo haciendo exactamente eso.
Durante un tiempo escribí en Python, unos 10 años, en C #. Y en 2011, es decir, no hace mucho tiempo, decidí que estaba cansado de mi trabajo y que sería bueno probar algo nuevo; entonces quería hacer programación funcional. Resultó que mi Visual Studio ya tenía un lenguaje funcional, así que traté de entender F #. Y al principio parecía muy extraño, no podía entender nada, era muy diferente de todo lo que trabajé antes.
Había varios buenos blogs en F #, pero había muy pocos y tampoco había suficiente documentación. Como resultado, mis amigos me dieron excelentes consejos: si quieres estudiar algo correctamente, trata de comenzar a enseñar a otros sobre esto, porque te hace comprender muy bien el tema. Además, me aconsejaron comenzar un blog, esto me permite destacar entre otros programadores.
En general, en 2012 comencé el blog "F # por diversión y ganancias" y comencé a publicar artículos cada vez que aprendía algo nuevo sobre F #. Ahora hay varios cientos de páginas, y ha ganado gran popularidad. Al principio era solo un hobby, trabajé en ello en mi tiempo libre. Y hace unos 3 o 4 años, decidí dejar mi trabajo y convertirme en consultor independiente. El año anterior, escribí un libro, que también resultó ser bastante popular. Y así se conoció a F #.
- ¿Cómo trabajas como profesional independiente con F #, o no solo?- Básicamente, F #, aunque en términos generales, lo que pagarán, es por eso que les aconsejo
* risas * . Si necesito dinero, pero alguien tiene trabajo en C # y parece interesante, lo tomo. Y el año pasado, trabajé con Python durante tres meses. Lo que me importa no es el lenguaje, sino qué problema en particular tiene que resolverse. Me gusta estudiar, y cuando te contratan para resolver un problema, tienes que convertirte, si no en un experto, en al menos ordenar una nueva área.
De esta manera tuve que estudiar la economía inmobiliaria y los riesgos de seguros. Creo que un buen código solo se puede escribir cuando comprendes bien el tema que estás haciendo y no solo escribes lo que otros te dicen. Para mí, este es el más interesante, no un idioma, sino un problema.
- En Rusia, aunque algunos desarrolladores tienen interés en F #, los negocios con este lenguaje son difíciles: es más difícil encontrar o reemplazar un desarrollador que con C #. Y esas empresas con las que trabaja, ¿cómo se resuelven en F #?- Hay dos situaciones más comunes. La primera opción es cuando la empresa ya usa F #, generalmente tienen algún tipo de proyecto piloto. Me llaman y me piden que los ayude a lanzar este proyecto y les enseñen el idioma. Por lo general, están listos para pasar unos seis meses en un proyecto de este tipo para averiguar si quieren continuar con esto.
Además, me dedico a enseñar a las personas diseño basado en dominios, y aquí F # no está en el centro de atención, pero lo uso como lenguaje. Le estoy mostrando a los programadores acostumbrados a C # cuánto más corto puede ser el mismo código en F # que en C #. Es decir, promuevo en silencio el lenguaje. Ayuda a que no tenga que cambiar a F # por completo, puede escribir un modelo de dominio en F # y todo lo demás en C #.
- Dices que C # y F # se pueden usar juntos. Pero en C #, el Entity Framework, NHibernate o algo similar se usa con mayor frecuencia. Y entre los desarrolladores de F # esto es mucho menos popular. ¿Cómo mezclar estos idiomas teniendo en cuenta la diferencia en los enfoques?- Una de las empresas con las que trabajé utiliza el Entity Framework. Intentaron cambiar a la arquitectura de Puertos y Adaptadores, es decir, eliminar todas las operaciones de entrada / salida del núcleo de la arquitectura. Para esto, Entity Framework es bastante malo. En tales situaciones, es mucho más conveniente usar algo como Dapper, que le permite no tratar con SQL en el medio de su código. Entre otras cosas, esto facilita las pruebas.
Deje que no usen la programación funcional, pero la situación aún los empuja a tener un núcleo limpio del programa y mantener la base de datos en algún lugar de la periferia. Si el pensamiento ha cambiado a este formato, entonces este es un paso importante para abandonar la Entidad. En una empresa así, yo, de hecho, no habría cambiado nada. No puedes obligar a las personas a cambiar; ellas mismas deben querer un cambio. No estoy tratando de venderme e imponerle a alguien la forma que creo que es la mejor. Por lo general, las personas ya quieren cambiar, y yo solo les ayudo a lograrlo. ¿Entiendes lo que quiero decir?
- Es decir, sus clientes son empresas que ya están adoptando un enfoque más funcional.- Incluso si trabajan con C #, cambian a un C # más funcional, comienzan a usar LINQ, estructuras de datos inmutables, es decir, en general, van en esta dirección. Por lo tanto, para ellos, cambiar a F # ya no es un gran salto.
¿Las profesiones de un desarrollador y un carpintero son similares?
- Tienes un hilo interesante en Twitter que compara el trabajo de un programador y un carpintero. Me gustaría preguntar sobre el "funcionalismo", a partir de este hilo. Pero, ¿puedes decir la esencia de esto para nuestros lectores?- A los desarrolladores les gusta compararse con los ingenieros y el desarrollo de software, con la construcción de edificios o puentes. Y hay mucho debate sobre si la programación está realmente cerca de estas actividades, o si son fundamentalmente diferentes. Al igual, tenemos requisitos para que el proyecto cambie todos los días: cuando construyes un puente, ¿probablemente todo está completamente mal? ¿O es realmente así también?
Pero creo que en esta disputa no hay una única respuesta correcta. Nunca he sido ingeniero, pero fui carpintero. Y puedo decir que los carpinteros tienen muchos trabajos diferentes, muy diferentes en formato, y cada uno necesita su propio enfoque.
Por ejemplo, en uno de los trabajos hice gabinetes de cocina. En Estados Unidos, todos están muy estandarizados, todos del mismo tamaño, adaptados entre sí, y se está trabajando con herramientas eléctricas. Es necesario proporcionar algo de calidad, pero en Estados Unidos, la vieja cocina generalmente se desecha cuando la casa cambia de dueño, es decir, no servirá durante mucho tiempo. Entonces, en este trabajo, todo está relacionado con la velocidad y el ahorro de costos.
Luego tuve otra tarea, donde necesitaba reemplazar una gran viga de roble de 6 pulgadas en el centro de la habitación del edificio, que tenía entre 400 y 500 años. Aquí todo era lo contrario: todo era curvo, sin ángulos rectos, y para reemplazarlo, era necesario colocar manualmente una nueva pieza de madera para que tuviera exactamente la misma forma que la anterior. Esto requirió mucha precisión.
Finalmente, hubo el tercer trabajo en el que hice el escenario para el escenario. Estaban hechos de madera contrachapada y madera muy delgada para accesorios.
Mi idea es que cada trabajo requiere su propio enfoque. En el caso de los gabinetes de cocina, se necesita precisión, el uso de herramientas eléctricas y resultados reproducibles. En una vieja casa de madera que trabajas con un sistema heredado, es importante tener cuidado, no apresurarte, no necesitas velocidad, sino la exactitud del resultado. Finalmente, en el caso de las decoraciones, crea deliberadamente una estructura frágil que no tiene que ser fuerte, a menudo tiene que cortarla y ensamblarla nuevamente en unos minutos, tales estructuras no duran para siempre.
Cuando dicen que la programación es similar a la ingeniería, esto es cierto solo para ciertos tipos de programación. Por ejemplo, si escribe software que controla un avión, debe tener mucho cuidado y lograr una precisión muy alta. Una cosa completamente diferente es un script de una línea para buscar archivos, esto es más como crear escenarios. No tiene sentido gastar 20 horas demostrando que este script funciona y escribiendo 1000 pruebas unitarias para él. Todo el trabajo no debe tomar más de 5 minutos. Y cuando trabaja con un sistema heredado, necesita ajustar su código al existente tanto como sea posible, aquí no es deseable una refactorización grande.
Es decir, en cada caso, el contexto es importante. A veces necesitas planear mucho, pensar mucho en un proyecto, escribir muchas pruebas. En otros casos, es suficiente para preparar algo. Muchas personas carecen de flexibilidad a este respecto, creen que si no usa pruebas unitarias o no usa algún lenguaje de programación, entonces no es un profesional. De hecho, la idea de que todo depende del contexto es bastante obvia. Sorprendentemente, cuán tercamente algunos programadores insisten en sus ideas, y si al menos de alguna manera se desvía de sus ideales, se lo envía de inmediato a la lista negra. En mi opinión, esto es estúpido.
- Dices que para un observador externo la actividad se ve uniforme, pero cuando la ves desde adentro, se revelan casos completamente diferentes. Y quiero preguntar: ¿es lo mismo con la programación funcional? Aquellos que miran desde el exterior tienen un estereotipo común, pero en realidad hay diferencias gigantescas.Eso es correcto. Desde el exterior puede parecer que todos los "funcionarios" piensan igual, pero hay muchos grupos diferentes que discuten entre sí: partidarios de Haskell, F #, Clojure, Elm. Incluso dentro de F #, existe un fuerte desacuerdo en cuanto a la dirección en que debe evolucionar este lenguaje: si intenta imitar a Haskell o si la facilidad de uso es una prioridad. Entonces tiene razón, dentro de este campo es mucho más diverso de lo que los observadores externos usualmente lo imaginan.
- Por diferencias en el trabajo de un carpintero, dio ejemplos muy claros. ¿Puedes ilustrar las diferencias en la programación funcional con ejemplos específicos también?- Hay una escuela de programación funcional, que cree que debes intentar probarlo todo y que todo sea matemáticamente perfecto. Esta escuela usa mucha jerga matemática, por ejemplo, "monoides" o "mónadas". Estos son principalmente usuarios de Haskell, y el entorno académico es muy influyente.
Y hay personas que son más importantes para lograr resultados. No les interesan tanto las matemáticas como la inmutabilidad y la eliminación de E / S a la periferia. El mejor ejemplo de este enfoque es la comunidad Elm. Están involucrados principalmente en la creación de aplicaciones web. A diferencia del primer grupo, aquí no usan conscientemente la jerga matemática, y rechazan conscientemente la parte de la funcionalidad que está en Haskell y que los usuarios de Haskell consideran vital.
Además, existe una disputa entre los defensores de la tipificación fuerte y la tipificación dinámica. En opinión del lego, la programación funcional es algo así como Haskell o F #, pero además de ellos, hay lenguajes como Clojure que tienen una tipificación dinámica y un enfoque completamente diferente para resolver problemas. Si reúnes toda esta variopinta compañía en una habitación, pueden luchar. Creo que todos los enfoques tienen su propia razón, y cuando trabajo para alguien, no les digo que su enfoque es incorrecto.
- Muchos están asustados por la mencionada "naturaleza académica" ("F # está enraizado en ML, que es por evidencia científica rigurosa, pero aquí resuelvo problemas reales"). Pero resulta que la gente tiene miedo en vano?- En general, me parece extraño que tanta gente esté acostumbrada a considerar la academia como algo negativo. Bueno, es decir, cómo, algunos lo consideran negativo, otros, positivo.
El hecho es que muchas de las tecnologías que ahora utilizamos en la programación han surgido en el entorno académico, por ejemplo, la recolección de basura o los tipos. Así que no hay nada malo con los métodos académicos en sí. Otra pregunta es que un énfasis excesivo en ellos puede ser perjudicial, porque los científicos y los programadores tienen objetivos diferentes.
Aunque los lenguajes funcionales tienen raíces académicas, me parece la decisión correcta y consciente de ocultar esta lógica en lenguajes como F # y Elm. Por lo tanto, F # no se usa para probar teoremas, sino para resolver problemas reales, es un lenguaje muy pragmático. Y las universidades ahora han cambiado a idiomas aún más complejos, como Coq, F * y similares. Son mucho más académicos y se usan para probar teoremas.
Como dije, los científicos y programadores hacen cosas diferentes. Los programadores pasan la mayor parte de su tiempo leyendo y escribiendo archivos, trabajando con bases de datos, mostrando datos en la pantalla, verificando datos ingresados, convirtiéndolos, etc. Pero los científicos no están interesados en tales cosas. Pero el hecho es que las cosas que eran puramente académicas hace 40 años pueden no serlo hoy.
- Como usted mismo dijo en relación con el trabajo de un carpintero, diferentes enfoques son buenos en diferentes contextos, no hay enfoques universales. Y específicamente, F # también se adapta mejor a ciertas tareas. ¿Cuáles son estas tareas?- Sí, definitivamente este no es un lenguaje universal, definitivamente no recomendaría usarlo en absoluto para todos, sería estúpido. Pero me parece que F # es un excelente reemplazo para C #, con la excepción de las tareas que requieren un rendimiento muy alto. La programación en F # se basa en un enfoque completamente diferente: inmunidad, igualdad estructural, dependencias explícitas, F # no tiene valores nulos, etc. Y me parece que este enfoque es mucho más útil para resolver problemas de programación cotidianos.
Por lo tanto, si una persona usa C #, definitivamente debería preguntar sobre F #, este lenguaje ayudará a mejorar el código. En cuanto a otras áreas de aplicación, me parece que F # sería adecuado para muchas tareas para las que ahora se usa Python. F # y Python son muy similares, y me parece que F # tiene un gran potencial para el procesamiento de datos. Por el momento, todavía hay más trabajo por hacer en esta área, pero tal vez en unos pocos años la gente usará F # para varias cosas relacionadas con big data y ciencia de datos, para lo cual Python ahora se usa.
Finalmente, F # es muy conveniente para trabajar con JavaScript. En general, nadie quiere trabajar directamente con JavaScript, por lo que hay muchos lenguajes que se compilan en JS: por ejemplo, ReasonML (que se ejecuta en OCaml) y Fable (que se ejecuta en F #). Personalmente, prefiero trabajar con cualquiera de estas opciones que tratar con JavaScript, por lo que al trabajar en la interfaz, elegiría algo como Fable. Estas son las tres áreas principales en las que F # muestra su mejor lado.
- Como señaló en su informe "F # para desarrolladores de C #", lo principal en el lenguaje no es la sintaxis, sino la filosofía. Pero aquí radica la dificultad para aquellos que quieren entender rápidamente "si este lenguaje me conviene". Ya puedes entender si te gusta la sintaxis con una introducción rápida. Pero, ¿cuánto tiempo lleva comprender la filosofía del lenguaje?- Una persona que escribe en C # puede descubrir rápidamente un lenguaje como Java o Go, porque la mayoría de estos lenguajes estándar tienen aproximadamente un modelo imperativo. Pasar de ellos a F # definitivamente requiere mucho esfuerzo, y esto detiene a algunas personas. En mi experiencia, F # es mucho más fácil de aprender si por un tiempo olvidas todo lo que sabes sobre OOP. De lo contrario, comenzará a transferir todo tipo de cosas de C # a F #.
En cuanto al tiempo, en algún lugar de dos semanas de entrenamiento ya es posible comenzar a escribir código de trabajo, y tomará varios meses acostumbrarse más o menos al idioma. Finalmente, para un buen nivel de propiedad, necesita más tiempo, 6 meses, tal vez más, esto es si estamos hablando de resolver todas las bibliotecas, modismos y demás.
Pero, sinceramente, cambiar a F # no es más difícil que cambiar a Entity o WPF. También requieren mucho tiempo. No subestimes los esfuerzos necesarios, pero a veces dicen que esta transición lleva años. Repito: para comenzar a escribir código, lleva varias semanas sentirse cómodo, varios meses. Lo digo tanto por mi propia experiencia como por la experiencia de otras personas con las que hablé.
¿Necesito saber C # antes de F #?
- Está claro que la mayoría de los que usan F # provienen de C #. ¿Hay muchos que vienen a F # sin experiencia en C #?- No hay muchas personas así, y es bastante difícil para ellos, porque todas las bibliotecas tienen documentación para C #, por lo que las personas en todas partes encuentran ejemplos de C #. Pero todavía hay personas así, y además, F # se enseña en varias universidades.Hay quienes intentan aprender F # después de Python. El problema es que F # depende mucho de .NET y .NET está vinculado a C #. La misma situación con Visual Basic, también hay todos los ejemplos en C #. Esperemos que en los próximos años esta situación pueda cambiar y facilitar el aprendizaje del idioma, ahora este es uno de los problemas importantes.— C#, F#, , F# . ? LINQ , , , ?— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .
— C# , F# ?— . , . , , . , - , Python JavaScript, .
, . JavaScript , F# . , . F# — , , C#, . F# .
— F# — «F# for fun and profit»? C#?— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.
Fun and profit
— «F# » («F# for fun and profit») - , «». , -, ?— . . , F# , , . , , F#, , . F# .
- , — . , - Java . , , , . , , F# C# .
— «»: , , , .— , . , , , . .
StackOverflow , , F# , . , , , , C#. , - , , 10 . .
, , F#, F#. F#, , . , . , F# .
— , F# . ? , , F# . F# ?— , F# . , . - , . , , , . , . F# null; , ; . F# .
, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .
- . , , . , , , , , . Google Amazon — .
— , F# , — , , . ?— , . , , C# , , C#. , C#, null, , - . F# . , , , .
- - , , , . C# F#, , , . , , . , , F#, .
— , Microsoft F# ( C# ). ?— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .
, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .
— Haskell. F# — .NET-, ?— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .
Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .
— . F#, , : , , ?— , F# . , , , . , . F# , , C#. , Haskell, - , .
, , , .
F# , , . , -, .
, - , , — , ? , , , . F#, C#, , . . - , F#.
, F# , , .
DotNext «The Power of Composition». , F#: , , , . , .