"¿Cuántos espectadores vendrán a tu charla en Java?" Depende de si Venkat está actuando en la sala adyacente al mismo tiempo ".
Esta es una broma con una gran cantidad de verdad: en el mundo de Java,
Venkat Subramaniam es uno de los oradores más famosos, que es realmente capaz de atraer a los espectadores de otras salas en las conferencias. Se ha estado moviendo sin descanso por el planeta y recientemente estableció un récord impresionante, cuando cumplió 50 años hablando en un año antes de 50 grupos de usuarios de Java diferentes.
¿Cómo es cuando tu carrera en Java no es "estar sentado en la oficina", sino "moverse constantemente"? ¿Y qué piensa Venkat sobre los problemas actuales de Java? En octubre, llegará a San Petersburgo, y en previsión de esto, (
phillennium ,
olegchir ) lo entrevistamos en detalle, donde comenzamos con "la vida en el avión" y consejos para oradores principiantes, y luego pasamos a la tecnología.
Como Venkat responde en detalle, el texto es largo. Si lo desea, puede pasar inmediatamente a la segunda parte:
Para toda la vida
- Comencemos con su recorrido, durante el cual visitó 50 grupos de usuarios de Java, casi nadie ha hecho esto antes. ¿Cuáles fueron tus impresiones?- Lo más interesante para mí fue darme cuenta de que, en diferentes culturas en diferentes partes del mundo, las personas que hablan diferentes idiomas, a pesar de todas estas diferencias, están unidas por la programación como un hilo de conexión único. Cuando comenzamos a hablar sobre programación, resulta que los problemas que enfrentamos todos los días son los mismos. Este fue un gran descubrimiento para mí: puedes conocer a un programador en cualquier aeropuerto del mundo y definitivamente encontrarás temas comunes para conversar. Puedo enumerar infinitamente casos en los que estuve involucrado hablando de Java en el otro lado de la Tierra.
Por lo tanto, la experiencia con estos grupos fue muy útil para mí. Administrar un grupo de usuarios es muy difícil ... No quiero decir "trabajo" porque no es trabajo, pero hay que gastar mucho esfuerzo. Tengo un gran respeto por todos los líderes que reúnen estos eventos una y otra vez cada mes. Los diferentes grupos tienen diferentes dinámicas: algunos tienen 20 o 30 personas en las reuniones, otros 200 o 300. Sin embargo, el número, de hecho, no juega un papel, porque lo principal es la pasión de los desarrolladores que vienen a estas reuniones, su interés en tecnología y su deseo de aprender. Así que tuve mucha suerte de tener la oportunidad de reunirme con estos grupos, y estoy muy agradecido por ello.
- Y con la similitud que mencionó, ¿los grupos de usuarios en diferentes partes del mundo tienen diferencias locales notables?- Estas diferencias son sorprendentemente pocas. Noté que en algunas regiones se da más preferencia a los frameworks pesados, y en otras a soluciones más livianas. Pero, como regla, todas estas características son superficiales, y las preguntas y problemas profundamente arraigados, por el contrario, son universales. Sinceramente, me gustaría decirles que en algún momento en el mapa las personas hacen cosas completamente diferentes a las nuestras, y que todo es interesante e inesperado allí, pero no puedo decir eso.
Todos nos esforzamos por la complejidad, nos arrastra, y cuando se arrastra, comenzamos a luchar contra ella. Esta es una tendencia general en casi todas partes. Otro problema importante del que nadie ha escapado son los estrictos requisitos del negocio y la falta de tiempo para trabajar en la calidad. Puedo hablar de algún ejemplo a personas en cualquier parte del mundo, y después de mi historia me preguntarán: "¿Trabajaste en nuestra empresa?" Nuestros problemas son tan profundos y universales que, aparentemente, son comunes a todo el mundo. Lo que involuntariamente nos hace pensar en nuestra esencia humana común, en psicología y filosofía, que finalmente seguimos. No importa cuánto nos imaginemos como geeks que recurrieron a la tecnología, no debemos olvidar el aspecto humano en el desarrollo de software. Aparentemente, él es una fuerza unificadora y universal.
- Me gustaría preguntar sobre un estilo de vida de "campamento". Cuando te sientas en la oficina, puede no ser obvio si te gustaría una vida como la tuya. Por ejemplo, para muchos, el desfase horario es un problema, y debido a esto, los vuelos constantes pueden parecer una pesadilla. Pero quizás con la práctica, ¿te adaptas a esto?- Para responder a su pregunta, recordemos la integración continua. Si un equipo realiza la integración una vez al mes, sugieres que lo hagan todo el tiempo, te considerarán loco. En esto, las relaciones de viaje se asemejan a la integración continua y la entrega continua: si las manejas mucho, tu enfoque hacia ellas cambia.
No me malinterpreten, no estoy orgulloso de mi forma de vida, en mi opinión, no vale la pena vivir así. Siempre digo que en los viajes menos me gustan los viajes en sí. Sentarse en un avión es agotador, el cuerpo se desgasta y, con la edad, estos problemas no van a ninguna parte. Pero cuando llego a mi destino, cuando me encuentro con otros desarrolladores, veo su pasión por la tecnología, su entusiasmo, tengo la oportunidad de compartir esta pasión, aprender algo nuevo y ayudar a aprenderlo, todas las dificultades se compensan con interés.
Si hablamos sobre el cambio de zonas horarias, entonces no me molesta en absoluto. Debido a los vuelos constantes, en cierto sentido no tengo un tiempo constante de "casa". Tengo una regla: siempre me levanto a la misma hora local, alrededor de las 3.30 de la noche, y el cuerpo entra rápidamente en un cierto ritmo. Y, por supuesto, el café siempre es muy bienvenido.
- A muchas personas les gustaría ver el mundo, pero generalmente realizan viajes turísticos y no viajes de negocios. ¿Puede mirar las ciudades o por falta de tiempo solo en las salas de conferencias?- Sí, en parte hay un problema con el tiempo. Pero, además de esto, debido a los vuelos constantes, tengo algunos principios a los que me adhiero. Si el viaje está conectado con el trabajo, entonces no hago nada más que trabajar. Intento pasar el mayor tiempo posible con los desarrolladores. Cuando tengo un sábado o domingo gratis, por ejemplo, en Europa, generalmente lo paso en un grupo de usuarios. Me da mucho gusto comunicarme con los desarrolladores, por lo que en mis viajes de negocios casi nunca voy a lugares de interés.
Pero cada año, durante cuatro o seis semanas en el verano, viajo con mi familia y hacemos turismo. Este es nuestro tiempo para un descanso conjunto, y en los meses restantes me concentro en el trabajo.
Además, mi enfoque me permite prestar la máxima atención a varios eventos de la comunidad, lo que también me da un gran placer. Esto consume mucho tiempo y es una especie de compromiso, pero me conviene. La vida es a veces demasiado estresante, y me alegra la oportunidad de distraerme y escuchar a los desarrolladores que pueden no tener la oportunidad de asistir a una conferencia o curso de capacitación. Además, creo que este es también mi deber profesional, por la razón de que fueron estas cosas las que me inspiraron en mi juventud. Visité grupos de usuarios, escuché presentaciones y soñé en mi tiempo también de presentarme. Si, a su vez, logro inspirar al menos a una persona de la misma manera, esta vez será bien aprovechada.
- Última pregunta de viaje. En la película "Up in the Air", el personaje de George Clooney, que vuela constantemente entre ciudades, conoce muchos trucos para mejorar la eficiencia del viaje: cómo hacer cola, cómo empacar equipaje, etc. ¿Quizás también tenga algún conocimiento no obvio que le gustaría compartir?“Me da vergüenza admitirlo, pero a veces envío ropa entre ciudades en FedEx, porque simplemente no tengo tiempo para volar a casa y llevarme ropa para la próxima semana. A menudo, cuando llego al hotel, mi ropa ya está allí, y cuando me voy, la envío a casa. Afortunadamente, esto no sucede con demasiada frecuencia, tal vez tres o cuatro veces al año, cuando estoy en camino durante tres semanas seguidas. Hubo un momento incómodo cuando mi esposa tuvo que ir al aeropuerto a entregarme las maletas, porque solo tenía media hora entre vuelos. Pero con el tiempo, realmente aprendes a hacer algunas cosas de manera más eficiente. A veces me sorprende cuando la gente dice "Necesito empacar" porque mis cosas se recogen todo el tiempo.
Hablando de eficiencia, tengo al menos una ventaja: soy una persona con una sola tarea. Vivimos en el mundo de Facebook, Twitter y varios mensajeros, nos distraen constantemente. Trabajé duro para reducir este efecto, porque los minutos se convierten en horas, las horas se convierten en días, los días se convierten en semanas, y tarde o temprano te das cuenta de que no podías lograr lo que querías. Por lo general, tengo un diario en el que escribo las cosas que deben hacerse para cada viaje. Por lo tanto, tengo un horario para cada día (por ejemplo, para el 7 de noviembre o el 8 de octubre), y mi teléfono me recuerda cada tarea en el día correspondiente. Durante un vuelo de ocho horas, puedo escribir la mayor parte de un capítulo del libro o preparar un ejemplo para el curso. Por lo tanto, los vuelos para mí son un momento extremadamente efectivo. Nunca necesito entretenimiento adicional durante el vuelo: suficiente entretenimiento relacionado con la depuración de código es suficiente. Por lo tanto, un viajero profesional (si dicho término es generalmente aplicable) pasa el tiempo en vuelo de manera muy diferente a un turista.
- Probablemente, debido a tu fama, obtienes muchas más cartas que los desarrolladores comunes. ¿Cuánto le escriben y cuánto tiempo le lleva trabajar con el correo?- Vale la pena agregar que enseño en la universidad y recibo muchas cartas de los estudiantes. Por lo general recibo 20 o 30 cartas al día. Hace aproximadamente un año
escribí en un blog sobre uno de mis principios: "responde ahora o di cuando respondas".
Realmente valoro mi tiempo, lo que significa que valoro el tiempo de otras personas. En mi opinión, el respeto por otra persona no está en el atractivo del señor, sino en apreciar el tiempo del otro. Por lo tanto, si me llega una carta, siempre respondo dentro de las 24 horas. Pero hay momentos en que no funciona dar una respuesta completa, por ejemplo, si el organizador de la conferencia pide enviar una anotación o si un colega en la industria hace una pregunta sobre cómo resolver un problema determinado, pide refactorizar algún código o pregunta sobre el uso de un método determinado. Algunas veces la respuesta puede tomar diez minutos, y otras dos horas, pero incluso diez minutos no siempre se pueden gastar. Esto puede sonar un poco extraño, pero aún respondo en tales casos dentro de las 24 horas y escribo: Recibí su carta, trabajaré en este problema, digamos, el 2 de septiembre y le escribiré el 3. Al mismo tiempo, mi calendario se actualiza con la entrada correspondiente en el día en que tengo tiempo en el vuelo o en la tarde.
Gracias a este enfoque, mi bandeja de entrada siempre está vacía, la limpio todas las noches antes de acostarse. Así que soy extremadamente disciplinado al responder cartas. La gente a menudo se sorprende de que responda a sus cartas tan rápido, pero, por el contrario, no entiendo cómo de otra manera. No quiero interponerme en el camino de las personas, para evitar que se desarrollen. Además, considero importante decir que no. Me gusta repetir que cuanto más a menudo digas sí, peor obtendrás lo que haces. En un momento determinado, debe darse cuenta de que no podemos lograr todo en el mundo. Por eso, a veces respondo que, lamentablemente, no puedo evitarlo. A su vez, prefiero que me digan que no de inmediato, y que no tire del caucho y no lo diga más tarde. En mi opinión, esto también habla del respeto por la persona y la falta de voluntad para perder su tiempo en vano. No tienes que ayudar, pero al menos no te molestes. Por lo tanto, es importante decir que no. Así es como se organiza la vida, no intentes fingir que puedes hacer todo en el mundo. Para mí, la capacidad de responder rápida y honestamente es una señal de profesionalismo.
- Eres un orador muy experimentado. Como organizadores de la conferencia, nos encontramos con personas que no tienen experiencia en hablar en público o que tienen muy pocas. ¿Quizás tienes recomendaciones para ellos? Tuviste un consejo interesante en Twitter "para visitar la sala en la que se realizará el informe con anticipación". ¿Hay algo más?- Mis primeros informes fueron en grupos de usuarios, por eso sigo haciendo 15 informes en ellos cada año. Y recomiendo que otros comiencen con lo mismo: con un grupo de usuarios en su región, luego en un grupo vecino, y así sucesivamente.
Por muchas razones, estos informes tienen menos riesgos que en una conferencia grande: hay una atmósfera amigable, las personas acuden allí para compartir conocimientos, después de sus informes le será fácil obtener una respuesta. Puede comenzar la presentación diciendo que tiene poca experiencia en este asunto y que le gustaría saber la opinión de la audiencia. Este año tuve un nuevo informe, durante la preparación del cual experimenté mucho. Escribí sobre esto en Twitter: parece que todo se puede decir en dos minutos, pero en realidad el material no se puede poner en una hora y media. Y estoy muy contento de que la primera vez que hice este informe en un grupo de usuarios, ya que esto me dio la oportunidad de prepararlo mejor para la conferencia.
En grupos de usuarios o en la empresa donde trabaja, tiene una gran oportunidad para practicar presentaciones. Primero, recibirá críticas de sus colegas, lo que le permitirá mejorar el informe. En segundo lugar, incluso si no te dicen nada directamente, entenderás mucho cuando comiences a hablar. Creo que es posible mejorar realmente el informe desde la tercera vez. La primera vez solo intentas unir todos los pensamientos. Y esto es lo que es interesante: practicar solo no ayudará aquí, la conciencia de los problemas solo se produce al hablar con otras personas. Por tercera vez, la cadena lógica de su narración se vuelve más clara para usted, se completa. Esto no siempre se nota, pero a veces me detengo durante mi discurso por tercera vez; en este momento, me doy cuenta de lo que estaba tratando de decir en el informe que llega un momento de verdad. Entonces, la práctica es muy importante, pero no solo, sino con las personas. Esto puede dar al joven desarrollador la confianza necesaria.
Es cierto que algunos hacen sus primeros informes en las conferencias. A veces es más fácil para una persona morir que hablar en público, y son fáciles de entender: se necesitan muchos nervios. Hace dos o tres años, hablé en una conferencia. Una persona muy interesada se acercó a mí y me dijo que, aparentemente, estaba muy preocupada, a lo que respondí que realmente era así. Él preguntó: "¿Es este su primer informe?", Y le respondí: "No, probablemente diez mil, por eso estoy preocupado". Cada presentación frente a la audiencia requiere mucho estrés emocional, incluso si tiene mucha experiencia, simplemente porque le importa cómo va el informe. Hará un gran trabajo si alivia esta tensión con unos pocos informes de prueba en grupos de usuarios o en su empresa. Esto se aplica a todos los oradores, incluidos los experimentados.
- Pero, ¿hay algo en hablar en público que, por el contrario, debería evitarse?"Cometí muchos errores en mi vida que me enseñaron que las personas aprenden mejor de la experiencia". Cuando hablas con una audiencia, hay algunas cosas a tener en cuenta. En primer lugar, debe mantener la confianza en sí mismo: trabajó mucho en el tema y sabe mucho al respecto. En segundo lugar, recuerde: es imposible saberlo todo, y la ignorancia de algo no es su culpa. Simplemente significa que no tuvo la oportunidad de prestar atención a esto, y no hay nada de malo en eso. Es extremadamente importante admitir esto honestamente. Puede responder la pregunta en la conferencia de esta manera: lo siento, no puedo decirle nada, no tuve la oportunidad de estudiar este problema.
Otro punto importante es que los oyentes se pueden dividir en tres tipos. Hay personas que quieren aprender algo nuevo de usted. Otros se mantienen un poco más cuidadosos, te escucharán, pero no estarán listos para percibir todo lo que dices. Finalmente, hay un tercer grupo de personas, afortunadamente, bastante pequeño: aquellos que son hostiles y están tratando de atraparte todo el tiempo. Tarde o temprano, su informe definitivamente tendrá un desarrollador que lo interrumpirá todo el tiempo e interrumpirá el progreso del informe. En tales casos, es muy importante mantener la calma, dejar que hable y regresar la discusión a la dirección que necesita, pero, debo admitir, también soy una persona, y no siempre logro hacerlo. Puede, por ejemplo, decir: entiendo que esto es importante para usted, hablemos después del informe, este tema es importante para muchos aquí. Es cierto, muy a menudo tienes aliados en la audiencia, y cuando una persona realmente viola el curso de su discurso, se le pide que se calme. Todo esto lo digo al hecho de que es importante no estar demasiado en conflicto en tales situaciones, a pesar de que nuestra naturaleza puede resistir esto. Como un joven orador, a menudo entraba en tales confrontaciones con toda su fuerza, y esto nunca trajo nada bueno a nadie. Es necesario mostrar madurez emocional y no tratar de demostrarle nada a nadie sobre ti, entrando en este tipo de escaramuza. En cambio, en tales casos, el tema debe volver a ser interesante para el público.
También me gustaría hablar sobre algunos hábitos negativos durante las actuaciones, que, en mi opinión, los desarrolladores tienen. Para empezar, las personas deben mirar a los ojos. Entiendo que esto es muy difícil y requiere mucho esfuerzo emocional, pero debes practicarlo. Los oradores a menudo miran su monitor o, lo que es peor, la pantalla, de pie de espaldas a la audiencia. Siempre debes estar frente a la audiencia y siempre debes mirarlos. Además, se debe mantener la autoconfianza. Hablas con una audiencia de programadores, y puedes apostar a que ninguno de ellos tiene un código que funcione la primera vez. Si su demostración no funcionó durante la presentación, no hay nada de malo en eso. Todos los presentes probablemente pensarán: "Maldita sea, todo es exactamente lo mismo conmigo". Con los años, he aprendido en tales situaciones a recurrir a la audiencia para obtener ayuda con la depuración. Por lo general, los hablantes en tal situación comienzan a murmurar algo por lo bajo y tratan de resolver todas las dificultades por su cuenta. En cambio, deberías preguntarle a la audiencia: amigos, ¿puedes decirme dónde soy tonto?
Inmediatamente recibirá muchas ofertas, y muy a menudo lo ayudarán a encontrar el error. Es difícil para una persona hablar y escribir código al mismo tiempo, no tenga miedo de pedir ayuda. Para los oyentes, esta experiencia también es valiosa. Esta es una de las razones por las que visito los informes de otras personas: para ver lo que están haciendo y comprender exactamente qué no se debe hacer. En mi opinión, estos hábitos te ayudarán a refactorizar tus habilidades de orador.
Acerca de la tecnología
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?— , . , , Java — , 2000-. , , , .
, , , , , . , , 70 try-catch . , , , .
— . , , , . , , . , . , .
Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .
. Joker «Don't walk away from complexity, run» . , Joker , , .
- En el contexto de "Java menos bombástico", es imposible no preguntarte sobre Kotlin, que a menudo se llama así."Sí, eso es cierto". Y el asunto no es solo en menos pretenciosidad. Para mí, una de las cosas más emocionantes de la vida es conocer nuevos idiomas y sus capacidades. Una posibilidad en Kotlin es ejecutar una lambda en el contexto de un objeto, aunque no sea parte de la clase. Me interesé mucho cuando lo descubrí, porque la misma posibilidad está presente en JavaScript. Allí puede pasar un objeto de contexto en la llamada (lo que Kotlin llama receptor), y luego ejecutar esta función global arbitraria como si fuera una función de algún objeto. El hecho de que esta característica esté en JavaScript no es sorprendente, ya que este lenguaje es dinámico. Pero Kotlin es un lenguaje estático, y hace lo mismo, respetando la seguridad de los tipos. La falta de pretenciones, por supuesto, es una gran ventaja del lenguaje, como lo es el hecho de que genera una parte significativa del código automáticamente, por lo que no podemos escribir las mismas plantillas una y otra vez. Pero los beneficios no terminan ahí, ya que esta característica le permite crear DSL internos.
La ciencia y las matemáticas me llevaron a la programación, pero 30 años después sigo siendo programador debido al hecho de que esto es arte. Nuestro campo combina ciencia y arte, no hay forma de evitarlo. La capacidad de hacer que el sistema simplemente funcione no está limitada, aquí puede hacer una analogía con la escritura de poesía: pídale a dos personas que escriban sobre el amor, y cada uno escribirá a su manera. El código para cualquier tarea se puede escribir de muchas maneras diferentes. Esto es lo que me atrae a idiomas como Kotlin y muchos otros: la capacidad de expresar algunas de estas ideas, dar flexibilidad y ligereza al código. Puede pensar mucho menos sobre la sintaxis del lenguaje y más sobre el pensamiento que desea transmitir.
- La calidad del código es de gran importancia para usted. Parece ser importante para todos, y parece que todos quieren escribir mejor, pero se sabe que una parte importante del código existente tiene problemas. Por lo tanto, la pregunta es: para que sus colegas no lo odien por su código, solo necesita autodisciplina, ¿puede dar alguna recomendación específica?"Estoy convencido de que la única forma de escribir código legible es leerlo". Cuando me dicen que el código es legible, pregunto: ¿quién lo leyó? Si el propio autor lo leyó inmediatamente después de escribir, esto no cuenta. Por lo tanto, creo firmemente en la revisión de código. Quiero aclarar: me opongo a traer un equipo a una habitación con una pantalla grande, mostrar código y criticarlo. Esto inevitablemente conduce a quejas, como okhayanie público nadie es bueno.
Debemos admitir honestamente: todos escribimos códigos incorrectos. Estoy orgulloso de admitir: mi código apesta, no sé cómo escribir un buen código. Si me pregunta cómo encaja esto con mi charla sobre la calidad del código, le responderé: escribir código es un proceso con innovación constante, y cuando intenta implementar alguna idea, la calidad del código no le molesta demasiado. Siempre es necesario volver y refactorizar, e incluso cuando hago esto, por lo general, nada funciona para mí. Pero a lo largo de los años, me di cuenta de que, aunque mi propio código es base, puedo encontrar fallas en el código de otra persona. Por lo tanto, en lugar de pretender que mi código ya es tan excelente, lo escribiré lo mejor que pueda y se lo daré para su verificación, mientras que mientras tanto tomaré el código de mi colega y lo comprobaré. Como resultado, tanto mi código como el código de mi colega serán de mayor calidad.
Es muy importante renunciar al falso orgullo. Siempre les recuerdo a los desarrolladores que son parte de un equipo, no tiene sentido competir entre ellos y descubrir quién es más genial, no. Estoy listo para admitir honestamente que mi conocimiento es bastante limitado, pero lo que sé, lo sé bien. Y mi colega también tiene un conocimiento muy profundo en alguna otra área. Juntos nos hacemos más fuertes cuando estamos listos para aprender unos de otros. Por lo tanto, siempre sugiero verificar el código del otro, y el orgullo extra es completamente inútil aquí. Deben ser honestos el uno con el otro, esta es una de las cualidades más importantes de un buen equipo. La honestidad no debe ser castigada si una persona admite que escribió un código incorrecto; esto es normal. Elevamos el listón ofreciéndonos mutuamente formas de mejorar el código.
Otro punto importante: no necesita decirle a una persona que cometió un error, debe decirse qué se puede mejorar exactamente. No diga: "Dios, qué nombre tan terrible para una variable", es mejor así: "Probablemente quisiste decir que esta variable muestra la frecuencia de distribución, probablemente debería llamarse en consecuencia". Esto te ayudará a transmitir mejor tus intenciones. Esto también se aplica a la edición de libros: hable no solo de lo que debe mejorarse, sino también de lo que se ha hecho bien. A menudo olvidamos esto. Cuando edito el código de otra persona y veo un lugar que está bien ejecutado, escribo un comentario que realmente me gusta, que necesitamos hacer esto con más frecuencia y explicar por qué. Esto crea comentarios constructivos, deja en claro al desarrollador que no eres hostil hacia él y, en última instancia, mejora la calidad del código de tu equipo.
- Escribiste que usar una herramienta que te lleva al anhelo es como quedar atrapado en una relación tóxica: en esta situación, solo tienes que irte, y lo antes posible. Esto suena genial, pero a menudo el instrumento no tiene una alternativa particular, ¿y luego qué?- Una pregunta completamente justificada. De hecho, hay situaciones en las que no hay a dónde ir. Pero más bien hablé de esos casos cuando todavía hay una posibilidad de elección, y solo falta el deseo de hacerlo. En mi opinión, este es un factor significativo.
Cuando no hay otra opción, en lugar de quejarse, se deben identificar los puntos débiles: qué es exactamente lo que hace que esta herramienta sea incómoda para usted. Y luego puedes hacerlo de diferentes maneras. Puede contactar a los desarrolladores y decir: gracias por su trabajo, nos parece que su herramienta podría ser mucho mejor si prestara atención a tal o cual aspecto. O puede realizar un hackathon: reúnase el fin de semana con varios desarrolladores, organice un grupo de usuarios, dígales que pasa nueve horas al día con esta herramienta, que es terrible, y pídales que intenten agregarle algunas funciones.
Quizás no pueda resolver todos los problemas solo, pero al menos puede reunir a otras personas y resolver este problema con ellos, especialmente si sus intereses son similares a los suyos. Finalmente, si su herramienta realmente le causa tantos problemas, puede intentar escribir uno nuevo usted mismo, si tiene tres o cuatro amigos en la comunidad con la misma actitud que usted.
Entonces, en mi opinión, todavía hay alternativas. No tiene que soportar una relación tóxica. Siempre debe ser capaz de encontrar una salida, ya sea de acuerdo con un compañero y lograr un entendimiento mutuo, o irse.
- Escribiste un libro sobre lambdas, y eres conocido gracias a este libro. También lo leí, y creo que está bellamente escrito, da lo que necesita el desarrollador de la aplicación y no da nada superfluo. Como verdadero profesional, me gustaría preguntarle: ¿qué es la programación funcional para usted? ¿Podrías describirlo con tus propias palabras? Hago esta pregunta porque todos la definen un poco a su manera, y cada vez que se revelan significados ocultos que difieren de la definición estándar de Wikipedia.- Esta es una pregunta maravillosa. Mi comprensión de este concepto ha evolucionado a lo largo de los años, y ahora para mí lo más importante en la programación funcional es la eliminación de la complejidad extraña. Estamos hablando del hecho de que en la programación imperativa no solo se indica lo que hay que hacer, sino que también se prescribe en detalle cómo hacerlo. Para mí, la programación funcional es un complemento del estilo de programación declarativa, en el que indicamos lo que hay que hacer, pero no decimos cómo.
Permíteme darte una analogía primitiva: a mis mejores amigos les encantan los autos, pero no me interesan en absoluto. Cuando nos reunimos, acordamos no hablar de autos, porque queremos seguir siendo amigos. Nunca conduciré un automóvil con una caja de cambios manual: la necesidad de cambiar de marcha constantemente arruina todo mi recorrido, y lo mismo se aplica al estilo imperativo de programación. La transmisión automática hace que conducir sea un poco más fácil, pero para mí la mejor opción es que el conductor me conduzca. En este caso, solo digo dónde necesito llegar, y en el camino escribo el código en mi computadora portátil en el asiento trasero. Para mí, esta es la diferencia entre la programación imperativa y funcional. Con la programación imperativa, usted mismo conduce, necesita saber a dónde ir, cómo ir, dónde girar, dónde puede cortar. Con la programación funcional, está sentado en el asiento trasero, diciéndole al conductor a dónde llevarlo, y su atención se centra completamente en su trabajo.
¿Cómo se elimina esta complejidad extraña? A través de la composición de funciones. Al componer funciones, su código experimenta una serie de transformaciones durante las cuales los datos pasan de un formulario a otro. Además, para nosotros es importante no cómo se lleva a cabo cada uno de estos pasos, sino qué es exactamente lo que logra. Para mí, el primer aspecto de la programación funcional es la composición funcional. El problema es que muchos lenguajes en los que se implementa la composición funcional (Ruby, Python, JavaScript, Groovy, etc.) brindan elegancia y expresividad debido a esto, pero tienen un rendimiento muy bajo. La composición funcional en ellos se implementa de manera ineficiente. Creo que la elegancia sin eficiencia no es viable. El código no solo debe ser hermoso, sino que también debe funcionar rápidamente. Y aquí llegamos al segundo aspecto vital de la programación funcional: estamos hablando de computación perezosa. El resultado de una determinada función se calcula solo en el momento en que se necesita. Gracias a esto, se logra una combinación de elegancia y eficiencia en la programación funcional. Entonces, para mí, la programación funcional es un énfasis en qué hacer, no en cómo hacerlo; uso de la composición funcional como una serie de transformaciones de datos; y la capacidad de realizar estas transformaciones de manera eficiente gracias a la informática diferida.
Tenga en cuenta que no hablé sobre inmunidad y funciones de alto orden. El hecho es que son solo ingredientes para obtener el resultado que describí. Utilizamos la programación funcional no para inmunidad y funciones de alto orden, son solo un medio para lograr un objetivo superior: deshacerse de la complejidad extraña.
- Gran definición. Hoy existe un lenguaje que es el punto de referencia de lo que debería ser la programación funcional: Haskell (y posiblemente F #).Eso es correcto.
"Al menos mucha gente piensa que sí". Pero Java obviamente no es Haskell, es en gran medida limitado. ¿La programación funcional tiene sentido como disciplina cuando se aplica a Java? Después de todo, nuestro lenguaje tiene un conjunto muy limitado de herramientas para este enfoque.- Para mí, el aspecto pragmático más que la búsqueda de la excelencia es más importante. Tengo curiosidad por la perfección, pero para que todo funcione, tengo que ser pragmático. Estoy loco por Haskell y paso mucho tiempo con él, solo para descubrir cómo se resuelve una tarea en particular en la programación funcional. Pero para mis clientes no estoy escribiendo sobre Haskell. Aquí puedes hacer una analogía con la "Catedral y Bazar". La catedral es hermosa, pero la mayor parte del tiempo la paso en el bazar. La pregunta es cómo sobrevivir en este mundo. Cuando los lenguajes evolucionan y cuando intentamos combinar varios paradigmas diferentes, nosotros, como programadores, debemos ser extremadamente cuidadosos con su implementación.
No creo que la programación funcional sea imposible en absoluto en Java. En situaciones donde hay una opción, me enfocaré en el idioma más adecuado para mí. Pero nunca le diré al cliente: debe usar este lenguaje. La mayoría de las veces les pregunto qué hacen exactamente, y trato de encontrar una manera de hacer lo mismo de una manera más óptima dentro del marco del entorno que ya tienen. Creo que en lenguajes como Java, una combinación de programación imperativa y funcional es bastante posible e incluso recomendada, pero esto debe hacerse con extrema precaución. Imagine que tiene una especie de círculo de funciones puras, alrededor del cual habrá un anillo de impureza. Todo lo que quieras hacer cambiante debe estar fuera del círculo. Dentro de este círculo, puede implementar su propia cadena de funciones, pero todos los cambios deben estar fuera de él.
Esta es una de las razones por las que disfruto aprendiendo nuevos idiomas. Recientemente me familiaricé con el lenguaje Elm, que es una sintaxis de Haskell con F # intercaladas que se compila en JavaScript. Este enfoque me interesó desde el principio, porque JavaScript es un bazar. Cuando viajas a través de JavaScript, constantemente estás entrando en charcos. Gracias a la sintaxis de Haskell, Elm es definitivamente una catedral. Sin embargo, este código conciliar es posible de ejecutar en el bazar. La arquitectura de Elm es elegante, tiene un modelo (es decir, datos), hay una vista que muestra estos datos y hay una transformación, actualización. El primer principio principal es que los datos se almacenan a la vista. Cuando el usuario realiza una acción (presiona una tecla, por ejemplo), los datos de la vista se envían a la función de actualización, donde tiene lugar la conversión. Los datos son inmutables y la función de actualización devuelve datos nuevos que muestran los archivos guardados en lugar de los antiguos.
Si lo piensa, entonces exactamente de la misma manera que Redux funciona. Hay datos en él y existen reductores. Cuando los datos se envían a los reductores, obtiene una nueva copia a cambio, que guarda en lugar de la anterior. Pero si Elm y Redux operan en el mismo esquema, entonces el mismo esquema se puede implementar en Java. Podemos crear funciones puras que tomarán datos, los transformarán y devolverán una nueva copia. Al aprender de Redux y Elm, podemos hacer que la arquitectura Java sea más funcional. Estoy hablando de esto porque Redux compila en JavaScript, que es únicamente un bazar. Creo que JavaScript es el más alejado del ideal de la pureza funcional, aquí en cada paso te encuentras en un charco. Sin embargo, Redux le brinda pureza funcional en este mundo extremadamente inmundo. Este enfoque me influyó mucho porque cambió mi visión de la programación funcional y mostró que también puedo implementar estos principios en Java.
Bien, gracias. En su opinión, ¿el conjunto completo de herramientas que tenemos en Java es completo y suficiente? ¿Necesitamos algo más además de expresiones lambda, referencias de métodos, colecciones con secuencias?- En mi opinión, todavía tenemos mucho que perder. El mundo Java está en constante evolución. Recientemente tuve un diálogo con un hombre que dijo: "Escuché que estuviste en nuestra ciudad hace unos años y discutí mucho sobre genéricos", a lo que respondí: "Siempre discuto mucho sobre genéricos". Creo que en Java los genéricos se hacen muy mal. Brian Goetz está enojado conmigo todo el tiempo: "Siempre habrá alguien que se queje de los genéricos", y este, por supuesto, soy yo. En mi opinión, se puede mejorar mucho en esta área. La reforma es muy importante, en mi opinión. Se puede hacer mucho en términos de reducir la flatulencia, deshacerse del código repetitivo. El código se puede hacer mucho más fluido. Y un cierto movimiento en esta dirección ya es visible hoy. Java ahora implementa la coincidencia de patrones, lo que me hace muy feliz: realmente me gusta cómo se implementa en Scala y Kotlin. Creo que es muy importante, y me viene a la mente la analogía con una máquina de procesamiento de billetes. Si pasa un paquete de notas a través de él, las ordenará de acuerdo con el valor de cada billete. Del mismo modo, la coincidencia de patrones en la programación funciona. Pasa datos a través de parámetros que pueden recuperar datos para su procesamiento. Creo que esto podría ayudar a deshacerse de la gran cantidad de operadores de sucursales que escribimos en Java. El código se volverá mucho más expresivo. En general, creo que Java necesita muchas adiciones, pero, aparentemente, ya se está moviendo en esta dirección.
Quiero mencionar un aspecto más que es realmente curioso para mí. Crecí en el mundo de la programación tradicional. No tengo miedo de admitir públicamente que mi primer idioma fue Visual Basic. En cierto sentido, este es un buen lenguaje para el primer experimento, porque no puede ser peor. Luego escribí durante mucho tiempo en C y C ++, y la mayoría del tiempo desde todos los lenguajes que pasé con C ++. Después de eso, comencé a escribir en Java, C #, lenguajes como Ruby. En cierto momento, me di cuenta de que siempre escribía en idiomas con subprocesos múltiples. Así que conocer Nodo fue una especie de comprensión: me llevó un tiempo descubrir la programación asincrónica. , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .
— , ? JVM-, . . ?— , . , . , , : , , , , , . , . . , , , , . Big Data. , . , . , , , -. , , . , .
, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .
, . , , , . . . , , , . : , . , , .
— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .
, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .
— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .
Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.
, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .
Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .
— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .
, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
"Gracias, esa es una gran respuesta". En nuestra conferencia Joker, también hablará sobre la complejidad , para que pueda continuar la discusión allí.- Sí, lo espero con entusiasmo.