Stephen Cleary se encuentra entre los
100 mejores usuarios de Stack Overflow. Principalmente gracias a sus respuestas asincrónicas en .NET. Su vida no se limita a la programación: en Twitter, primero escribe sobre sí mismo "cristiano", y solo luego "desarrollador".
Ahora, en relación con la aparición de secuencias asíncronas, su conocimiento es especialmente relevante: como relator sobre este tema, la figura de Stephen simplemente lo suplica. Y muy pronto en DotNext lo
contará . Mientras tanto, le preguntamos acerca de todo esto: religión, desbordamiento de pila y asincronía.
Biografia
- La primera pregunta es simple: cuéntenos sobre su biografía profesional.- Me interesé por la programación bastante temprano, tenía 7-8 años. Luego en la escuela pude escribir un pequeño programa en el lenguaje Logo, y esta fue mi primera experiencia de programación. Más tarde, cuando tenía 12-13 años, guardé en mi primera computadora. Y cuando elegí Ciencias de la Computación cuando ingresé a la universidad, fue una decisión bastante obvia: ya estaba interesado en las computadoras por un tiempo tangible.
En 1998, después de graduarme de la universidad, comencé a trabajar para una empresa local dedicada a transportadores controlados automáticamente por vehículos para la industria y la automatización de otras fábricas. Siete años después, la compañía se mudó a Detroit, pero no quería mudarme allí, y desde entonces logré trabajar en diferentes compañías. Desde 2013, trabajo remotamente, el último año y medio, en Faithlife.
- Es curioso que comenzaste con Logo y ahora en una compañía cuyo producto principal se llama Logos. ¿Y qué haces exactamente allí?- Backend: servicios web a los que accede Logos y otros productos de la empresa. Faithlife tiene una gama de productos relacionados con la iglesia. Logos: para el estudio de la Biblia. Y también hay Proclaim, diseñado para aquellos que dan sermones (ayuda con diapositivas y similares). Faithlife ha hecho históricamente productos para pastores, pero ahora están agregando cosas que ayudan a la gente común.
Realizo backend, a menudo tengo que lidiar con ASP.NET Web API, y ahora estoy trabajando con Docker. En este momento tenemos parte en la nube y parte en las instalaciones, y algo no debería transferirse a la nube, pero queremos transferir algunas cosas allí, y lo estoy haciendo.
Religión
- No es frecuente que conozcas una empresa que fabrica software para "iglesias", por lo que quiero aclarar: ¿el trabajo en el backend se parece a cualquier otro lugar o tiene sus propios detalles? ¿Y los desarrolladores generalmente son creyentes y ellos mismos usan los productos de la compañía, o no?- No hay diferencias fundamentales en el trabajo: debe pensar en el diseño adecuado de la API tanto como en cualquier otro lugar. Algunos de nuestros productos (especialmente los de escritorio) han existido durante mucho tiempo, y tenemos que lidiar con las API antiguas. Y al comenzar a usar Docker, es importante pensar en la compatibilidad con versiones anteriores. En general, tenemos las mismas preocupaciones que los demás.
Aunque Faithlife fabrica productos para la iglesia, no es una compañía cristiana. Para llegar aquí, no es necesario ser cristiano: en primer lugar, tal selección violaría la ley estadounidense (sería una discriminación religiosa en la contratación), y en segundo lugar, la compañía no querría esto de todos modos.
Pero en cuanto a que los desarrolladores utilicen los productos de la compañía, se recomienda en todos los sentidos. Por ejemplo, recientemente pasé un día de entrenamiento sobre el uso de Logos. También tenemos muchas herramientas internas; en este caso, nos alienta a ir a trabajar el día en el departamento que usa su herramienta para ver personalmente cómo sucede esto.
- En tu Twitter en el campo bio hay las palabras "cristiano" y "desarrollador". ¿Estas dos partes de su identidad se cruzan de alguna manera?- Yo diría que están separados. Siempre traté de separar la vida laboral y el hogar, sin trabajar en mi tiempo libre (aunque no siempre funcionó). La iglesia es una gran parte de mi personalidad, la mayoría de mis amigos son de allí. En el trabajo, hice pocos amigos.
"Bueno, tu biografía también dice" adicto a escribir OSS ", y dar a las personas software libre suena altruista y cristiano. En este caso, no hay correlación?- Hmm, tal vez. Creo que, desde un punto de vista filosófico, realmente puedes ver la relación entre el código abierto y el cristianismo: en ambos casos, el énfasis está en el "dar a las personas" que mencionaste.
También hay un tipo de código abierto "humanitario". Yo mismo no estoy involucrado en esto; tengo bibliotecas de uso general. Pero conozco desarrolladores cristianos que han trabajado gratis en algo que afecta directamente otras vidas, especialmente en lugares con gente pobre. Por ejemplo, un software que le permite asegurarse de que las alarmas contra incendios funcionen correctamente. Aquí, por supuesto, hay una correlación.
- También está activo en Stack Overflow: ¿es esta también una forma de dar algo desinteresadamente a la comunidad?- No diría eso, para mí se siente más como "enseñar". Aunque "enseñar" también se puede conectar con el cristianismo ... Mi familia tenía muchos maestros, y continúo esto a mi manera, no como profesión, sino a través de Stack Overflow y conferencias. Así que satisfago mi necesidad de esto.
Desbordamiento de pila
- Todavía tenemos una serie de preguntas sobre Stack Overflow, la primera locura. Recientemente recibió una insignia allí para obtener respuestas en Windows Phone 8:
¿Cómo sucedió que en 2019 recibiste una insignia para respuestas sobre una tecnología casi muerta? ¿Alguien sigue haciendo preguntas sobre ella?- Para obtener una insignia, generalmente necesita al menos un cierto número de respuestas con un cierto número de votos para estas respuestas. Supongo que obtuve esta insignia porque ahora alguien votó por parte de mi respuesta, publicada hace años, y con ella finalmente obtuvo el número correcto de votos. ¡Esto es divertido porque no he visto preguntas de Windows Phone 8 en mucho tiempo!
(risas)- En SO, su reputación es de 320,000, y esto es más de una cuarta parte de la reputación del legendario John Skeet, aunque dio respuestas en un orden de magnitud menor que él. ¿Cómo conseguiste esto?- No estoy completamente seguro. Es más fácil obtener una reputación para aquellos que vinieron al sitio antes que los demás, y aunque yo estaba entre los primeros en adoptar, todavía llegué más tarde que muchos. Comencé a responder preguntas, al principio, 1-2 por día, lo que está muy lejos de John Skeet. Me concentré en el tema de async / wait, así como concurrencia y subprocesamiento múltiple, simplemente porque, de hecho, se convirtió en mi especialidad. Hace muchos años ya estaba involucrado en la asincronía, y luego fue doloroso. Entonces, cuando apareció async / wait, inmediatamente vi cuál era su significado. Así que estaba en el momento correcto y en el lugar correcto, y mi "sangre de maestro" ayudó a explicar todo en un idioma que la gente entendía. Y en el caso de Stack Overflow, resultó ser un especialista local de async / wait. Y John Skeet, bueno, no lo dijo directamente, pero supongo que me deja la mayoría de las preguntas sobre async / wait. Pero él, por supuesto, responde mucho más que yo, ¡no puede ser atrapado!
- Mirando los números de reputación, es fácil pensar "una persona toma la mitad de su vida para responder", y ¿cuánto tiempo dedicas realmente a SO?"No tanto". Reviso Stack Overflow un par de veces al día, y generalmente respondo 1-3 preguntas. Y obtengo la mayoría de los votos positivos por las respuestas dejadas hace años. Así es como SO ayuda a quienes vinieron antes: fueron los primeros en responder preguntas hace años, recibieron votos y las voces hacen que estas respuestas sean más visibles, y al final obtienen nuevos votos. Este es un efecto de avalancha que alienta viejas respuestas.
Me parece que esto causa algunos problemas, porque a veces hay nuevas respuestas que se refieren a tecnologías más modernas y, por lo tanto, son mejores, pero las respuestas anteriores no se actualizan. Pero, en general, obtengo la mayoría de los votos por las respuestas anteriores, pero todavía trato de responder las nuevas todos los días. No paso mucho tiempo en esto, solo lo hago constantemente durante muchos años.
- Cuando John Skeet voló a nosotros en DotNext, le preguntamos sobre el estado actual de Stack Overflow y cuáles consideraba que eran los problemas del sitio. Es interesante comparar: ¿qué opinas sobre esto?"Creo que SO está mejorando, especialmente en el último año". Ahora se esfuerzan mucho por mejorar la calidad de las preguntas. A menudo, las personas que primero preguntan algo en este sitio no están familiarizadas con cómo hacer preguntas técnicas correctamente.
Y este es un problema que siempre ha estado presente en Internet. En los años 90, cuando todos estaban en los grupos de noticias, ella también estaba allí. Diez años después, todo sucedió en las listas de correo y en los Grupos de Google. Ahora un nuevo recurso para preguntas de programación de desbordamiento de pila. Pero siempre ha habido preguntas sobre la programación, y cómo hacer una buena pregunta siempre ha sido un problema, y cómo mantener una comunidad amigable también. Quizás estos problemas nunca puedan resolverse por completo. No estoy diciendo que no debamos trabajar en esto, definitivamente deberíamos hacerlo. Pero si miras al pasado, resulta que incluso en los años 90 ya había tutoriales escritos sobre cómo hacer preguntas técnicas.
Hay un par de problemas que son nuevos en Stack Overflow. Puede comenzar con el hecho de que muchos de ellos nunca le preguntaron a otra persona antes de hacer su primera pregunta. Por lo tanto, en muchos casos, simplemente no se dan cuenta de todas esas cosas que deben presentarse en la pregunta para que pueda ser respondida.
Y luego, imagina que estás trabajando en una tarea. Estás loca por el código, tu cabeza está llena de todo esto. Y nos fijamos en algo específico que no se presta de ninguna manera. Este es un pequeño detalle concreto de un sistema grande, y generalmente preguntas "¿Cómo puedo hacer esta pequeña cosa?" Sin darte cuenta de que tienes todo este contexto que conoces, pero no lo pones en la pregunta. A menudo, la pregunta "¿Cómo hago X?", La respuesta correcta es "No haga X, haga Y". Esta es una trampa en la que las personas suelen caer cuando escriben las primeras preguntas. No se dan cuenta de que su respuesta en su forma actual es "no responde".
Y además del problema de la calidad de las preguntas, también hay una tendencia, especialmente en Stack Overflow, donde todos luchan por obtener puntos, tratando de responder lo más rápido posible, cerrar rápidamente la pregunta o garabatear rápidamente las respuestas menos agradables. No me refiero a "rencoroso", he visto muy pocos comentarios francamente rencorosos, solo unos pocos a lo largo de los años. Por el contrario, son duros, y para el autor de la pregunta, esto se lee como hostilidad.
Stack Overflow ha tomado algunos pasos simples para solucionar esto. Ahora, cuando la gente hace una pregunta por primera vez, el sitio le dice qué incluir en él. Anteriormente agregaron "mira estas preguntas similares", que fue un buen primer paso. Y ahora hay un sistema completo que debe completarse para la primera pregunta, lo que ayuda a componerlo bien.
También agregan recordatorios para aquellos que escriben las respuestas. Es como "Este es un novato, sé amigable", y es una buena manera de recordarte que la mayoría de las personas no escriben bien las preguntas la primera vez, y eso es completamente normal. En general, están trabajando en ello. ¿Se resolverá este problema por completo alguna vez? Lo dudo Pero el progreso es posible.
Asincronía
- En una publicación dedicada al décimo aniversario del iPhone, usted escribe que su apariencia afectó la programación asincrónica, porque las aplicaciones móviles deben ser receptivas. ¿Y puede dar una historia histórica general sobre el desarrollo de la asincronía para aquellos que recientemente comenzaron a desarrollarse y no vieron el mundo sin async / esperar?- Bueno, la programación asincrónica siempre ha sido posible. Creo que en los años 60 ya lo estaban haciendo. Y tuvo las mismas ventajas durante mucho tiempo: una interfaz de usuario más receptiva y una parte de servidor más escalable. Y el soporte siempre ha sido un problema: era muy difícil mantener el código asincrónico. Inicialmente, se basó en devoluciones de llamada.
Creo que el gran paso fue el advenimiento de Promise. Esto es lo que lo llamaron en JavaScript, y en C # es Task o ValueTask. Y este fue un gran paso adelante, porque ahora tenemos un objeto que representa la operación. Puede controlar su progreso, etc. Y async / wait en cualquier idioma es esencialmente azúcar sintáctica alrededor de Promise.
Diría que la aparición de Promise es el evento que más impacto ha tenido en el código asincrónico. Y en el caso de asíncrono / espera, es importante que la máquina de estado se cree para usted. En los viejos tiempos, cuando trabajábamos con devoluciones de llamada, teníamos que hacer nuestras propias máquinas de estado. Y siempre fue difícil porque inevitablemente olvidaste alguna condición o transición, y nada funcionó. Y fue muy difícil de depurar. Async / await no trajo la capacidad de escribir código asincrónico, pero sí la capacidad de escribir código que pueda ser soportado.
- ¿Y ahora ves que la situación se calmó, o pronto nos esperarán nuevos cambios?- Creo que ahora todo es bastante estable. Async / await parecía revolucionario, pero solo para aquellos que no habían hecho una programación asincrónica antes. Y para aquellos que trabajaron, se sintió muy natural. Pero, en general, este fue un gran evento.
Y ahora viene otro evento con .NET Core 3. Hacen lo que todos llaman flujos asíncronos, aunque en realidad son enumerables asincrónicos. Creo que esto confundirá a las personas, porque ya hay un tipo de Stream que no tiene nada que ver con las transmisiones asíncronas. En general, habrá más mejoras incrementales. ¿Veremos algo tan masivo como cuando async / wait se anunciaron por primera vez? No lo creo
Si desea un nuevo cambio de paradigma, siempre existe la posibilidad de un sistema basado en actores. O algo así como goroutine, donde toda la asincronía está implícita. En mi opinión, estas cosas son algo similares. El problema es que en .NET esto no es tan fácil de agregar. Creo que .NET tiene demasiadas restricciones para hacer esto, por lo que es poco probable que esto suceda. Si vemos una transición a gran escala al mundo del actor o al mundo de Goroutine, donde el enfoque de la concurrencia no será el mismo que con el subprocesamiento múltiple actual, esto requerirá lenguajes y tiempos de ejecución completamente nuevos. Y .NET no vale la pena. Y no creo que la programación en su conjunto dé un salto tan grande. Quizás estoy equivocado, pero mi posición actual es la siguiente.
- Más a la pregunta de cuánto cambia todo con el tiempo. Muchos libros de programación se están volviendo obsoletos rápidamente, pero donde los cambios son menores, duran más. ¿Qué pasa con su concurrencia en el libro de cocina de C # , cuánto requiere actualizaciones?Buena pregunta Recientemente publiqué la segunda edición, y la primera salió en 2014. Es decir, han pasado cinco años y ya estamos en la segunda edición, para mí parece un desarrollo rápido.
Creo que todavía depende de cómo esté escrito el libro. Traté de escribir para que no pasara de moda el mayor tiempo posible. Solo tiene que intentar no referirse a cosas como Windows Phone 8. Pero de todos modos inevitablemente quedará obsoleto. Aparecen secuencias asíncronas y similares, y quería incluir esas cosas en el libro. Como resultado, algo estaba desactualizado, pero la mayoría del material migró a la nueva edición sin cambios.
Y, por supuesto, todo depende de para quién es el libro. Por supuesto, el libro sobre el uso de Visual Studio 2008 caducará muy rápidamente. Pero creo que hay un lugar para auténticos clásicos. Considero que Code Complete es uno de los mejores libros de programación del mundo. ¿Y cuánto tiempo estuvo escrito? Ni siquiera lo se. Hace décadas. ¡Y este sigue siendo un libro fantástico! Algo está desactualizado, pero en general sigue siendo genial.
- Recientemente, ha habido ajustes sobre async / wait en Twitter, que comenzó con un tweet de Vaughn Vernon, autor de varios libros sobre DTD y modelos de actores:
No le gusta la importunidad asíncrono / espera: en su opinión, esto se extiende por todo el código y puede conducir al bloqueo de hilos. ¿Qué opinas de esto? ¿Valió la pena diseñar algo más?- Sí, quizás el hecho de que async / waitit se está extendiendo por el proyecto es la queja más común. Me gustaría mencionar un par de cosas aquí.
Primero, el código asincrónico, para ser realmente asincrónico, requiere asincronía de todos los que lo llaman. Y no se mueve. Cualquiera que sea el paradigma que uses (incluso uno de los viejos), al final te encontrarás con él. Tenía un informe donde cronológicamente reviso todos los paradigmas y muestro cómo el código se volvió más limpio y mejor.
Hay un par de enfoques diferentes para evitar el dominio generalizado de async / wait. El primero es aislar todas las entradas / salidas en objetos separados. Puede usar patrones de diseño como Puertos y adaptadores: esto le permite contener todas las E / S fuera de la lógica de su negocio, y luego no requerirá ninguna asíncrona / espera en absoluto. Recientemente, vi un informe completo sobre cómo evitar la "asincronización en todas partes" refactorizando el proyecto para que la lógica empresarial nunca se ocupe de las E / S. Yo recomendaría este enfoque.
Hay otro enfoque para lidiar con el dominio de async / await, pero no es factible en .NET. En mi opinión, Go trató de hacer esto con las gorutinas. De hecho, todo está ahí, es un asíncrono sólido / espera. Puede eliminar async / await del lenguaje agregándolo allí a todo y haciéndolo implícito.
No hay otras formas. Cuando apareció async / await, alguien (no recuerdo exactamente quién) dijo que era como un virus zombie: tan pronto como se infecta una parte de su código, comienza la distribución.
- Algunos desarrolladores usan el modelo de actor, explicando esto por la simplicidad del control de flujo (los actores, de hecho, son de un solo hilo). ¿Crees que con la elección correcta de bibliotecas, los desarrolladores pueden deshacerse de la complejidad de la concurrencia de programación?"Bueno, no del todo". Porque incluso con el modelo de actor, los problemas persisten. No encontrarás condiciones de carrera como en un programa de subprocesos múltiples, pero tendrás dificultades de amistad.
Por ejemplo, problemas con el retraso del mensaje o con mensajes asincrónicos. Por lo general, son necesarios para evitar puntos muertos en el modelo de actor. Pero cualquier modelo de actor que use mensajes asincrónicos también puede causar puntos muertos. Los mensajes asincrónicos también pueden crear sus propios problemas de coordinación. Por lo general, en este nivel, uno también tiene que lidiar con la idempotencia.
Además, el uso de actores con mensajes asincrónicos puede hacer que la gestión del estado sea bastante confusa, a menos que ocurra completamente en los mensajes. E incluso en este caso, tendrá dificultades con la consistencia eventual. En general, desde mi punto de vista, el modelo de actor no puede resolver todos los problemas. Lo describiría de esta manera: solo puede cambiar dónde surgirán exactamente los problemas.
"Usted es conocido como donante, pero utiliza otros lenguajes como TypeScript". Cuando los prueba, ¿cómo le hace ver C # y .NET? ¿Encuentras algo allí que te gustaría ver en C #?- Gran pregunta C # tomó mucho de otros idiomas. Uno de ellos del que tomó mucho es Python. Y a mi me gusta. Hace años que no escribo en Python, pero creo que este es un lenguaje muy bien diseñado. Realmente aprecio los bloques enumeradores que C # tomó prestados de Python. Y Python fue uno de los primeros en que aparecieron las secuencias Async, por lo que podemos decir que C # lo tomó desde allí.
En diferentes idiomas me gustan las cosas diferentes. Generalmente prefiero la escritura estática, por lo que no he estado usando Python últimamente, y por la misma razón estoy usando TypeScript en lugar de JavaScript. JavaScript tiene sus ventajas simplemente por su subproceso único. Por ejemplo, si observa la relevancia de las extensiones reactivas, verá que en .NET esto no se acepta particularmente. Y en JavaScript, puede ver Rx en todas partes.
- Las últimas dos preguntas son sobre su informe en DotNext. Vas a hablar sobre las transmisiones asincrónicas allí. ¿Puedes decir brevemente a los desarrolladores de .NET qué esperar y por qué este informe les será útil?- Entonces, mi informe sobre transmisiones asíncronas: por qué se agregaron al idioma y cuál es el escenario principal para su uso. Abordo esto muy pragmáticamente, y no entro en todos los detalles de lo que está sucediendo debajo del capó. , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .