Get best of the week

Do Andrei Breslav atormenta los errores de diseño de Kotlin que no se pueden arreglar // Estamos condenados # 6



Andrey Breslav apenas habla de Kotlin recientemente. Dos veces lo llamé para una entrevista, y las dos veces me pidió que no discutiera cuestiones técnicas.

Por un lado, estoy molesto. Entiendo que todos los demás les preguntaron, pero yo no. Probablemente soy el último periodista puramente humanitario en Rusia que quiere contarle a la gente sobre el lado de la ingeniería de la industria, y no solo sobre los millones de hombres de negocios exitosos criados; y quién no preguntará a este patético "bueno, explique a mis oyentes con los dedos cómo funciona para que entiendan".

Por otro lado, los personajes de las personas son comprensibles e interesantes para mí personalmente más que la tecnología, y me alegro cuando un desarrollador genial está listo para hablar de sí mismo como persona, no como una unidad de trabajo.

Tomé la primera entrevista de Breslav hace un año, pero nunca lo liberé. El segundo fue llamado al podcast junto conFillpackart. Reflexionó sobre los éxitos y errores en Kotlin, luchó con nuestros estereotipos sobre el poliamor, escuchó quejas sobre la vida y adjuntó una poderosa conferencia con la justificación de la tipificación dinámica.



Algunas citas del podcast

¿Por qué ya no es interesante hablar sobre desarrollo?


He estado haciendo Kotlin durante diez años, y durante los últimos seis años todos quieren hablar conmigo solo sobre él. Todos tienen las mismas preguntas sobre Kotlin, estoy terriblemente cansado de responderlas. Sin ofender: es muy difícil encontrar una pregunta que alguien no haya hecho en estos seis años. Parece que esto es simplemente inútil: ya respondí, todos los materiales se pueden encontrar y leer. Estoy harto de terriblemente, solo terriblemente.

Necesito hablar sobre otra cosa. Ahora estoy más interesado en temas humanitarios: psicoterapia, poliamor, equilibrio de género. Realmente quiero darme cuenta de estos aspectos de mi personalidad. Implementé los aspectos de ingeniería, también quiero otros.

A menudo me encuentro hablando de áreas en las que estoy poco versado. Inmediatamente empiezo a sacar conclusiones: tengo esa propiedad. No tengo la paciencia para ordenar cuidadosamente, leer literatura, asegurarme de que esto no fue lo primero que se me ocurrió. Pero hablando de cosas fuera del desarrollo, no tengo la sensación de estar completamente fuera de lugar. Por el contrario, parece que puedo traer una nueva apariencia.

Sobre la actitud de Kotlin hacia el éxito


Sí, creo que este es un logro que parece genial para muchos. Después de eso me tranquilicé un poco.

Siempre he tenido confianza en mí mismo: esto es tanto una fortaleza como una desventaja. Después de todo, todavía era necesario encajar para hacer un proyecto así, para convencerse de que puede hacerlo. Y no tuve que persuadir en absoluto. Estaba seguro de que sí, por supuesto, vamos a hacerlo. Tenía la sensación de que no podría volar. Pero qué hacer: no había ninguna pregunta.

Mi autoconfianza solía ser más inquietante. Pensé que sí: "ahora estoy bien, de repente todos los demás no entenderán esto". Ahora tengo menos ansiedad y ni siquiera estoy seguro de que esto se deba al éxito de Kotlin. Este es un efecto acumulativo de diferentes cosas.

Era como la psicoterapia, esto también eliminó algunos tipos de ansiedad. Me equivoqué tantas veces en diferentes cosas y descubrí las verdaderas consecuencias de los errores. Parecían ser catastróficas, pero estaban lejos de lo que temía. Y en general no son lo que esperaba: las consecuencias funcionaron en lugares completamente diferentes.

La calma vino de comprender el alcance real de los riesgos.

Son defectos de diseño de Kotlin que no se pueden arreglar


No hay tales errores que no dormí por la noche. Pero hay cosas que surgen, y cada vez es una broma. Hay muchos lugares donde era necesario hacer algo pequeño de otra manera o convertir algo importante en la otra dirección. Pero entiendo que este es el caso con todos.

Cualquier persona que haya creado un sistema complejo grande que no se puede rehacer porque tales personas lo usan tiene tales pensamientos. Especialmente como en mi caso, si este sistema fue el primero en su vida.

Hay personas que crearon un idioma, un compilador, una máquina virtual, una base de datos, cualquier sistema complejo, y no ha ganado popularidad. Luego, otro, tercer y único cuarto intento despegó. Y cuando el cuarto intento, ya hay una comprensión de dónde mirar; qué es importante y qué no importa. No solo en cosas que pueden entenderse matemáticamente, sino en términos de percepción por parte de otros.

Es más fácil para esas personas en el sentido de que ya saben mucho de antemano. Y no lo sabía, como tantos que tuvieron sistemas exitosos primero. No sabían dónde estaban colocadas las minas. Solo bultos rellenos.

Me parece que el usuario de cualquier sistema popular mira y piensa: "Señor, ¿por qué se hace esto aquí?" Sí, porque de quien dependía todo, una vez hace mucho tiempo, simplemente no lo adivinó. Bueno, sucede: una persona no lo ha adivinado.

¿Qué error sería corregido en primer lugar si hubiera regresado al pasado?


La mierda más importante: no comencé a reclutar un equipo desde el principio.

Era necesario reclutar un equipo. Mucho de todo depende de ello. Kotlin se lanzó en el año 16, y fue muy tarde. Salió después de Java 8. Muchas cosas muy importantes desde el punto de vista de la promoción del lenguaje habrían sido completamente diferentes si no hubiera sido tonto en los primeros años y hubiera escrito un equipo.

Otra respuesta es aún mejor: tenía que buscar un mentor para la gestión de proyectos. Entonces tenía 26 años, de alguna manera sabía cómo escribir código, entendía mejor sobre lenguajes de programación que muchos, pero no sabía cómo administrar a las personas en absoluto. Tenía que buscar a una persona que supiera y pedirle que me lo dijera.

Eso sería lo mejor que podría hacer, y luego Kotlin sería mucho más genial de lo que es ahora.

More articles:


All Articles