Hola a todos!
Recientemente, se celebró en Novosibirsk el próximo C ++ Siberia 2019. La conferencia tuvo un ambiente acogedor y muchos buenos informes. Aproveché esta oportunidad para hablar con dos de nuestros oradores, a quienes pronto podrán ver en Moscú.
Ivan Chukic es uno de los desarrolladores de KDE, profesor e investigador del diseño de lenguajes de programación en la Universidad de Belgrado.
Alexander Granin ( graninas ) es un conocido orador y desarrollador especializado en FP, el organizador de la comunidad de FP Novosibirsk LambdaNsk.
Sergey: Hola a todos, vamos a conocernos. Alexander es un orador principal en este C ++ Siberia, e Ivan fue un orador principal el año pasado. Hablemos de programación funcional. Por lo que recuerdo, FP en C ++ fue el tema de su discurso principal anterior, Ivan ...
Ivan: No del todo, pero parcialmente, sí.
Sergey: Y el tema del informe de Alexander es sobre la programación funcional. Por lo tanto, preparé un par de preguntas y la primera: ¿cómo se determina la FA?
Alexander: No creo que haya una definición "correcta" de FP, pero hablando de mí personalmente, FP es algo con una composición funcional y funciones de primera clase.
Ivan: Estoy de acuerdo, pero agregaría más funciones de un orden superior, aquellas que pueden tomar otras funciones como argumentos y devolverlas como resultado.
Sergey : Enlace a una función en C, ¿se considera?
Ivan: No, C no es un lenguaje de programación funcional :-)
Sergey: Dime por qué?
Ivan: Debido a que no puede crear una nueva función a partir de una combinación de punteros de función, solo puede apuntar a los existentes. Por supuesto, si no se usaron algunos hacks de ensamblador.
Sergey: Genial, ¡ahora tengo una respuesta oficial! Las personas constantemente hacen esta pregunta por qué C no es un lenguaje de programación funcional, porque hay funciones completas allí. Y aquí es por qué C ++ es un lenguaje funcional, más comprensible ...
Alexander: No diría que C ++ es un lenguaje de programación realmente funcional, admite un montón de paradigmas vertidos en un lenguaje.
Sergey: Quiero decir, C ++ admite el paradigma funcional, por supuesto. Por cierto, ¿por qué? ¿Lo admite porque puedes manipular funciones de orden superior?
Ivan: Bueno, me parece que siempre ha sido así, porque incluso en C ++ 98, las funciones de orden superior ya existen, incluso en STL. Este no es el lenguaje funcional más conveniente: hay lenguajes que implementan FP y mejores. Pero para mis necesidades siempre ha sido bastante funcional.
Sergey: Pero desde este lugar con más detalle. ¿Qué tipo de necesidades tienes?
Ivan: es complicado. Vamos, cuenta una historia. Cuando estaba en la universidad, pasamos por LISP, y todos odiaban este LISP porque es feo. Pero lo que entendí de esto es cómo simular construcciones C directamente en código LISP. Y luego, un día, salió una nueva versión de Java, que se lanzó para cosas como el foreach incorporado, y pensé: wow, necesitas un nuevo compilador, una nueva versión del lenguaje y todo eso es nuevo solo para implementar algo que hice en la universidad en LISP , que generalmente ni siquiera admite bucles. En ese momento, me di cuenta de que FP es algo bastante bueno para construir abstracciones de alto nivel, y es por eso que uso C ++ funcional en 2019.
Sergey: De hecho, usas el FP para un diseño de alto nivel.
Ivan: Exactamente.
Alexander: En este momento no trabajo en C ++, pero no me negaría a usarlo para manipular datos, esto es mucho más agradable que en el enfoque imperativo. Incluso en comparación con OOP, en contraste con él, solo las transformaciones son aceptables aquí, y esto es conveniente.
Sergey: Bueno, puedes usar FP no solo con C ++, ¿verdad? Bien, entonces la siguiente pregunta: ¿qué parte de C ++ estás usando? Si solo los problemas de diseño son importantes, puede elegir solo la parte que vaya bien con el FP, la que realmente usa.
Ivan: Estas definitivamente serán funciones lambda. Y aún más importante: plantillas, porque le permiten pasar otras funciones como argumentos y todo lo demás, y las lambdas son solo una buena sintaxis para escribir objetos funcionales.
Sergey: Sí, ya nos dimos cuenta de que realmente te gustan las lambdas :-)
Ivan: No es que realmente les hayan gustado, pero esto es claramente lo mejor que teníamos en C ++ 98, es más conveniente trabajar con ellos.
Alexander: Sí, también me gustan las lambdas: esta característica es tan universal que solo se puede escribir en ellas. Esto es algo así como un combinador universal que le permite construir cualquier lógica, tal vez no tan hermosa como en otros idiomas, pero no menos útil.
Sergey: Ivan, notaste aquí que hay estándares anteriores a C ++ 11, por ejemplo, C ++ 03, que es muy común, y ya hay características funcionales allí. Y hay más características funcionales en los nuevos estándares ... ¿Es posible decir que C ++ se está moviendo hacia el FP? ¿Continuará o se detendrá este movimiento? ¿Y entonces a qué conducirá?
Ivan: Hay un buen informe de Simon Peython Jones sobre los lenguajes de programación en general, y allí dibujó un gráfico que muestra muchos idiomas seguros y los idiomas utilizados. Haskell comenzó su historia como un lenguaje completamente seguro con el que no se puede hacer nada, porque no hay E / S y nada en absoluto. SPJ clasificó el lenguaje C y los lenguajes ensambladores como aquellos que son muy útiles, pero al mismo tiempo extremadamente inseguros. Desde entonces, Haskell ha comenzado a avanzar hacia una mayor seguridad. Por otro lado, esas características que aparecen en C ++: parecen aumentar principalmente la seguridad para que pueda escribir programas correctos de manera más simple. Dio la casualidad de que la mayoría de estas cosas provienen de lenguajes de programación funcionales.
Sergey: ¿Por qué piensas eso? ¿Debido a la naturaleza de la FA?
Ivan: Sí, tal vez por naturaleza ... pero no estoy seguro.
Alexander: Creo que la FA cautiva a todos simplemente porque estamos cansados de luchar con plantillas, reorganizar bytes, con algún tipo de heces de bajo nivel; queremos algo digno de aplicar nuestra propia inteligencia.
Sergey: Es decir, ¿para ti esto es una especie de ejercicio intelectual?
Alexander: Sí, así.
Sergey: entiendo. Cuánto más interesante es para un desarrollador pensar en abstracciones de alto nivel que implementar características estúpidas estándar; esto es desagradable. Entonces esta es la pregunta C: ¿tiene alguna experiencia con la aplicación práctica de FP en C ++? ¿Algún proyecto de producción?
Ivan: por supuesto. Uno de los proyectos más grandes del mundo, KDE, tiene varias partes dentro de él que usan intensamente el estilo funcional. Por supuesto, esta es una mezcla de, por así decirlo, C ++ más tradicional orientado a objetos con un conjunto de conceptos funcionales. Nunca iba a ser purista o algo así. Siempre trato de combinar lo mejor de diferentes mundos.
Sergey: ¿Qué hay de Haskell o Scala? Después de todo, son ampliamente utilizados en la producción. ¿Qué le parece la idea de que Haskell ahora se considera el estándar de un lenguaje funcional? Esto es especialmente notado por los puristas.
Ivan: Sí, estoy de acuerdo en que Haskell hoy es sinónimo de FP. De hecho, cualquier característica de Haskell es percibida por las personas como algo relacionado con la PF. Esto no es necesariamente cierto, pero creo que Haskell se ha convertido realmente en el lenguaje de programación funcional académico más popular. Sé que varios bancos en Londres y el norte de Europa hacen un uso extensivo de Haskell, pero aún así Scala es mucho más popular en este momento.
Alexander: Estoy de acuerdo en que Scala es más popular, pero Haskell parece ser un lenguaje más funcional, la mayoría de sus características se implementan más correctamente. Es decir, cuando tienes curry que es fácil de hacer, cuando hay una manera fácil de hacer la composición, la programación se vuelve fácil y simple, es como caminar por el bosque y disfrutar de las vistas.
Ivan: Pero a veces hay osos en el bosque. Si estas en Rusia.
Sergey: ¿Crees que C ++ está inspirado principalmente en Haskell? ¿Vale la pena?
Ivan: ¿Te das cuenta de algún miembro específico del comité? :-) Alguien insinuó que los conceptos aparecieron como resultado de la comprensión de las clases de clase, pero Björn detuvo estos rumores e incluso escribió algún documento sobre cómo los conceptos difieren de las clases de clase. Desde mi punto de vista, difieren en todo, pero tienen un propósito. Solo diferentes enfoques.
Sergey: ¿El futuro / promesa está relacionado de alguna manera con FI? Bartosh parece haber argumentado que estas son mónadas mal implementadas.
Ivan: Bueno, sí, se implementan como mónadas, transmitiendo secuelas, pero no estoy seguro de qué es lo más importante en este asunto.
Sergey: ¿Necesitamos soporte mejorado de mónada en C ++?
Alexander: Por supuesto, esta es la característica más importante que puede convertir C ++ en un lenguaje realmente bueno.
Ivan: Por cierto, ya que estamos en la conferencia, déjame hacerte una pregunta también, Sergey. Dijiste que las conferencias son un trabajo emocionante. Comparta lo que es tan interesante al respecto, y ¿me aconsejaría a mí o al camarada Granin organizar independientemente conferencias en otras partes del mundo?
Sergey: La organización de conferencias es realmente genial, conoces a muchas personas interesantes, pero esto es solo la punta del iceberg. Y allá abajo: mucho trabajo, toda esta preparación del salón, comida para los participantes, sin mencionar la búsqueda de oradores. C ++ Rusia todavía no es la conferencia más famosa del mundo, y los oradores tienen que explicar que somos una conferencia nueva, que aquí están sucediendo cosas interesantes. Debe convencer al orador, especialmente a los famosos oradores estrella que no están particularmente interesados en volar a Rusia solo para ver un nuevo país. El trabajo organizativo es difícil, especialmente si trabajas en el trabajo principal. Pero todo vale la pena comunicándose con estas personas maravillosas. Sin embargo, ahora he llegado al punto de que prefiero asistir a la conferencia de otra persona que a la mía.
Ivan: Es decir, sugieres asistir a conferencias, en lugar de hacerlas.
Sergey: Sí, si puedes evitar organizar una conferencia, deberías arriesgarte. Al organizar, una gran carga caerá sobre usted, este es otro trabajo de 8 horas. Personalmente, empiezo a trabajar 8 horas adicionales al día aproximadamente 3 meses antes de la conferencia. Es divertido hacerlo ... pero espero que mi familia sea igual de divertida. Gracias por preguntar!
Y ahora, volviendo al tema. Hablamos de programación funcional, y casi me convenciste, en el sentido de que tus informes me convencieron. Existe la sospecha de que el enfoque funcional en C ++ me ayudará con el subprocesamiento múltiple cuando necesito sincronizar diferentes cosas. ¿Realmente ayudará?
Ivan: por supuesto.
Alexander: A pesar del hecho de que tengo una experiencia limitada con subprocesos múltiples funcionales específicamente en C ++, tengo que decir que cuando tienes un mundo de funciones puras, es mucho más fácil hablar de ellas en un entorno multiproceso. Si escribe lógica, por ejemplo, competitiva, no tiene que pensar en sincronizar todas estas cosas, en mutexes, en secciones críticas, en nada. Todo esto simplemente desaparece, porque piensas en el código como un código secuencial regular, y todos los subprocesos múltiples y la sincronización están ocultos en algún lugar dentro. Hay muchos enfoques para la programación multiproceso y funcional. No estoy seguro de que esto suceda en absolutamente todos los enfoques, pero, por ejemplo, la memoria transaccional de software es un gran enfoque para reducir la complejidad en aplicaciones competitivas. Lamentablemente, se trata de elegir los compromisos correctos.
Ivan: Cuando el compilador hace todo el trabajo por ti, tienes que pagar con eficiencia.
Alexander: Bueno, hay diferentes problemas. Primero, debe comprender todas estas cosas como STM, y luego transmitir este conocimiento secreto a sus colegas. Y luego hay errores en una implementación particular y lugares que pueden funcionar mucho mejor cuando se usa el control manual de subprocesos. Pero puede escribir más rápido y más fácil que con dicho control manual. Será más lento de ejecutar, pero el código tendrá menos errores. Por cierto, Ivan, ¿qué opinas sobre qué tan bien este tema está bien cubierto en las conferencias?
Ivan: Este tema está en auge. En los últimos años, todas las conferencias principales: CPPConf, C ++ Rusia, Meeting C ++, etc. - Recibí informes directamente en FP, o en estructuras de datos algebraicos, o algo así. A veces los oradores ni siquiera sospechan que en su informe hablan sobre algún concepto del FP. En C ++, las cosas provienen de muchos lugares diferentes ... La gente generalmente no escribe en un solo idioma. Imagine a Ivan Ivanov trabajando en un proyecto escrito en Erlang y C ++. Entonces llega Tatyana Petrovna, y ella ya trabaja para Haskell con funciones puras y todo eso, toman sus mecanismos favoritos y los portan a C ++, y como resultado, una gran cantidad de personas de diferentes comunidades traen más y más cosas a C ++. Todo esto sucede ante nuestros ojos. Como mínimo, esto sucede en la comunidad de desarrolladores de C ++, pero en cuanto a las compañías de C ++, no estoy tan seguro. Sin embargo, muchas personas en la comunidad C ++ ahora están trabajando en conceptos funcionales.
Alexander: ¿Entendí correctamente que muchos de los principales desarrolladores de C ++ estudian Haskell solo para comprender lo que está sucediendo con C ++?
Ivan: No estoy seguro de que le enseñen a Haskell por este motivo. Creo que los desarrolladores de C ++ son muy egoístas. Aprendieron C ++ muy bien solo porque es complejo. Y si quieres aprender algo realmente nuevo, tu camino obviamente no se encuentra en ningún Java, que está especialmente creado para ser simple. Debe buscar en el campo de los idiomas extraños e inusuales, los más extraños, y Haskell estará automáticamente entre las respuestas más populares. Una persona lo ve, entiende: oh, esto es algo más complejo que C ++, necesita aprender. Cuando estudié a Haskell, fue lo mismo conmigo, y tengo amigos que han seguido exactamente la misma línea de razonamiento.
Alexander: Cuando Eric Nibler estuvo con nosotros en Siberia y mostró su biblioteca para rangos, a menudo se le preguntó cuál era la fuente de inspiración. Él respondió que era Haskell. Tal vez no se deben tomar todas las características seguidas, pero algunas son claramente necesarias en la comunidad.
Ivan: Es un poco de evolución. Material genético. Y Haskell también se puede mejorar tomando algo de C ++. La mayoría de los idiomas están experimentando tal evolución. Java intentó adaptar LINQ de C # a sí mismo, y los creadores de LINQ de C # se inspiraron en Haskell, etc. Resulta una red tan hermosa y enredada de influencia mutua entre diferentes idiomas.
Alexander: Sin embargo, ¿C ++ sigue siendo un lenguaje de bajo nivel?
Ivan: La mayoría de la gente piensa que sí.
Sergey: ¿De qué tipo de "bajo nivel" estás hablando?
Ivan: Compilado en código de bajo nivel. Pero funciona con abstracciones de alto nivel. Todo el punto y el propósito es que tales abstracciones no conducen a una sobrecarga innecesaria en términos de rendimiento. C ++ debería generar código a partir de sus abstracciones que no serían peores que las escritas a mano. Al menos teóricamente.
Alexander: ¿Qué pasa si alguien rompe esta regla? Por ejemplo, Rangos.
Ivan: El rendimiento de la compilación sufre, sí. Todas las características nuevas, especialmente las características suministradas en las bibliotecas, aumentan el tiempo de compilación. Pero no hay razón para que los rangos sean lentos. Si los rangos se están desacelerando, entonces lo único que puede culpar aquí son los compiladores que no están optimizados para este caso en particular.
Sergey: los rangos en sí mismos no están frenando, pero los rangos están en modo de depuración: esta es la esencia de toda la discusión. En el modo de lanzamiento, funcionan bien.
Ivan: Esto es normal.
Sergey: No todos están de acuerdo con esto :-)
Ivan: Sí, lo sé en la práctica. En una compañía, en su biblioteca más utilizada ... No diré qué tipo de compañía y biblioteca es ... hay algoritmos que son asintóticamente significativamente más lentos en modo de depuración. ¿Y quién se quejará ahora de que los rangos están haciendo lo mismo?
Sergey: En el artículo que estamos discutiendo, el punto no estaba en los rivales en sí mismos, eran solo un ejemplo para el autor, que estaba furioso porque esta situación se estaba convirtiendo en una tendencia y baja productividad en modo de depuración. En su área temática, motores de juego, esto es simplemente inaceptable.
Alexander: A estas personas no les gusta STL en absoluto, porque funciona más lento de lo que necesitan. Los rangos solo expanden la biblioteca en la misma dirección, y para ellos parece otra característica inútil que no pueden usar.
Sergey: Los que odian odiarán.
Ivan: Exactamente. Por ejemplo, todos usan la clasificación. Solo imagine que no hay más ordenación en la biblioteca estándar. ¿Cómo lo implementaría?
Sergey: Normalmente hago una pregunta así en una entrevista :-) Esta es una pregunta muy común.
Ivan: Sí, una pregunta frecuente es cómo implementar la clasificación. Y luego habla sobre alguna versión básica de clasificación rápida, que en realidad no se usa en ningún otro lugar del mundo, porque puede ser muy lenta en ciertos casos. La biblioteca estándar no permite su uso, ya que requiere un N log N garantizado, y la ordenación rápida no puede. En su mayor parte, puede, pero el estándar en este lugar es muy estricto y no significa N log N acumulado, debería ser N log N puro, y ¿cómo implementará tal algoritmo? Debe investigar, encontrar muchas optimizaciones diferentes para una ordenación rápida y fusionarlas en un algoritmo, que consta de al menos tres algoritmos diferentes, como se hace en libstdc ++. Este es el significado de las bibliotecas estándar: no necesita saber todas estas cosas para programar. No es necesario descubrir cómo implementar todo de la manera más eficiente, alguien más ya se ha encargado de esto por usted. Por lo tanto, no me gusta este enfoque cuando la gente dice: "STL es muy complicado, no lo usemos y escribamos todo desde cero manualmente".
Sergey: Nos acercamos al final de la entrevista, así que la última pregunta: ¿cómo te gusta en Rusia?
Alexander: Se puso más frío.
Sergey: ¿ Incluso para ti? Eres local!
Ivan: Pero para mí hace mucho más calor aquí de lo esperado.
Sergey: Ahora es -16, y te dijimos que será -40.
Ivan: ¡ Sí, lo prometiste! Me preparé especialmente para menos cuarenta. Y luego miro el termómetro, y allí todo está más y más cálido.
Sergey: Bueno, ahora solo nos encontraremos en C ++ Rusia 2019, será en Moscú y habrá una temperatura positiva. Gracias por la entrevista y hasta pronto!
Minuto de publicidad. Del 19 al 20 de abril, se llevará a cabo una conferencia de C ++ Rusia, en la que Ivan hará una presentación "Diseño de C ++ solo para movimiento" , y Alexander hablará sobre analizadores monádicos. Además, Ivan realizará una de las tres capacitaciones más importantes : "Programación funcional aplicada en C ++" . Queda un mes antes de la conferencia y el programa continúa siendo refinado. En el sitio web oficial puede ver qué informes ya han ingresado al programa y comprar boletos . Tenga en cuenta que hay diferentes tipos de boletos, y elegir el correcto puede ahorrar mucho.