Siguiendo los pasos del movimiento ruso Scala. Parte 2

En la última parte de la investigación, Roman Timushev me aconsejó que contactara a Vlad, lo cual hice. Vlad aclaró lo que me interesa, delines y acordó escribir algunos párrafos. A la mañana siguiente vi un aviso en Facebook. Fue Vlad quien encontró un nuevo testigo: Alexander Podkhalyuzin . De 2008 a 2017, trabajó como líder de equipo en el complemento Scala en IDEA y personalmente vio todo el desarrollo del movimiento Scala, pero principalmente no la parte rusa.

"Hice clic" en mi cabeza: los planes están cambiando, este es un nuevo hilo en la investigación. Marcaron la hora y grabaron una entrevista de una hora con Alexander. Hay tanta información que no había opciones para colocarla en ningún lugar excepto en una parte separada. Por lo tanto, te advierto: hay mucho texto por delante.



En esta parte estamos hablando con Alexander Podkhaluzin y Mikhail Mutsyanko . Fuera del programa - comentario de Ilya Sergey . Scala plugin, los primeros eventos Scala en Rusia, dejando en Kotlin, nativo en ambos idiomas, Eclipse al atardecer y mucho más bajo el corte.

Cómo llegó Alexander a Scala, fue a Kotlin y enseñó

De 2008 a 2017, Alexander Podkhalyuzin desarrolló el complemento JetBrains Scala en IDEA como líder del equipo. Más tarde se fue a Kotlin Tooling primero para Kotlin / Native, luego para Kotlin en su conjunto.

Alexander : La tarea es grande, todo se confunde después de la limitación de años. Por cierto, el movimiento comenzó no en 2010, sino tres años antes. En 2007, recién vine a trabajar a JetBrains y tuve suerte con MPS ... ¿Sabes qué es MPS?

Vadim : Escuché que es un lenguaje declarativo y visual.

Alexander : MPS está adelantado. Este es el Sistema de Meta Programación : programación generativa de inmediato con el IDE. Conseguí un trabajo en la empresa en MPS, pero ya encontraron a una persona allí. Así que tuve suerte: me enviaron a escribir un complemento Scala.

JetBrains comenzó a escribir un complemento, pero lo descartó porque era Groovy. Era popular y exigía apoyo. Todos los involucrados con el complemento Scala se pusieron a trabajar en el complemento Groovy. Nadie estuvo involucrado en Scala y heredé tal herencia.

Me uní a la empresa a principios de 2008. No sabía nada, comencé a cavar un analizador, solucioné un error, segundo, tercero, esto continuó para siempre. Como resultado, se sentó y lo reescribió. Así que lentamente se fue desarrollando.

Ilya Sergey trabajó en el complemento antes que yo. Lo encontré y trabajé con él en el complemento. Es curioso que yo fuera matemático e Ilya programador. Pero él quería ser matemático, y yo quería ser programador. Me gustaba programar, estaba listo para hacerlo y no entendía por qué a Ilya no le gustaba. Y él no me entendió. Como resultado, la vida puso todo en su lugar.

Ilya dejó JetBrains y se dedica a la informática en España, casi profesora. Recientemente llegó, le dijeron cómo buscar carreras automáticas: esto es algún tipo de ciencia. Todavía en alguna competencia se sentó y escribió 10 mil líneas en Scala. Dijo que todo es super, todo funciona. Todavía montó los primeros Scala Days, parece que en 2009.

Después de mirar la biografía de Ilya, sentí que era importante aclarar los detalles de la fuente original.

El informe que mencionó Alexander fue sobre análisis estático para encontrar condiciones de carrera en aplicaciones Java. En 2018, llevamos a cabo un trabajo junto con Facebook. Un informe y dos artículos más fueron escritos en él. Es cierto que existe todo el código en OCaml. La competencia es el Concurso de Programación ICFP que organicé este año . También escribí casi todo el código para el concurso en Scala usando Scala.js.

Yo uso Scala exclusivamente como usuario. Usando IntelliJ IDEA y el complemento Scala, se escribieron muchos prototipos para mis proyectos de investigación: síntesis de programas con punteros TyGus / suslik , pruebas de algoritmos geométricos . En la universidad, enseño un curso de subprocesos múltiples, donde Scala es el idioma principal.

Ilya Sergey , Profesor, Universidad Nacional de Singapur .

Alexander : Empecé a montar Scala Days en 2011. Desde hace tres años, de hecho, hemos estado escribiendo el segundo compilador de interfaz de Scala. Lleva años, es normal. Todo funcionó lenta y mal para nosotros, pero al mismo tiempo había al menos algo. Desde el punto de vista de los editores, nada era mejor de todos modos. No recuerdo si Eclipse comenzó a dar soporte en ese momento. Sí, parece que lo apoyaron en paralelo.

Vadim : hablé con Roman Timushev y él me contó sobre los 13 años, cómo comenzó a escribir y mantener reuniones en Moscú. Según su versión, todos usaron Eclipse. Fue bastante tolerable, fue oficialmente apoyado.

Alexander : Sí, lo fue. En 2011, Eclipse fue muy malo, y en 2013 alcanzó una velocidad como la nuestra en 2011. A diferencia de Eclipse, escribimos nuestro propio front-end, por lo que el resaltado de error fue diferente del compilador. Esto es inconveniente y este es un tema clave. Algunos errores no están resaltados, pero viceversa en el compilador. Eclipse usa el código del compilador.

Usar el código del compilador es una mala idea porque todo funcionará lentamente. En Kotlin, es similar cuando se usa el código del compilador. La situación no es tan mala como en Scala: pensaron un poco sobre el IDE, pero no es fácil proporcionar un buen rendimiento desde el punto de vista del IDE.

En 2011, Scalathon ( fotos ) se celebró en Filadelfia. Esta es la primera conferencia a la que fuimos invitados, pero fue extraño que fuéramos allí. Se comunicaron con JetBrains si nos gustaría asistir al evento. Antes de eso, no llamaron a ninguna parte con Scala, y cuando comenzamos a hacer algo, se dieron cuenta. Los usuarios, como los programadores de Scala, tenían una nariz desgarradora: alrededor de 100 personas durante la conferencia. En Scalathon, conocí a Bill Venners .

Vadim : El nombre me es familiar, pero no recuerdo quién es.

Alexander : El autor de dos cosas: Scalatest y el libro principal Programming in Scala . Este es un libro escrito con Martin Odersky, ¡nuestra Biblia!

Vadim : no leí.

Alexander : no importa. En mi casa está este libro autografiado por Bill Venners y Martin Odersky. Me lo dieron en uno de los días Scala en 12 o 13 años. En una cena para todos los participantes, se premió a las personas que contribuyeron a la comunidad. De repente me llamaron y recibí un libro por mi contribución.

Scala Days también comenzó a visitarse desde 2011. Al principio se llevaban a cabo una vez al año en Europa o en América, y luego dos veces. El año pasado asistí a una conferencia, pero no fui a la segunda. El año pasado presenté un informe sobre la comparación de Kotlin / Native y Scala Native. Nadie en el equipo de Kotlin creía que el informe sería aceptado, pero fue tomado. Quizás por respeto o por otras razones. Al informe asistieron pocos oyentes. Los programadores de Scala no están interesados ​​en todo lo que contiene la palabra "Kotlin". Así fue y sigue siendo.

Vadim : Creo que la palabra "nativo" jugó un papel.

Alexander : No, en Scala Days todos los informes sobre Scala Native siempre reúnen habitaciones completas, por ejemplo, una actuación de Denis Shabalin. Pero al mismo tiempo, la tecnología está lejos de la producción. Ella no está destinada a llegar allí por otros 10 años, al menos.

Vadim : ¿Por qué piensas eso? Me sorprendió, pero está Richard Whaling que escribe un libro sobre Scala Native, ya hay mucho material. Él va a los podcasts y habla sobre cómo lo usa en la producción. Él tiene una esfera donde hay muchos datos. Está muy satisfecho con los nativos en estas condiciones.

Alexander : Vea mi informe sobre la comparación de Scala Native y Kotlin / Native , en el que explico mi punto de vista. En el momento de la presentación, una persona trabajaba en Scala Native. Por lo tanto, no se puede hablar de ningún producto. Si hablamos de una persona que en algún lugar aplicó tecnología, tal vez. Simplemente no es convencional, habrá pocos usuarios.

Kotlin / Native tiene una aplicación específica: código compartido entre iOS y Android. Solo esto crea un cierto interés. Scala Native no tiene esto y no hay nada a lo que aferrarse. Scala Native puede usarse para cálculos cuando tiene que combinar el código Scala y cálculos rápidos como Tensorflow. Pero Scala Native no significa que entre Scala y Native puedan llamarse entre ellos de manera segura o buscar código común.

En Kotlin, nos estamos elevando para escribir y compilar el mismo código. Este es un gran trabajo en el sentido del diseño de que no está utilizando POSIX, sino algún tipo de biblioteca de capas intermedias que funciona igualmente bien en la JVM y sin ella. Si no tienes una biblioteca así, eso es todo, Krant. El código será diferente en este lugar, y si es diferente, ¿cómo mantenerlo? ¿Cómo implementar bibliotecas en las que se deben compilar, implementar diferentes puntos finales, también hay un sistema de compilación, dependencias? Si cavas, entonces las preguntas: el abismo. Una persona que desarrolla Scala Native no puede responder a todos. La aplicación es una historia separada, y sobre esto puedes ver mi informe.

Vadim : Bueno, volvamos. En 2011, fuiste a Scala Days, y antes de 2016, ¿todavía estabas con el complemento Scala?

Alexander : hasta 2017.

Vadim : Entonces llegaste a Kotlin. Que paso

Alexander : Desde algún punto de vista, no hice todo lo que pude. Podrías seguir desarrollando el complemento Scala: muchos chips, hay algo que terminar. Pero, desde el punto de vista comercial, tiene éxito como proyecto. El 80% de los programadores de Scala usan IntelliJ IDEA. ¿Cuánto sabe de los productos que han capturado el 80% del mercado? Hay pocos de ellos.

¿Qué hacer a continuación? Quiero nuevas metas, nuevos horizontes, y dentro del complemento Scala esto era imposible. JetBrains está desarrollando su propio lenguaje de programación y es escéptico sobre Scala. Es imposible encontrar un lugar para Scala en la empresa, por lo que me voy o trabajo aquí y después. En la empresa cualquiera, o algo más. Tuve que tomar una decisión difícil.

Hasta cierto punto, me estaba preparando. Primero, me di cuenta de que si dejo el equipo, Kolya Tropin estará en mi lugar. Ahora está liderando el equipo. Me estaba preparando, y lo preparé de una manera peculiar, entendí que él podía pararse en mi lugar. El segundo: distribuyó lentamente todos los subsistemas, los rechazó. Ya no necesitaba programarlos.

La apoteosis de todo esto fue una lesión en la mano, cirugía y 2 meses de baja por enfermedad. Después de la salida, fui al Director General Maxim Shafirov. Él vino y dijo: "Dame algo más". Hubo tal detonante, algo se estaba preparando inconscientemente para poder hacer esto, y estos dos meses permitieron que se decidiera. Y Max sugirió. Dije "cualquier cosa menos Kotlin". Ya veo, soy del mundo Scala, y el mundo Scala odia a Kotlin.

Vadim : No es que lo odie, es desagradable que tal producto haya aparecido. Este es el trozo de Scala. Al mismo tiempo, el marketing está activo, el mercado está siendo capturado: aquellas personas que podrían ir al lado positivo de Scala.

Por otro lado, ¿eso es bueno? Si imagina una brecha en el conocimiento que necesita dominar para escribir efectivamente en Scala o Haskell, entonces para un desarrollador de Java es gigantesco. Aquí Kotlin es un punto de transbordo, al que puedes llegar, sentarte y seguir con seguridad.

Alexander : Esto no es del todo cierto. Cuando no había Kotlin, las personas acudían a Scala que no estaban contentas con Java: faltaba algo, muchas repeticiones. Scala tomó el lugar de lo que se llama Mejor Java. Kotlin apunta exclusivamente a este nicho.

Con Kotlin, Android y todo lo que sucedió, y ahora multiplataforma, eso es todo. Kotlin no se fijó en un Android, en un nicho, y fue más allá.

Vadim : Creo que es bueno, Oracle se ha movido. Ahora, al menos algunos JEP normales se han ido para hacer que Java evolucione.

Alexander : Creo que la razón no es Kotlin, esta es una consecuencia normal. 2 años antes de que Google anunciara Kotlin, era insignificante. Cuando decidí mudarme, Max Shafirov me dio una lista para seleccionar. Aunque dije "simplemente no Kotlin", la opción de soporte Kotlin / Native en IDEA estaba en esta lista. Como resultado, de toda la lista decidí intentar mudarme a Kotlin. El día después de asumir la responsabilidad de Kotlin / Native, Andrei Breslav dijo que el próximo Google I / O anunciaría que Kotlin es un idioma de Android oficialmente compatible.

Aquí está el pensamiento: "Goofy". Pensé que estaba haciendo algo por un lenguaje marginal condicional. Estaba claro que el nicho de Better Java era difícil de conquistar. Con el lanzamiento de Java 8 con lambdas, esto se ha vuelto aún más difícil. Scala está bien con esto, no es fuerte con lambdas y no con lo que es mejor que Java. Es aleatorio: personas aleatorias llegaron a Scala con el entendimiento de que necesitan una mejor Java.

Después de Java 8, el flujo de estas personas se desaceleró. No van a ir a Scala y Kotlin, tienen lambdas. Para empezar, esto es suficiente, y lo mejor ya no está interesado. Me senté, pensé y me di cuenta de que la escala ahora es diferente.

En mi cabeza, cambié a un equipo en una escala no mucho más grande que en el complemento Scala. En ese momento, había 100 mil usuarios, y Kotlin tenía 40 mil. Una escala completamente diferente. Me di cuenta de que es divertido, que no me lo dijeron por adelantado. Decidí ir a Kotlin porque era interesante intentarlo, y no por objetivos ambiciosos y ambiciosos.

En general, Scala es más agradable de programar. Cuando comienzas a escribir Kotlin después de 9 años de programación en Scala, terminas sin manos. Hay algo de tristeza en esto.

¿Qué haría si fuera CTO? Para una tarea simple de Kotlin, sería más fácil para mí formar un equipo. Sería más barato o más eficiente. Podría haber reclutado programadores de Scala más baratos, pero habría obtenido un resultado peor, porque harán algo terrible en este Scala. Incluso si es difícil en el mercado laboral, comenzaré a reclutar programadores de Java: Kotlin será mucho más fácil capacitarlos. Esto es desde el punto de vista de comenzar un nuevo proyecto, si no hay cosas tecnológicas serias.

Para la industria bancaria, por ejemplo, hay razones para usar Scala. Kotlin no puede resolverlos. La misma metaprogramación en Scala es mucho más conveniente.

Si piensa mucho en este tema, puede crear cosas geniales de infraestructura en Scala, pero es imposible en Kotlin. Existen los mismos procesadores de anotaciones. Algún día será posible, pero solo en la perspectiva de varios años.

Vadim : ¿Por qué crees que Scala es bueno para los bancos?

Alexander : Hay muchas repeticiones que no están relacionadas con el lenguaje de programación. Este es un sistema donde hay objetos de tipo de usuario. Requiere mucha duplicación, comenzando desde la base de datos y terminando con todo. Para cambiar algo efectivamente, necesita un buen soporte de metaprogramación. Se necesita en todas partes, pero es necesario pegarlo con precaución, de lo contrario puede quedarse atascado.

En el año 11, fui llamado a la Universidad Académica. Fui demasiado vago para enseñar todo el curso, y estuve de acuerdo con Sveta Isakova , quien ahora es abogada desarrolladora de Kotlin. Acordamos ejecutar el curso por la mitad, pero se trataba de Scala. Probablemente quería aprender más sobre Scala.

Vadim : ¿Era la universidad superior en ese momento?

Alexander : Sí, con una magistratura en curso 5-6. Los primeros años de la competencia fueron pequeños. Pero la competencia por el lugar aumentó cuando JetBrains, Yandex y Transas llegaron con patrocinio, una invitación a pasantías y el objetivo de aumentar el personal para ellos.

Resultó genial: dinero privado y una iniciativa privada bajo cobertura estatal y la cobertura de Alferov. Dio una carta blanca completa: ¡haz lo que quieras! Resultó genial, porque los cursos son relevantes. Reclutaron personas que estaban a la vanguardia, entendieron lo que estaba sucediendo en la industria en este momento, y no hace 10 años no estaba claro dónde. Si hablamos de universidades ordinarias, ala "mathmech / mehmat", entonces Pascal no pasa allí, esto no tiene nada que ver con la vida real.

Esta fue una universidad académica fuerte. La gente entendió que cuando llegaran allí, volarían muy rápidamente a la industria. Graduados universitarios con mucho gusto reclutados en Yandex y JetBrains. Este es un buen paso profesional, y la competencia fue de 10 estudiantes. Enseñé allí durante 5 años. En el segundo año, Sveta no habló conmigo sobre Scala, y llamé a varios asistentes, en particular, Sveta para Kotlin. Como resultado, cambiamos el nombre a JVM-languages.

En algún momento, obtuve el apoyo de Clojure y entendí un poco este lenguaje. Según los estudiantes, no entendían qué estaba haciendo Clojure, qué tipo de basura era. Hablan sobre idiomas normales: Scala y Kotlin y, de repente, arrastraron Clojure. Simplemente no era un experto. Esa fue la historia.

Sobre el primer ScalaSPB / ScalaDev

Alexander : Luego, eventos como Scala Days aparecieron en San Petersburgo. El primer ScalaDev pasó , y para el segundo evento, los organizadores de los Scala Days originales contactaron a San Petersburgo y pidieron que se les cambiara el nombre.

Vadim : ¿En qué año es este?

Alexander : Sí, todo está ahí, 11-13. El evento fue realizado por muchachos de la subcontratación electrónica de San Petersburgo e-legion. Parece que escribieron la aplicación Raiffeisenbank. Incluso escribieron una aplicación móvil en Scala, pero ahora nadie escribe de esa manera: la gente está loca.

Vadim : Uno de los invitados al podcast , Matvey Malkov , habló sobre Scala y Android hace dos años. Dijo que todo está bien con ellos, y lo usan. Su principal ganancia es tanto el backend de Scala como las aplicaciones.

Recientemente le escribí con una solicitud para hablar en la conferencia, porque no encontrarás a nadie sobre teléfonos móviles. Resultó que dejó la compañía y lo último que hizo fue configurar Cot para construir el módulo Kotlin a partir de ese proyecto en Scala para que los chicos se volvieran gradualmente a él.

Alexander : Hace dos años, Kotlin no tenía nada claro. Teóricamente, Google podría tomar Scala, pero no lo hizo.

Actuamos en los primeros Scala Days e incluso reunimos personas. Más precisamente, no en el primero, sino en el segundo, que se celebró en JetBrains. Entonces Sveta Isakova actuó con una introducción en Kotlin.

Fue divertido: todos los desarrolladores de Scala percibieron a Kotlin como el enemigo número uno. Hall reaccionó muy negativamente y lanzó preguntas: "¿Por qué no se está haciendo esto, por qué no, por qué no?" Era espeluznante, algún tipo de piratería.

Después de Sveta, fui la segunda persona en decir algo sobre Kotlin en la conferencia de Scala, sobre Kotlin / Native. Mi experiencia ha demostrado que esto no tiene sentido. No estoy por el bien del informe, estaba interesado en ver Scala Native. Cómo se organiza en el interior, programas de inicio, regocijarse ante algo. Incluso en ese momento, me alegré de que el tamaño binario de Scala Native fuera más pequeño que el de Kotlin. Creo que Kotlin / Native tiene menos ahora, porque 10 personas están trabajando en ello.

Vadim : Oh, bueno, definitivamente estás estrangulando a Denis Shabalin .

Alexander : Esto es imposible, es una tecnología muy compleja. Tenemos 10 personas, y esto no es suficiente. Y 10 personas geniales, muy geniales, prueba estas más colecciones. El propio Denis es genial, pero ¿qué puede estar solo?

La historia sobre la comunidad es bastante interesante, como lo es toda la historia de Scala. Mucha gente quería crear algún tipo de marco, probablemente nadie lo necesitaba, para anunciar y dejar de fumar. Se formaron muchas estrellas peculiares, y algunas también ayudaron a EPFL. Uno de los requisitos es un trabajo de posgrado de un estudiante de posgrado. Por ejemplo, Scalameta es obra de Zhenya Burmako . En el proceso de trabajo, los estudiantes graduados aumentan el precio como programadores, y después de graduarse encuentran un trabajo genial. El primer trabajo con un salario es más que para las personas que han estado trabajando durante 10 años. Debido a que son famosos, informaron sobre un montón de conferencias y giraron.

Aquí hay otra cosa. Mira, en Kotlin: aquí lo vamos a hacer, aquí está, y en Scala absolutamente igual. Aquí está Tasty, en el backend Kotlin IR. Pero, dado que en Scala todo impulsa a la comunidad, todo está en completo caos. No hay diseño centralizado. Lo que pase funcionará. El hombre quería quemar algo, resultó. A Martin le gustó, la aprobación fue para las masas. Y en Kotlin, cada vez más clara y profesionalmente, eso es lo que significa la industria.

Sobre Eclipse y Jason Zaugg

Alexander : En el '13 fuimos a la conferencia. Todos en el compilador programado en Eclipse. Nos pusimos de pie y las personas que usaron IDEA se nos acercaron. Estaban complacidos, agradecidos. Tenemos el 10% del mercado, el resto en Eclipse. Todos los compiladores están sentados en él. Nos esquivaron durante mucho tiempo, de repente los convencemos de que lo usen. Pero en algún momento hubo un cambio.

En el año 11 o 12, tuvimos un colaborador, Jason Zaugg . En el mundo del código abierto, esto no es extraño, pero rara vez aparecen personas que invierten mucho tiempo y codifican mucho. Jason vino, ganó mucho dinero y él mismo trabajó en un banco. Incluso le dimos los derechos de cometer. Ni siquiera tuvo que mostrar la revisión para su publicación. Simplemente se sentaron, codificaron, discutieron algunas cosas juntos. Basado en nuestra interfaz, descubrió cómo funciona Scala. Todo terminó cuando Jason consiguió un trabajo como compilador de Scala. Es triste que no lo hayamos arreglado para nosotros. Creo que esta es la estrategia equivocada. Si una persona trabaja para usted de forma gratuita, debe organizarse para sí mismo, de lo contrario irá al compilador de Scala. No había más de esto.

Jason es una gran persona y un colaborador genial. Era fanático de IDEA. El hecho es que el complemento Scala se cuelga del código del compilador. El código es complejo: inyección de dependencia (DI), que, en esencia, es un patrón de pastel. Cuando abre cualquier archivo, debe analizar todo el compilador. Debido a DI, hay TODO en el contexto, y todo está allí con inferencia de tipos, y debe mostrar el tipo en todas partes: todo está entrelazado. El análisis de un archivo tomó 5 minutos. Incluso en la configuración del compilador como un proyecto, todavía llegó el bootstrap. Debe depender de sí mismo, esto se llama bootstrap. Tales proyectos fueron difíciles de establecer.

Jason y yo pasamos mucho tiempo adaptándonos. Para hacer posibles los proyectos bootstrap, programe en el compilador, de modo que al menos pueda escribir código en estos archivos complejos. Al principio, todo era rojo, y pasé mucho tiempo para convertir todo en verde. Incluso hicimos una prueba que verificó que nuestro frontend en el compilador es verde o contiene pocos errores. Y, en consecuencia, el equipo del compilador cambió completamente a IDEA.

Vadim Chelysov : ¿En ese momento comenzó el flujo de salida de Eclipse?

Alexander : Hay varias razones para el flujo de salida. Primero, IDEA lanzó una versión comunitaria. Esto significa que puede colocar el complemento Scala en la versión gratuita del usuario. Fuimos de código abierto desde el principio, y cuando comenzamos, era de propiedad exclusiva, con código abierto. Pero se instaló en un IDE pagado. Para esto, escribieron el soporte de Eclipse, porque necesitaban una herramienta estándar que se pudiera usar de forma gratuita. Por lo tanto, también nos volvimos libres.

El segundo: Eclipse como plataforma comenzó a morir en el '14. No murió, es ridículo decirlo, pero el financiamiento se ha roto abruptamente. La Fundación Eclipse comenzó a recolectar menos dinero y no está claro cómo desarrollar la plataforma en tales condiciones.

La tercera razón es que no pudieron hacer un IDE rápido. El compilador de presentaciones funcionó lentamente, y si hablamos de algún tipo de funcionalidad, generalmente son ensayos, la refactorización es extremadamente difícil de hacer. En el compilador, desde el punto de vista de la optimización, los árboles se construyen unidireccionales, no puede tomar un padre. Para encontrar el nodo principal, debe tomar un archivo de arriba, ir a ellos y mirar - terrible alboroto.

La cuarta razón es que funcionan con display en el compilador. Este es el árbol que se obtiene después del desacoplamiento. El editor está escrito en la declaración frontal, y en el compilador de presentación generalmente no está claro qué tipo de código. No está claro cómo trabajar con esto y organizar la refactorización. ¿Cómo extraer esta declaración frontal, y no toda esta basura loca? En consecuencia, las características aparecieron lentamente.

Al mismo tiempo, nuestro front-end era miserable y no funcionaba bien. Pero para que él sea al menos así, tuvo que hacer cosas terribles. Érase una vez, el método para {i <- 0 to 10} println(i) requería soporte para el 80% del lenguaje. Debido a que está desacoplado, y tiene una conversión implícita para Range - 1 to 10 , a lo largo de la ruta de una conversión implícita para el map , los parámetros implícitos son CanBuildFrom . Además, todavía hay una loca jerarquía de colecciones y lambdas, y alguna otra lambda anónima con un parámetro desconocido: el estaño completo. Una vez que este ejemplo funciona, debe comprender que funciona el 80% de la interfaz. Por lo tanto, incluso un front-end pobre significaba que admitíamos una increíble cantidad de funcionalidad Scala.

Ahora IDEA ha escrito muchos convertidores de idiomas. Son extraños, pero diferentes, y cuando todo comenzó, nadie lo recuerda. En 2009, fui a una conferencia y allí me sorprendió, ¿por qué no hacer una conversión de Java a Scala? Discutimos que se cansará de los puntos y comas para eliminar y expandir los tipos; debe moverse de alguna manera. Me senté y escribí mil líneas en la noche, un simple convertidor de un idioma a otro.

Pero fui más allá y descubrí cómo facilitar la búsqueda de esta función. Cuando copio al código Java, espero insertar y eliminar puntos y comas ahora. Este es mi caso favorito cuando crea una función que es ideal para la detección. Si bien no la necesitas, no sabes sobre ella. Tan pronto como lo necesite, lo obtendrá de inmediato. Es como un estilo de Apple: simple y directo. En consecuencia, desde entonces, JetBrains ha escrito muchos convertidores, y la característica publicitaria es que se ofrecen en el inserto. Pero sí, se me ocurrió, este es mi orgullo.

Sobre compiladores

Mikhail Mutsianko , uno de los desarrolladores actuales del complemento Scala en JetBrains, está conectado a la grabación. En este número del podcast, Mikhail y su colega Andrei Kozlov discutieron el complemento con más detalle.

Alexander : Estoy provocando historias de Scala aquí. Misha, dime cómo apareciste?

Michael : Originalmente aparecí en Kotlin. Andrei Breslav realizó una de las primeras prácticas: un estudiante. Llegué al proyecto de generar el código de bytes Kotlinovsky DSL de la biblioteca de la interfaz de usuario de Android. Ella ahora se llama anko . Luego busqué cualquier tema para un diploma, y ​​él me envió a Sasha. Como diploma, hice un intérprete de árbol para Scalameta.

Alexander : Exactamente, este es el tema que obtuvo Misha en forma de diploma: apoyo para la metaprogramación. Misha hizo esto por mucho tiempo. ¿Hicimos algo al final?

Michael : Sí, funcionó. Es cierto, entonces Scalameta fue reprendido. Scala 3 tendrá algo similar, pero con una API más estandarizada.

Alexander : No sé nada sobre Dotty.

Vadim : Acabo de ver hoy que Miles Sabin manipuló su código donde migra sin forma a Dotty con nuevas macros, y parece que resulta. Typeable migrado.

Mikhail : Sí, en particular, él es una de esas personas que da instrucciones sobre cómo escribir en Scala, para que Shapeless funcione de forma inmediata, sin muletas. Esencialmente doblar sin forma al compilador.

Alexander : ¡Oh, vamos! Estas bromeando Dime, ¿se dobla Scalaz?

Michael : Bueno, de alguna manera no está claro quién está escribiendo Scalaz ahora. Miles no está parado detrás de él.

Vadim : Ahora toda la comunidad está cuidando a Dotty. Miles mira sin forma. Por enésima vez, estas implicaciones han cambiado, junto con una discusión sobre cómo hacer clases de Tipo de Luka Jacobowitz .

Alexander : Sobre la comunidad. A principios del año 17, el Centro Scala decidió reunir personas influyentes en la comunidad para el grupo de trabajo . JetBrains siempre ha sido observado desde lejos y con cuidado. Dios no permita que hagamos que la programación en IntelliJ IDEA sea peligrosa. Cuando se hizo difícil negar que todavía tiene que programar en IDEA, fuimos aceptados. Me invitaron a una discusión, pero luego me lastimé la mano y no vine. Luego dejó Scala y nunca apareció en el grupo de trabajo.

Siempre me ha divertido que la gente dijera: "¿Por qué necesitamos documentar los detalles del compilador? ¿Todavía no hay un segundo compilador?" Esto fue divertido porque el complemento Scala siempre ha sido ese segundo compilador alternativo. Todavía había Typelevel, por supuesto, pero es un tenedor.

Estábamos muy influenciados por el desarrollo de Scala. Cuando Jason Zaugg apareció en el compilador, fue genial. Comenzó a decirnos: "Hemos hecho esto, apóyanos". Hay una comunicacion. Cuando los compiladores miran hacia abajo y no los usan, no nos dicen nada. Eso fue antes de Jason.

Michael : Ahora pateo periódicamente a Guillaume Martres , que cortó a Tasty, y a Fengyun Liu ; cortó macros.

Para resumir

Vadim : Alexander, muchas gracias, resumámoslo. Ayer hablé con un hombre. Dijo que en Scala le gustaba el concepto único de implícito, en el que se colgaban varias características. Ahora, en Dotty, han llegado a los mismos métodos de extensión explícitos; obviamente, todas las implicaciones de casos de uso se han declarado con palabras exactas. Espiaba a Kotlin y Swift, probablemente. ¿Cómo te sientes acerca de esto? ¿Y en general a Scala 3?

Alexander : En 2018 fueron los últimos Scala Days que visité. En él, Martin Odersky habló sobre el hecho de que Scala tiene tantos conceptos de lenguaje, Kotlin tiene tres veces más, C # tiene aún más. Pero al mismo tiempo, las capacidades de Scala son más amplias.

Pensamos que era genial, pero no lo es. Me impresionó, me di cuenta de que Martin entiende que tenemos que movernos. Lo único que le preocupa es que Scala debería convertirse en una especie de lenguaje de nicho. Las posibilidades ilimitadas del lenguaje crean este nicho. Este es el DSL que ella sabe hacer, y todo es genial. Perseguir a Kotlin para obtener el mejor Java es difícil y cada año más difícil. Lo principal es no perder tu nicho. Si agregan toda esta funcionalidad y no pierden su nicho, será genial. Pero si Miles lo ejecuta todo, entonces puede funcionar. Si misha?

En las siguientes partes de la investigación sobre el origen del movimiento Scala, estamos esperando una entrevista con Vladimir Uspensky, Roman Elizarov y Nikolai Tatarinov. Si desea agregar nuevas facetas a la historia del movimiento Scala o compartir su experiencia de uso, envíe informes . La convocatoria de ponencias cierra después de 10 días.