Descargo de responsabilidad : sí, el lunes publicamos un habrapost con tal comparación de idiomas. No, no estamos locos. Todo va según lo planeado.
Vitaly Bragilevsky combina el conocimiento de la informática teórica y la práctica actual de programación. Enseña disciplinas relacionadas con la informática teórica, es miembro del Comité de Normalización de Haskell y es miembro del comité de supervisión para el desarrollo del compilador HHCell GHC.
Esta habrastatya es una gran entrevista con Vitaly sobre los siguientes temas:
- Enseñar y conocer JavaScript;
- ¿Por qué elegir Haskell?
- El lugar de los lenguajes funcionales en la vida de un programador;
- De qué sirve JavaScript y cómo evoluciona;
- Lo que aparecerá en los lenguajes de programación en los próximos 10-15 años;
- Qué lenguajes de programación son creíbles y por qué;
- ¿Cuál es la diferencia entre conferencias científicas y conferencias de desarrolladores? ¿Por qué un maestro incluso iría a ellos?
- Es importante leerle al programador, son libros obsoletos y cuáles de ellos deben leer.
Los miembros del Comité de Programa de la conferencia
HolyJS 2019 Moscú , Alexei
Zolotikh y Artyom Kobzar,
realizan entrevistas . Si la entrevista no es suficiente para usted, muy pronto, en el próximo HolyJS, Vitaliy contará y mostrará con ejemplos cómo conectar JavaScript con la teoría de algoritmos.
Acerca de la enseñanza y conocer JavaScript
Artyom : Entre nuestros oyentes, especialmente entre la comunidad de JavaScript, no eres ampliamente conocido, cuéntanos sobre ti, qué haces, cuáles son tus pasatiempos: trabajadores, profesionales, posiblemente no trabajadores.
Vitaliy : Principalmente enseño, doy un curso en la Universidad Estatal de San Petersburgo y participo periódicamente en otros trabajos. Como soy maestra, tuve que estudiar muchos temas diferentes. Como suele suceder en una universidad, es necesario leer un curso en particular, y para ello debes comprender todo esto.
Sucedió que enseñé muchas cosas. Por ejemplo, uno de mis primeros cursos especiales, que me asignaron en el primer año de trabajo, cuando era muy joven, se llamaba "tecnologías Web XML". Entonces estos eran temas candentes, Ajax acaba de aparecer en JavaScript, y realmente no había literatura. Le expliqué cómo usar todo esto.
Desde entonces, nadie entendió realmente cómo usarlo, todo se limitó a ejemplos como este: hay dos listas desplegables, el usuario selecciona un elemento en una de las listas, se envía una solicitud al servidor y usted recibe datos para completar la segunda lista desplegable. Era una novedad; había pocos sitios de este tipo en los sitios. Entonces, solo la búsqueda de Google apareció en modo beta, cuando, mientras comienzas a escribir algún tipo de consulta, él te dice que continúes. Las cosas de Ajax eran nuevas y les enseñé.
Lo que no enseñé solo después de eso: cosas tanto matemáticas como programadoras. Una vez me encontré con Haskell, y desde entonces se ha convertido en el área principal de atracción, lo cual hice. Además de enseñar, estudiar todo en informática en general, para enseñar, comencé a colaborar con la editorial "DMK-press", les traduje varios libros (con otras personas, edité algo yo mismo). Estaba alrededor de Haskell también. Quizás estos dos tipos de actividad, la enseñanza y lo que está asociado con la traducción de libros al ruso, es lo principal que hice.
Artyom : Es decir, llamamos directamente a un veterano de JavaScript. Encontré Ajax y, probablemente, incluso PHP.
Vitaliy : Sí, incluso programé en PHP en los primeros años, escribí varios sitios.
Sobre las razones para elegir Haskell
Artyom : Eres más famoso en la comunidad de Haskell. ¿Por qué te detuviste en Haskell y este ecosistema?
Vitaliy : Como nunca consideré una carrera como programador para mí, era libre en lo que me gusta. No necesitaba estar interesado en lo que pagan más. Cuando me enteré de Haskell, realmente me gustó. No es muy bueno hablar de esto, y de alguna manera incluso me permití decir algo como "Haskell es un idioma para personas inteligentes en la comunidad de habla inglesa, y la comunidad es más inteligente en promedio". Los estadounidenses me golpearon por esto, y tienen razón. Pero eso era exactamente lo que me interesaba.
Es decir, en un momento, mientras aún estudiaba en una universidad, me dedicaba a matemáticas bastante rigurosas, por lo que cambiar a un tema de programación relativamente duro fue muy natural para mí. En general, está claro que ahora, de los lenguajes de programación utilizados en la producción, Haskell es uno de los más intensivos en ciencia o recursos. Toda esta abstracción que existe está más cerca de las matemáticas. Por lo tanto, para mí fue una elección natural.
Sobre los lenguajes funcionales y su lugar en el mundo de los programadores.
Alexei : ¿Cómo te sientes acerca de los lenguajes dinámicos y funcionales? ¿Qué pasa con cosas parecidas a Lisp?
Vitaliy : Me gusta posicionarme no tanto como un Haskellist, sino como un amante de los lenguajes de programación en general. En primer lugar, está claro que todos los idiomas tienen derecho a existir. Creo que comparar lenguajes de programación sobre una base de "mejor-peor" es una ocupación completamente idiota. Desafortunadamente, esto a menudo se hace en las redes sociales y no solo, sino que esto no tiene sentido.
Me gusta aprender las características de los lenguajes de programación y de alguna manera clasificar los lenguajes de programación por estas características. Pero considerar que esta es una buena característica y que es mala es una estupidez. Por lo tanto, está claro que los idiomas con escritura dinámica ciertamente tienen derecho a existir. Por ejemplo, ahora en mi curso para estudiantes de primer año tomé como base el lenguaje de programación Julia. Este es un lenguaje dinámico, hay un sistema de tipos. Fue interesante para mí enseñarle, al mismo tiempo, ver esta área de aplicabilidad.
En general, el primer lenguaje funcional que encontré fue Lisp. Cuando leí el libro
"La estructura e interpretación de los programas de computadora" hace muchos años, por supuesto, todo esto impresiona. Por lo tanto, tengo un gran interés en todo esto. Por ejemplo, también me encanta JavaScript, porque conozco bien su historia.
Sé que cuando apareció por primera vez, debería haber sido algo así como Lisp, porque al principio la sintaxis original era como Scheme. Y luego, más bien, por algunas razones de marketing, fue reemplazado por uno similar a C, pero, por supuesto, los lenguajes Lisp están dentro, y me impresiona.
En general, tengo la sensación de que muchos amantes de JavaScript no lo saben, y están bien, pero lo sé, así que estoy aún mejor. Entonces, todos los idiomas son buenos, y es interesante para mí estudiarlos, es interesante estudiar el campo de aplicabilidad, es interesante ver qué se hace más fácil y más conveniente. Y, en general, esta comparación de idiomas para tareas individuales también es un área interesante separada, con la que me gusta tratar.
¿Qué hay de bueno en JavaScript?
Artyom : Mientras preparaba el informe, estuvo en contacto con la nueva versión de JavaScript, con lo que estaba incrustado en él. ¿Qué puede destacar buena, mala, quizás alguna solución interesante desde el punto de vista de la teoría de los lenguajes de programación?
Vitaliy : Evaluando desde el punto de vista de la variedad de lenguajes de programación, por supuesto, lo más interesante en JavaScript es su modelo de objetos. Esto es lo que fue desde el principio. El modelo prototipo tiene una historia muy rica, es súper interesante porque prácticamente ningún otro lenguaje moderno lo tiene ahora.
En lenguajes como C #, utilizando métodos de extensión, resuelven el problema de agregar métodos a objetos existentes. Esto es lo que JavaScript era desde el principio, y allí parece mucho más natural. Es decir, tenemos un prototipo al que agregamos métodos y luego creamos nuevos objetos basados en él. En lenguajes como C #, esto es más artificial, en mi opinión.
Me interesó ver cómo se agregan los módulos a JS. En JavaScript, durante mucho tiempo ha habido problemas asociados con los módulos, durante décadas, se puede decir, y me pregunto cómo comenzaron a hacer todo esto. Debido a que los módulos son un tema teórico profundo, existen muchos enfoques diferentes para su implementación. Es cierto, no puedo decir que estudié esto a fondo, pero esto es lo que me parece un caso interesante en el campo del desarrollo de lenguajes de programación. Es decir, cómo agregar características al idioma existente que no existían antes.
Esto sigue siendo interesante porque hace unos años en Haskell hubo un intento de agregar, digamos, módulos más correctos. Ahora podemos decir que este intento falló, nadie comenzó a usarlo. Este es el llamado proyecto de mochila, es decir, parece implementado, pero el uso es tan insignificante que quedó claro que hicieron un buen sistema modular nuevo, pero no funcionó muy bien.
Tengo la sensación de hablar con diferentes personas que están involucradas en JavaScript que los módulos en JS resultaron mejor. Es cierto, lo sé muy superficialmente. Creo que la opinión sobre JavaScript está muy influenciada por el hecho de que puede escribir código muy malo allí. Y si puede escribir código muy malo, alguien debe escribirlo en grandes cantidades. Esto afecta negativamente la evaluación del lenguaje. Desde el punto de vista de la teoría de los lenguajes de programación, esto, por supuesto, no es muy bueno.
Alexey : ¿Conseguiste ver las últimas versiones de JavaScript? ¿Qué sorprendió además del sistema de módulos?
Vitaliy : No puedo decir que tuve éxito. Hojeé algo, pero no muy profundo. No puedo enumerarlo.
Lo que aparecerá en los lenguajes de programación en un futuro próximo
Artyom : La teoría de los lenguajes de programación es un entorno bastante académico y, en principio, interesante. ¿Cuáles son las nuevas características en los idiomas que están a punto de aparecer en 10-15 años? ¿Qué investigaciones se están llevando a cabo actualmente en esta área?
Vitaliy : Diría que el tema más candente en este momento es la escritura gradual. Esto es cuando al mismo tiempo en el programa hay partes tipificadas y no partes mecanografiadas. Es para Python, para JavaScript, está hecho para lenguajes de juguete. Es decir, podemos, en primer lugar, combinar partes con y sin tipo, y en segundo lugar, tenemos una forma sencilla de expandir la escritura.
Es decir, estamos haciendo una implementación prototipo de algo, como siempre se ha hecho en lenguajes dinámicos sin ningún tipo, y luego comenzamos a colgar tipos en componentes individuales, cada vez más. Idealmente, obtenemos un programa mecanografiado con todos los beneficios. Hay menos errores en el tiempo de ejecución, etc.
Este es quizás uno de los desarrollos más importantes. Algunos elementos ya están en forma de bibliotecas, pero hasta ahora esto sigue siendo un área de investigación. Si observamos conferencias líderes sobre lenguajes de programación, seguramente habrá varias secciones dedicadas a la mecanografía gradual. Esto es algo que seguramente se incluirá en la mayoría de los lenguajes dinámicos, porque es muy conveniente. Resulta la combinación de dos mundos.
Durante diez años, se han realizado investigaciones sobre tipos dependientes, cuando el tipo depende de los valores. El mayor problema es que borra la línea entre la etapa de compilación y la etapa de ejecución, porque en la etapa de compilación aún no se conocen valores específicos, pero los tipos deben verificarse. Es decir, los valores específicos aparecen en tiempo de ejecución, pero los tipos ya deberían ser correctos.
Y allí ya necesita escribir una función en la que, según el valor pasado, cambie el tipo de resultado. Este desenfoque de la frontera entre el tiempo de ejecución y el tiempo de compilación es algo muy interesante, también se está estudiando activamente en teoría durante 10-15 años y casi con certeza caerá en muchos idiomas, principalmente los de tipo estático, porque el sistema de tipo expresivo debido a este desarrollo aumenta significativamente.
Es cierto que hay un inconveniente. Resulta que escribir programas puede ser demasiado complicado. Parece que los tipos controlan todo, pero la escritura es muy difícil, por lo que a veces piensas que con estos tipos dependientes, toma algún tipo cualquiera y prográmalo.
Artyom : Lo hacen aquí.
Vitaliy : Esto también se puede hacer con un gran deseo, solo a veces no hay a dónde ir. Cuando sale del servidor, no entiendo qué, y hasta que inicie el programa, no lo sabe, todavía tiene que usar esas cosas, incluso en Haskell, no hay lugar a donde ir.
Cómo desarrolla Vitaly Haskell
Artyom : es gracioso. De vuelta a Haskell. Usted es miembro del comité Haskell 2020. En Podlodka, dijo que no estaba haciendo nada allí, pero en una entrevista mencionó que todavía estaba trabajando en familias simples y de funciones limitadas. ¿Qué otras cosas específicas implementa, supervisa o participa en la implementación de, quizás, el nuevo estándar de Haskell?
Vitaliy : Estos son dos comités diferentes. Tengo dos comités. Uno es Haskell 2020, en el que nada sucede realmente, es un comité muerto. Su propósito es escribir un estándar de idioma, y ciertamente no se escribirá. Suena mejor: "Comité para el desarrollo de un lenguaje estándar", pero no funciona.
El segundo comité se llama "Comité de Supervisión del Compilador GHC", el Compilador Glasgow Haskell. Llevo un poco más de un año, su tarea es mucho menos ambiciosa. Este comité considera características, sugerencias para cambiar el compilador y la versión del lenguaje que se implementa en este compilador. Hay un Haskell estándar, pero hay un Haskell implementado por un compilador específico. Aquí hay un ejemplo de tal extensión de lenguaje: "familias de tipo simple". Este es un intento de facilitar la programación a nivel de tipo agregando controles adicionales.
Es cierto, tengo que decir que hay un entorno bastante libre, es decir, probablemente no seguí ningún accesorio durante todo el verano y le debía mucho tiempo a este comité, planeo volver a esto.
Mi tarea allí es esta: la redacté: hay una propuesta descrita, tengo que buscarla, tal vez aconsejar al autor que finalice algo y finalmente ir al comité con una propuesta para recomendar la inclusión en el compilador o rechazarla. Después de presentar esta propuesta, el comité discute y toma una decisión: todo se decide colectivamente allí.
Una de las oraciones que debo está relacionada con el guión bajo en las anotaciones estándar. Cuando no puede especificar el tipo por completo, es decir, hay agujeros allí, y hay una propuesta para reformar este sistema para analizar de alguna manera todo de manera uniforme. Los agujeros pueden estar en anotaciones estándar, en la implementación de funciones. Se propone un cierto enfoque unificado.
Este comité considera cambios estrechos en el compilador.
Artyom : También tenemos un comité de estandarización: TC39. Al principio, llega un cierto y está buscando un campeón. Un campeón es una persona de un comité que está lista para supervisar este sitio. Entonces, que yo sepa, tenemos una graduación por etapa. Hay 4 etapas en las que se mueve la función. Cero es cuando solo hay una propuesta, una es cuando se encuentra un campeón y se describe una API de alto nivel, y así sucesivamente. El cuarto ya está ingresado en el idioma. La persona que hizo la propuesta y el curador participan en las reuniones de este comité y promueven esta proposición. ¿Cómo va esto contigo? ¿Es solo un comité que luego decide internamente?
Vitaliy : Toda nuestra actividad está abierta, se lleva a cabo en GitHub y parcialmente en listas de correo abiertas. Entra el autor de la propuesta, mientras estamos considerando la propuesta, la implementación no nos interesa mucho. Puede ser, puede no ser, no lo analizamos de ninguna manera, nada depende de ello. Primero, hay una discusión por parte de la comunidad en general, todos pueden comentar sobre esta propuesta.
Luego, cuando se estableció, el autor lo presenta al comité, es decir, le pide al comité que lo considere. El secretario del comité nombra a un pastor que lo supervisará. Él mira, analiza, quizás ofrece mejoras, o viceversa, trata de justificar por qué esto no tiene derecho a existir, después de lo cual presenta una propuesta para rechazar o, tal vez, enviar para su revisión o aceptación. El comité discute, toma una decisión.
Y cuando el comité decide que estamos de acuerdo con este sitio previo, y pasa al estado de aceptado, en principio, cualquiera puede asumir su implementación. Hasta este punto, puede que no haya implementación, solo tomamos una decisión; sí, sería bueno tener esa característica en el lenguaje o compilador, y tenemos una lista de subnodos aceptados, pero no implementados.
Además, esto ya no es tarea del comité, entonces cualquiera hace una solicitud de extracción al código fuente del compilador, hay ingenieros, el equipo se cruza parcialmente con el comité, aquellos que ya decidirán si esta solicitud de extracción es aceptada o no.
Dado que el comité acepta aceptar esto, es decir, en principio, es necesario aceptar la solicitud de fusión, pero hay preguntas de ingeniería, no está codificada allí, el equipo que está desarrollando directamente el compilador resuelve algunos problemas de rendimiento. Este ya no es nuestro trabajo.
Alexei : Resulta que ahora Haskell tiene estándares bastante antiguos. Veo que hay Haskell 2010.
Vitaly : Sí, 2010, muy viejo. Ha habido varios intentos de escribir uno nuevo. Hubo una idea de emitir estándares cada año, pero, desafortunadamente, todo falló. En 2016, se convocó un comité para 2020, pero tampoco hizo nada. Hay varias razones de diferentes grados de dificultad, por qué este trabajo no está en curso. Sí, el último estándar de 2010, no hay uno nuevo y no es visible que aparezca.
Sobre cursos y nuevos proyectos
Artyom : Volvamos a su actividad principal, a la enseñanza. Te conocí personalmente en el curso de la teoría de categorías, que realmente me gusta. Dices que no te gusta. ¿Qué otros cursos tienes de los que podrías estar orgulloso y de los que crees que sería bueno conocer? Por ejemplo, el curso puede haber sido con jambas, pero en principio, el programa narrativo en sí es muy bueno.
Vitaly : En primer lugar,
he publicado
en YouTube todos los cursos que tengo. Ahí tengo un curso sobre Idris: este es un lenguaje de programación con tipos dependientes, e incluso dos versiones, lo leí dos veces. También tengo un par de cursos sobre el compilador de idiomas Haskell allí. Uno está dedicado a las cuestiones teóricas del modelo. No recuerdo exactamente el nombre, pero se trata de cómo funciona la teoría de tipos directamente en el compilador de Haskell.
La idea es simple: todo el código de Haskell se compila en un cálculo λ bastante simple, el llamado sistema F con pequeñas extensiones. Esto está realmente en el código del compilador, y el curso se enfoca en cómo estos elementos de la teoría de tipos se usan directamente en el compilador.
Y hay un curso en el que generalmente cuento sobre la historia de la inferencia de tipos y cómo se organizó la inferencia de tipos al principio, cuando se inventó en los años 60, antes de que la inferencia de tipos se arregle en el idioma Haskell, cuáles son las dificultades cómo funciona todo
Hay un curso corto que enseñé en la escuela de verano de matemáticas. Allí, de vez en cuando, como me dijeron, toman cursos de informática para que los niños descansen. , , , , : . — — . , , , .
, , . - , , , , , , - . , - , . , , - - . .
. -, , , , , . , . , - , -, - , , . - , , - , . . , , .
, , , . , , , , , , .
: - ? , , . , , , , - .
: Computer Science Club. , , , . , .
10 . « GHC Haskell: ». GHC, , 40 , 10 . : .
, Haskell, , . , , . .
, 1-2 . . , ,
. , : , — , - , . , .
, , , . , , . , .
, , , , , . , .
: , JetBrains - , . ? , - ?
: JetBrains , Haskell , JetBrains Haskell- , .
: Haskell JetBrains?
: Haskell c JetBrains, . , .
: Haskell JetBrains?
: - Haskell JetBrains? , .
: , . ()
: . , Java, Haskell.
: , JetBrains?
: JetBrains Education. JetBrains Research — , Education — .
JavaScript-
: , , , JavaScript? , , , Elm, Haskell.
: -, . GHCJS , , , . Elm , Haskell, . , , - .
, , , . JavaScript .
, Idris — Idris PHP, JavaScript, . . , , JavaScript Haskell .
, - , — , — , .
— , , , , . , . ,
HolyJS , , , , , . — , .
, λ- , — λ-, , , . , λ-, , .
1936 , — . , .
: , ? Swift, , enum , Union, ?
: , , . : , , . , , Python , , .
, , Python, . , , , .
, , , , , . C#. C# : -, Microsoft Java, , ,
, Delphi, #, C# , Haskell, .
, . , JetBrains, Kotlin, . Kotlin, C#, Swift Apple, . , .
++ - , , , - , , , . , , , JavaScript , . , , .
, , .
: -, , , Mozilla Rust.
: , Mozilla — , , - open source-, . . , Rust , . , Rust , - , .
, Twitter — - Microsoft, , , C++ Microsoft Rust. , . , Rust. , , , , . , .
Rust , - , .
: ! , , , , , — , . , , , - , ?
: , , . , . -, , . . , , — . — , , . .
— , , -, , . , .
, , , . , , . . , , , , . - . . .
: ? , , , , , ?
: , . , , , , . , - , , , , . , . , — . , , .
, — .
: HolyJS ? , - ? , .
: , , , , , . , , . , .
, , AppsConf. . . , .
, , , . : « , ?». - , , : , , Twitter , Google . , .
. , , , , , , , .
, , , . — , .
¿El programador necesita libros?
Artyom : Una pregunta más, tal vez caótica. ¿Has escrito un libro sobre Haskell llamado
Haskell in Depth ?
Vitaliy : Desafortunadamente, el libro no fue escrito en el proceso. Esto se llama un "programa de acceso temprano". Y ella, desafortunadamente, se ralentizó, y lentamente estoy volviendo a trabajar en ello. Alrededor de la mitad está escrito allí, y la segunda mitad está retrasada, por lo que me avergüenzo de quienes adquirieron este acceso temprano.
Artyom : Aquí hay un hecho interesante: existe una opinión en la comunidad de que los libros sobre programación, especialmente si no se trata de conocimientos fundamentales, no son muy buenos, porque la información se vuelve obsoleta rápidamente. ¿Cómo usted, como autor del libro, tiene tal experiencia? ¿Y ha considerado un problema tal que la información que proporciona en un libro puede quedar desactualizada rápidamente?
Vitaliy : Por supuesto, no entiendo cómo se escriben los libros en JavaScript; en mi opinión, esta es una tarea imposible en absoluto. Con Haskell, en este sentido un poco más fácil. Pero aquí está lo que puedo decir.
Cuando estudiamos matemáticas en la escuela, estas matemáticas también están generalmente muy desactualizadas. Estas son las cosas que surgieron hace un par de miles de años, algún teorema de Pitágoras. Quizás todavía se esté implementando, pero decir que alguien mide las alturas de las pirámides usando el teorema de Pitágoras es algo como esto, generalmente se usan ruletas láser o algo así.
Es casi lo mismo aquí. Si una persona es un gran profesional en algo y ha estado utilizando alguna tecnología durante mucho tiempo, por supuesto, no necesita un libro. Bueno, el libro no es para él y está escrito, es necesario para entrar en algún tipo de tecnología, para comenzar a entender esto. Y cuando ya ha ingresado, tiene otras fuentes de desarrollo.
Por lo tanto, me parece que los libros no irán a ninguna parte. Cuando comienzas a aprender algo, puedes, por supuesto, aprender lenguajes de programación por artículos, pero en la mayoría de los casos el resultado no funcionará bien. Muy a menudo, esta es la transferencia de sus ideas sobre otro lenguaje de programación a uno nuevo. No reconoce las construcciones idiomáticas para este lenguaje y no sabe cómo usarlo correctamente.
Así que al principio es mejor tomar el libro, ordenarlo y obtener la base. Que no describa las últimas versiones de las bibliotecas, que se agregue algo al idioma, todo es posible ponerse al día. Para obtener la base, en mi opinión, todavía necesitas un libro. Esto es para todos los lenguajes de programación, incluso para JavaScript. De todos modos, necesitamos algún tipo de estabilidad, como un punto de referencia, al que pueda referirse.
Por cierto, este es uno de los objetivos al escribir un estándar de idioma Haskell para crear un punto tan estable en la historia del idioma mediante el cual puede escribir un libro. Además, de una forma u otra, el lenguaje puede desarrollarse, pero hay un estándar y cualquier estudiante puede enfocarse en él.
Es interesante cómo los libros desempeñan el papel de un estándar para muchos lenguajes de programación. Por ejemplo, Straustrup escribió un libro sobre C ++, y este es un punto al que siempre puede referirse. C ++ ha avanzado mucho, pero al aprender el lenguaje, es muy posible centrarse en esta versión, que describe Straustrup.
Artyom : Usted planteó un tema interesante sobre los recursos que las personas necesitan, que no aprenden el idioma, pero quieren profundizar y seguir adelante. Puede aconsejar algunos recursos que utiliza para estudiar y recursos que sería bueno estudiar para que un ingeniero se sumerja en una teoría. ciencia de la computación, en la teoría de tipos o, como dijiste, ¿eliminar cierta ignorancia de un ingeniero?
Vitaliy : Es difícil para mí dar un ejemplo, no puedo decir en absoluto que tenga alguna fuente regular de información. Quizás la fuente más importante para mí es Twitter. Resulta que todo me viene a través de Twitter. Me aparecen algunos enlaces interesantes, los guardo para mí y los leo periódicamente. Tengo la sensación de que al menos en Haskell no existe esa fuente, pero hay muchas personas respetadas que escriben cosas sensatas.
De alguna manera intenté usar Reddit regularmente para este propósito, pero de alguna manera no funcionó para mí, simplemente no tengo tiempo suficiente para seguirlo. Pero en Twitter, de todos modos, todo lo que aparece tarde o temprano viene a mí. Rápidamente miró, curiosamente - guardado, luego leer.
Y, por lo tanto, en general, recomendar algo en el campo de las ciencias de la computación o TI, para ser honesto, no estoy listo, no conozco ese sitio o recurso. Para aquellos involucrados en lenguajes de programación, una fuente importante es el sitio
http://lambda-the-ultimate.org . Todas las cosas más interesantes aparecen allí y se está discutiendo. Esta es una lectura obligada para aquellos interesados en la teoría de los lenguajes de programación.
Qué leer al programador
Alexei : Dices que los libros no caducan. ¿Hay una lista de cosas imprescindibles para leer o solo tus libros favoritos para recomendar? Estoy hablando de teoría de la programación, sobre alfabetización de ingeniería general.
Vitaliy : Periódicamente me piden que haga una lista, no emprendo tal trabajo, esta es una tarea muy difícil.
De acuerdo con la teoría de los lenguajes de programación, para comenzar a moverse en él, está el libro de Pierce
"Tipos en lenguajes de programación". Esto generalmente es un manual para comenzar con los tipos. Probablemente, su primer tercio sería útil para todos los programadores.
Mi colega y yo estábamos traduciendo un libro llamado
Introducción a la teoría de los lenguajes de programación . Es muy pequeño y explica la semántica formal, la inferencia de tipos, las cosas teóricas de la compilación. Una introducción tan útil a los lenguajes de programación.
Hay un libro de Charles Petzold
"Turing anotado" . Este es un género increíble: el autor tomó un artículo de Turing en 1936, donde Turing describió lo que más tarde se conoció como una máquina de Turing, y escribió un libro grueso que explica este artículo. Y el artículo en sí es páginas 15. Además, hay una historia de la vida del propio Turing, los antecedentes de esta tarea, cómo sucedió todo. Sección por sección, da un fragmento del artículo y una explicación de lo que significaba allí.
Si leemos el artículo ahora, será muy difícil para nosotros. Pero este libro de Petzold es sorprendente, recrea todo el contexto y describe el artículo en sí. Recomiendo esto a todos, esta es una lectura muy interesante, amplía la mente. También se trata del cálculo λ, porque todo está cerca y se plantean preguntas filosóficas relacionadas con los cálculos.
Además, por supuesto, desde un punto de vista tecnológico, soy un gran admirador del libro de
McConnell "Código perfecto" . Me parece que esta también es una lectura importante. No puede leer todo en una fila, simplemente ábralo en páginas aleatorias, lea un par de páginas y ciérrelo. Esto se trata de cómo escribir código.
Es cierto, recientemente hablé con varios trabajadores móviles, dicen que es un libro estúpido en el que no hay nada útil. Pero se trata de cómo escribir dicho código para que dure mucho tiempo, para que pueda ser soportado, cambiado. Tal vez realmente no tienen esas necesidades.
Sí, y no hay Swift, ni Kotlin, algún tipo de Java allí, diferentes ejemplos en diferentes lenguajes de los que los programadores modernos ya no hablan realmente de nada. El libro comenzó dos milésimas. Pero creo que para cualquier programador esta lectura es muy útil. McConnell sigue siendo bueno en que confirma todo con la investigación, dice: “Entonces, hemos hecho tal y tal estudio, pero tal y tal, y aquí están los resultados. Discutamos juntos cómo escribir código para que sea bueno ".
Aquí, tal vez, suficiente de tal lectura.
Artyom : Para uno más especializado, le preguntaré: usted recomendó la "Implementación del compilador moderno", que está disponible en tres versiones:
Java ,
C y
ML .
Vitaliy : Sí, este es un libro sobre compiladores. No sé si todos necesitan leerlo, es más probable para aquellos que estén interesados en compiladores. Pero sí, me gusta, es pequeño y, trabajando con él, realmente puedes escribir tu propio compilador. No estoy seguro de que todos los programadores necesiten escribir su propio compilador, pero si de repente sientes curiosidad, los libros de Appel son realmente interesantes, pero ya algo limitados.
Ahora no puedo recordarlo todo. Periódicamente, algo emerge a la superficie, porque en algún momento leo mucho. Por ejemplo,
"La estructura e interpretación de los programas de computadora" también es un clásico útil para leer y hacer ejercicios. Incluso si no estoy del todo de acuerdo, pero la lectura en sí es muy útil.
Vitaly Bragilevsky vendrá a la conferencia HolyJS 2019 Moscú del 8 al 9 de noviembre de 2019 con un informe "JavaScript al servicio de la informática teórica". Las entradas se pueden comprar en el sitio web oficial .