ES?.next()

Hola, JS Nation. Estamos hablando de ES Next en esta charla. Soy Hemant. Soy miembro del personal técnico de PayPal, un GDE en el dominio web y de pagos y, por supuesto, un delegado de TC39 y puedes enviarme un tweet a gnumonth. ECMA, la Asociación Internacional de Fabricantes de Computadoras de Europa, tiene muchos comités técnicos que deciden y definen las especificaciones de diferentes entidades.

Y uno de ellos, el 39, es el TC39 que trabaja en ECMAScript. ¿Cómo funciona básicamente el proceso? Entonces, básicamente tenemos 5 etapas que van desde la etapa 0 hasta la etapa 4. La primera etapa se llama propuesta inicial. En esta etapa, se permite la entrada en la especificación. Es más como tener una idea y aún no se ha presentado en el comité. Y la etapa 1 es más como una propuesta. Entonces tienes una idea y presentas un caso para la adición y luego describes la forma y también la solución. Y lo que estás tratando de resolver y cuál es la solución y cuál es el problema que quieres resolver es lo que se discute aquí en la etapa 1. Y en la etapa 2, tienes un borrador donde describes precisamente la sintaxis y la semántica utilizando un lenguaje de especificación formal. Y luego, en la etapa 3, tienes un candidato que indica que, hey, esto se puede probar con una bandera, tal vez en tu navegador o en un entorno de nodo. Entonces, es como si estuvieras buscando comentarios sobre el candidato de los desarrolladores y diciendo, hey, úsalo con precaución porque ahora está bajo una bandera. Solo úsalo y dinos cómo se ve. Y finalmente, en la etapa 4, está terminado y está listo para ser lanzado. Y a veces ya se ha lanzado con la bandera, como dije, en la etapa 3, la bandera se elimina en esta etapa y está disponible en la mayoría de los navegadores modernos y otros entornos. Ese es todo el proceso de cómo funciona TC39, desde la propuesta inicial hasta el final después de la propuesta, el borrador, el candidato, por supuesto. Curiosamente, esto se llamaba Strawman antes, y ahora se llama Strawperson, lo cual tiene mucho sentido.

Aquí hay un gráfico interesante, que se extrae del estado actual donde tenemos propuestas desde la etapa 0 hasta la etapa 4 y tenemos 18 propuestas en la etapa 0 y 79 propuestas en la etapa 1, y tenemos 26 en la etapa 2, 14 en la etapa 3 y 49 en la etapa 4. Así que durante esta charla, repasaremos algunas propuestas interesantes en cada una de estas etapas y una palabra de precaución, por supuesto, porque estamos hablando de algunas de las propuestas que están en una etapa muy temprana. Por supuesto, cambiarán, algunas de ellas incluso podrían cambiar su comportamiento. La sintaxis podría cambiar, algunas de ellas incluso podrían no llegar al estado final, así que no supongas que todas estas características estarán disponibles en Javascript algún día. Estas son algunas de las posibles características futuras en las que nos fijaremos. Así que marqué cada una de las diapositivas con estos dos emojis aquí, a la izquierda lo que vemos aquí con el icono de gafas es más como una IP que dice, hey, así es como lo estamos haciendo hoy. Y a la derecha con las gafas es lo que estamos diciendo, hey, cómo sería probablemente en el futuro. Digamos que tengo un iterLib y tienes una función obtener jugadores, que te da un objeto que tiene personajes y tiene atributos de fuerza y necesitas extraer alguna información de él. Entonces, iterLib te proporciona los métodos map, take while y forEach.

Y el getPlayer aquí, con el val, te da un objeto. Así que quieres mapear o, como se hace hoy en día, haces un map.call en ese valor y obtienes todos los personajes. Y luego haces un take while y dices, hey, si la fuerza es mayor que cien, dame todos esos. Y finalmente, probablemente tendrías que hacer un forEach y hacer algún procesamiento. En este caso, solo estamos imprimiendo en la consola el valor. ¿Puede ser mejor?

Así que en el estado cero, tenemos esta sintaxis de enlace, que facilita la vida con el operador bind. Si puedes pensarlo como dos columnas sucesivas aquí, lo que vemos después de getPlayer, tienes map y luego tienes take while y luego tienes forEach. ¿No es más simple en comparación con cómo lo estamos haciendo hoy en día, probablemente y cuán preciso y simple se ve aquí en el estado cero tenemos esta sintaxis de enlace. Entonces, esta sintaxis de enlace, si tuviéramos que resumir en las diferentes variantes que proporciona, si ves objeto con el operador bind y función, que es igual a function.bind objeto seguido del operador bind objeto.función, que de hecho es equivalente a objeto.función.bind con objeto. Si tienes objeto enlace con valor de función, eso es equivalente a function.call objeto.valor. Y si solo tienes enlace objeto.función.valor, que es igual a objeto.función.call objeto.valor. Esto hace que la vida sea mucho más simple e intuitiva de leer y entender. Y además, la sintaxis se ve hermosa, ¿verdad? Veamos otro ejemplo aquí.

Probablemente hayas hecho esto varias veces, si tienes un objeto y tienes un objeto con muchos atributos y quieres devolver atributos específicos o quieres tener un nombre diferente para los atributos. Entonces, en este caso, digamos que tienes un performance como uno de los atributos perf en ops. Probablemente dirías perf es perf.ops o si tienes un objeto de x, dirías x es objeto de x y con la notación de corchetes o si estás desestructurando, probablemente lo harías así. ¿No sería más fácil si tuviéramos una forma más sencilla de hacerlo en lugar de decir perf es op.perf? Yo simplemente diría op.perf, lo que debería significar que perf es op.perf. Y digamos que tienes coordenadas como O de x con la notación de corchetes. Como vimos en la diapositiva anterior, debería significar que x es O de x, ¿verdad? Lo mismo ocurre con la desestructuración. Simplemente podrías decir a de x, que es igual que decir x: a de x y la notación de objeto de x como a de x. Así que estas son las asignaciones de propiedades abreviadas en el Estado 0, que facilitan la vida.

La otra propuesta interesante en la etapa uno es la coincidencia de patrones, que te brinda este método de coincidencia y te permite decir, oye, coincidir, tomar esta entrada y luego decir cuando esta entrada es de un patrón particular. Quiero este comportamiento. Aquí tienes un ejemplo clásico donde estás obteniendo datos de un servicio JSON y obtienes una respuesta y podrías decir cuando el estado de mi respuesta es 200 y mi encabezado tiene una longitud de contenido y obtener la longitud de contenido como s, podrías extraer ese s y estás registrando aquí tu tamaño, el tamaño del encabezado. También podrías operar en la respuesta y decir, oye, si el estado de mi respuesta es 404, entonces adelante y decir, JSON no encontrado. Y también podrías desestructurar el estado y decir, oye, si mi estado es mayor o igual a 400, entonces lanzar un error de solicitud. Esto hace la vida mucho más fácil que tener un If-else anidado o un switch y una condición donde, hasta hoy, no tienes una forma directa de hacer esta coincidencia de patrones en JavaScript. Y esto lo hace muy interesante para aplicar la coincidencia de patrones a tus problemas y tratar de resolverlos de una manera más precisa y compacta.

Otra extensión, la mejora que se agregó recientemente a la propuesta en la etapa uno es tener una coincidencia asíncrona. Puedes tener una coincidencia asíncrona con un await matchable y hacer lo mismo que harías con una coincidencia no asíncrona, podrías decir cuando A puedes esperar y cuando B puedes hacer B.then. Básicamente, produce una promesa y puedes hacer una coincidencia asíncrona con la coincidencia de patrones también.

Otra característica interesante que tenemos en la etapa uno es la expresión do. La expresión do básicamente te ayuda a tener un bloque dentro de do, donde la última declaración se escribe por defecto. Digamos que tienes en este ejemplo X, donde, donde dices que temp es una función llamada y dices que temp es temp más 1, eso es lo que se escribe por defecto como valor. Pero ¿cómo es realmente útil? Digamos que tienes múltiples ramificaciones en tu código y ¿cómo lo harías hoy? Supongamos que tienes constantes let o una combinación de eso en tu código, o quieres envolverlo dentro de una función para, ya sabes, mantener el alcance y cosas así. Aquí tienes un ejemplo de múltiples ramificaciones. Puedes hacerlo tan fácilmente como decir, `Oye, aquí está mi expresión do y tengo mi condición if. Si foo coincide, entonces invocaría la función f y ese valor se asignaría a X aquí, si no. Si es bar, entonces seguirías e invocarías G y ese valor de la invocación de G se asignaría a X aquí de nuevo, o de lo contrario lo llamarías. Así que puedes ver lo intuitivo que se ve en comparación con probablemente lo habrías hecho con el operador ternario y tener condiciones anidadas dentro de las cuales hacen que tu código sea un poco feo y probablemente incluso dificulte la depuración.

Aquí tienes otra sintaxis más sencilla para JSX. Esto probablemente la mayoría de nuestros amigos que están en React habrán enfrentado, digamos que quieres renderizar componentes condicionalmente. Probablemente pondrías un operador ternario en ello, o probablemente usarías otro componente que evalúe condicionalmente la lógica requerida y renderice el componente requerido, ¿verdad? Así que se vuelve más complicado. Aquí tienes una vista. Así es como se ve tan bien con la expresión do. Dices que tienes un nav, tienes el componente home y dices que si has iniciado sesión, muestra el botón de cerrar sesión, de lo contrario muestra el componente de inicio de sesión. Así que es muy fácil expresarlo aquí con la expresión do.

Por supuesto, la expresión do no se detiene ahí. Veamos otra propuesta interesante. Hasta hoy, si estás usando promise.all que tiene await dentro, probablemente lo envolverías con funciones asíncronas, invocarías inmediatamente funciones asíncronas, porque no puedes usar await en el nivel superior a menos que estés en MJS, ¿verdad? Así que si lo usas hoy, haces promise.all y envuelves cada uno de ellos con funciones asíncronas, y luego seguirías y obtendrías los resultados y operarías en ellos. Así que async do en la etapa uno es exactamente esta propuesta, que es más como una extensión de la expresión do, pero a nivel asíncrono, lo que hace que las cosas sean aún más fáciles en lugar de envolverlas con una expresión de función asíncrona invocada inmediatamente, simplemente puedes decir async do y luego pasar tus propias declaraciones de obtención o cualquier otra cosa, o la lógica requerida para ese bloque asíncrono. Así que puedes hacer un async do y esto hace que el código sea mucho más legible y no tienes que romperte la cabeza envolviéndolo. Nuevamente, con una función asíncrona invocada inmediatamente. Así que esto está en la etapa uno, expresión do asíncrona. Y la sobrecarga de operadores en la etapa uno. Hay un gran debate sobre si JavaScript realmente necesita la sobrecarga de operadores, si realmente ayuda. Y esta propuesta está tratando de explorar eso.

Y aquí tienes un ejemplo con decimales, que dice que con operadores decimales, debatimos intentar sobrecargar el significado de suma, igual y otros operadores e intentar obtener una sintaxis y comportamiento expresivos con la sobrecarga de operadores, y la intención principal aquí es tener bibliotecas donde si el operador está sobrecargado, te ayuda a hacer expresiones mejores y más fáciles, lo que básicamente te ayuda a definir métodos que son particularmente útiles para tu dominio. En este ejemplo, tenemos decimales que están sobrecargados con suma. Entonces, si dices decimal uno más decimal dos, obtienes un decimal tres. Y de manera similar, aquí tienes otro ejemplo de la especificación donde dice con operadores de valores numéricos de CSS, podrías hacer un selector de consulta en estilo y rellenar a la izquierda con CSS M tres o CSS PX dos, y así es como probablemente sobrescribirías esos operadores. Dirías que usarías la función de operador aquí y dirías, Oye, mi suma está definida de esta manera y mi multiplicación se define de esta manera, mi igualdad es esta, y mi izquierda y derecha, ¿cómo se evalúan? Así que entiendes cómo podrías sobrescribir los operadores y, finalmente, extenderías el operador decimal para la clase decimal. Y luego, el nuevo grande probablemente obtendría las definiciones de los operadores sobrecargados sobrescritos básicamente para lo que se ha definido aquí para los operadores decimales y en la etapa uno.

Tenemos la propuesta de String dot didn't, afortunadamente soy uno de los co-campeones de esta propuesta. Si has utilizado nuestras plantillas literales para generar código, básicamente te habrás enfrentado a este problema de lo difícil que es la indentación dentro de una plantilla literal. La indentación se mantiene y una vez que se genera el código, se mantiene la misma indentación. Así es como se ve el String dot didn't, tendrías el método estático didn't en el objeto string. Hemos dicho string.didn't, que también admite expresiones. Así que tienes una expresión aquí que se evalúa y se reemplaza en la salida con la expresión. Y si tienes espacios, los espacios se mantendrán, no se recortarán. Así que esta característica hace la vida más fácil cuando intentas generar código o imprimir algo en la consola con el formato correcto, o si estás escribiendo una declaración o consulta SQL que deseas ejecutar y que se muestre correctamente en la salida. Hay muchos casos de uso similares, pero string.didn't en la etapa uno es una propuesta que facilita las cosas en este ámbito.

La otra propuesta interesante que tenemos es el operador de canalización. Actualmente, es una sintaxis no resuelta que tiene cuatro variantes sobre cómo puede funcionar el operador de canalización. Y aquí tienes un ejemplo. He elegido una de esas sintaxis, digamos que tienes dos métodos, doble e incremento, que obviamente duplican e incrementan en uno o N, lo que pases, toma un N y le suma uno. Pensamos que con el operador de canalización, probablemente tendrías que tener estas llamadas anidadas. Dirías doble incremento, doble y doble, ese es el caso de uso. Entonces, si te doy un archivo, deberías obtener 42 de él. Con el operador de canalización, básicamente lo que hace es que necesita una expresión y luego tiene el operador de canalización y una función. Entonces, si dijeras cinco, doble y doble, y luego incremento y doble, obtendrías 42 y así es como se ve hermosa la sintaxis. Así que esto está en la etapa uno, el operador de canalización y object.on, has on está en la etapa dos. Esta fue una de las propuestas interesantes que llegó directamente a la etapa dos cuando se presentó al comité y todo lo que hace es que te brinda este hermoso método abreviado, si puedo llamarlo así, para decir que object.on tiene on, que toma el objeto y toma la propiedad y dice si esa propiedad está ahí o no. Hasta hoy, probablemente tendríamos que hacer object o prototype.hasOn propiedad y llamar al objeto con esa propiedad y luego verificar si está ahí o no. Así que en lugar de pasar por esa cadena larga de funciones, simplemente puedes decir object.hasOn pasando el objeto con la propiedad y dice si las propiedades tienen on, si esa propiedad tiene esta propiedad o no. Así que eso es object.hasOn en la etapa dos.

Y tenemos map.prototype.emplace. Esto, esto, esto es un método muy útil si estás, si estás trabajando con mapas hoy en día, digamos que quieres verificar si una clave está presente en un mapa o no, y luego establecer y luego obtener el valor, probablemente harías map.has, si el mapa no tiene esa clave, entonces sigue adelante y establécela y más adelante, tú puedes obtener y hacer cosas con ella con emplace. Se vuelve muy, muy ingenioso y fácil. Solo puedes decir map.emplace clave y luego insertar el valor y hacer cosas. Entonces map.emplace básicamente toma una clave y necesita actualizar e insertar valores. Entonces no necesitas romperte la cabeza verificando si tu mapa ya te tiene, si está ahí, entonces actualízalo. Si no está ahí, entonces créalo. Todo esto lo maneja emplace. Entonces map.product o emplace en la etapa dos.

Y en la etapa dos, también tenemos registros y tuplas. Entonces podrías pensar en los registros como estructuras similares a objetos profundamente inmutables. Aquí tienes un ejemplo de una propuesta, que tiene ID, título, contenido y palabras clave. Y luego sigues adelante y dices una propuesta o título, imprime registros y tuplas. Y luego continúas y lo expandes como objetos y dices título es un registro en tuplas de la etapa dos. Pero si sigues adelante, dices propuesta a título, dice etapa dos, un registro en tupla. Pero tu propuesta seguiría teniendo el mismo registro y tupla. Así que es más como un objeto inmutable, como una estructura. Eso es un registro para ti. Y las tuplas son en su mayoría estructuras similares a matrices profundamente inmutables y similares a los registros. Puedes decir hash seguido de uno, dos, tres, eso sería una tupla. Y luego podrías decir con cero coma dos para obtener esas partes de la tupla. En este caso, dices, adelante y reemplaza el índice cero con dos. Entonces básicamente obtienes que la tupla dos sea igual a dos, dos, tres. Mientras que la tupla uno es uno, dos, tres, y estas dos no son iguales. Así que también puedes hacer una expansión de esas. Puedes, puedes decir pushed con cuatro. Puedes usar el método popped. Entonces, todos estos métodos están disponibles en la tupla, lo que básicamente te ayuda a tener una estructura similar a una matriz, pero es inmutable. Así que si te gusta la inmutabilidad y la programación funcional, probablemente estarías usando Immutable JS y similares, y las tuplas recursivas te brindan esa fuerte capacidad de tener estructuras inmutables en tu programa, y find last y find last index es otra propuesta en la etapa dos que dice que tienes una matriz de valores. Y hoy en día, si intentaras encontrar, el índice, el último índice o el encontrar el último elemento en la matriz, probablemente intentarías tomar la matriz, revertirla y hacer una búsqueda de índice, ¿verdad? Aquí tienes un ejemplo donde debería haber sido menos uno, pero es cuatro. Estás tomando una matriz, invirtiéndola, estás haciendo una búsqueda de índice y diciendo que los valores sean iguales a 42. Debería haber sido menos uno, pero hoy será cuatro. Si ves que tu matriz tiene valores de uno, dos, tres y cuatro con el método find last en la matriz, simplemente puedes decir, matriz.find last. Y le das una condición aquí. Estamos diciendo que si es divisible por dos, entonces dame el último que sea divisible por dos. Obtendrías ese valor. Y también podrías hacer un find last index. Si estás trabajando en el índice, podrías obtener la misma idea aquí, donde dices end dot value es 41. Dame el índice aquí.

Te da menos dos porque no hay 42 aquí. Todos los valores son uno, dos, tres, cuatro y divisibles por dos. Dame el último índice que sea divisible por dos. Obtienes 0, 1, 2, y obtienes eso como resultado en el find last y find last index. Y básicamente tienes la expresión throw en la etapa dos, que también es una propuesta interesante. Por ejemplo, si tu función recibe un parámetro y se espera que esté presente, podrías lanzar un nuevo tipo de error en línea en lugar de afirmarlo dentro de la función para verificar si el parámetro está disponible o no. También puedes hacerlo dentro de las funciones flecha o con expresiones condicionales y, básicamente, también en operadores lógicos. Por lo tanto, puedes lanzar este nuevo error en línea donde sea necesario. Lo cual es útil. Y si vienes de lenguajes de programación como Perl, donde podrías decir all die, una cosa similar, o podrías hacerlo como una expresión. Puedes lanzar, ya sabes, lanzar una expresión donde quieras.

Y en la etapa tres, tenemos la propuesta de indexables incorporados. Te daré un ejemplo con números, como arreglos, o puedes tener un nombre como cadena o tener tu arreglo de ocho elementos. Puedes usar el método app para obtener o cualquier elemento que desees en ese índice particular. Entonces, si dices nums en cero, obtendrías cero y nums de menos uno, obtendrías tres. Es como ir desde el último índice, esos índices negativos sugieren que, okay, ve y selecciona el último elemento de ahí. Entonces, si haces menos uno, obtienes tres, si haces menos dos, obtienes dos. Y si pones cien o algo así, simplemente obtienes undefined, lo cual no está en ese rango. Y puedes hacer lo mismo para cadenas y datos unitarios.

Y la causa de error es otra propuesta de la cual soy co-campeón. Esta es una propuesta interesante que agrega una opción al constructor de errores. Si fueras a lanzar un nuevo error, podrías pasar la causa y decir, hey, este error fue causado por esta falla o algo más. ¿Verdad? Entonces puedes tener una función y luego lanzar un nuevo error. Hasta ahora, dirías, hey, esto falló debido a este error, pero ¿cuál es la causa exacta? ¿Y cómo podrías ver eso en el rastreo de errores? ¿Verdad? Ahí es donde la causa del error juega un papel clave. Entonces tienes una función asíncrona, intentas obtener algunos datos, capturas el error y lo registras en la consola y luego registras el error causado por E.cause. Y esa causa es la causa que se lanzó aquí en la obtención de datos. Entonces, la salida que ves es error no se pudo obtener los datos, https ejemplo.com causado por error de tipo, no se pudo obtener. Esa es la causa, ese es el error que se pasa en el atributo de causa en la opción que se pasa al constructor de errores. Entonces, eso es una causa de error en la etapa tres.

Y en la etapa tres, tenemos la espera en el nivel superior. Si fueras a hacer await.promise resolve o cualquier función principal de promesa. Hasta ahora, diría que await no es una función válida porque necesita estar envuelta en una función asíncrona. Pero dentro de los módulos, tienes la espera en el nivel superior, donde puedes tener await en el nivel superior. Entonces, si has estado siguiendo esto durante algún tiempo, habrás visto que se escribió un artículo sobre cómo las esperas en el nivel superior son una pistola cargada, pero luego el mismo autor vio la propuesta de cómo la espera en el nivel superior es útil. Y luego dijo, sí, tiene sentido dentro de los módulos. Y hoy en día lo tenemos en la etapa tres y pronto estará en la etapa cuatro. Y eso es todo lo que tenemos para todas estas propuestas inmensas, intensas y emocionantes, y espero que te gusten. Gracias. Gracias, Hemant, por esta gran charla. Ahora, pasemos a las encuestas. ¿Qué tipo de propuestas te gustan más? Espero que todos respondan.

Y el ganador es Syntax Sugar con un 32%, seguido de Fresh Paradise con un 30%, New Operator con un 20% y New Method en el prototipo con un 16%. ¿Te parece interesante, Hemant, o te sorprende? ¿Qué piensas al respecto? Sí, es bastante interesante. Y también resultó ser la primera opción en las preguntas. Y normalmente a la gente le gusta Syntax Sugar porque hace que las construcciones de programación sean más fáciles y el código se ve más preciso y conciso. Y por eso creo que la mayoría ha ido a parar a Syntax Sugar, y aún seguimos viendo que está aumentando. ¡De acuerdo, genial!

Y ahora pasemos a las preguntas. Bartos pregunta, además de los índices negativos, ¿cuál es el uso de la función add? Sí, no solo se trata de índices negativos, también puedes agregar cualquier índice que desees. Y si observas las API del DOM, como mencioné en la charla, también tiene un enfoque similar para obtener el índice de la lista de modelos. Por lo tanto, te ayuda a obtener un elemento en ese índice apropiado fácilmente. Y el índice negativo también es una ventaja donde puedes ir y buscar el elemento, digamos, en el último y recogerlo. Esa es la ventaja. De acuerdo, gracias.

Gianpo pregunta, ¿es posible votar por esas propuestas? ¿O es trabajo del comité de RF? Bueno, sí. Aparte del comité, la gente no puede votar realmente por las propuestas, pero hay muchos foros donde puedes discutir sobre las propuestas y compartir tus ideas y pensamientos. Y a veces también hay un tuit, que se convierte en una propuesta y se implementa. Así que todo sucede de manera abierta, pero las reuniones se llevan a cabo en entornos cerrados, pero las notas siempre están abiertas. La gente puede leer las notas y podemos dar comentarios sobre la propuesta, pero no realmente votar, porque la votación se lleva a cabo en una sala donde los implementadores tienen la autoridad para decir, hey, esto podría causar ambigüedad o es bastante complejo de implementar en un navegador, quienes tienen más idea de cómo debería hacerse la implementación. Y aparte de eso, todos los miembros del comité tienen derecho a votar por las versiones. De acuerdo, gracias.

La siguiente pregunta es, ¿el comité considera la compatibilidad con TypeScript al evaluar las propuestas? Bueno, no realmente. ECMAScript es más como una especificación que los lenguajes implementan y JavaScript implementa eso y es compatible con ECMAScript. Por lo tanto, el objetivo principal aquí es no romper la web y definitivamente está influenciado por muchos lenguajes cuando se presentan propuestas. Pero realmente no se analiza, hey, ¿es compatible con TS o es compatible con alguna otra construcción o lenguaje en particular. Tampoco se habla de cómo se implementarán las propuestas. Se va un nivel más alto y se habla de la especificación y cosas similares.

La siguiente pregunta es mía. ¿Cómo es estar en el comité? ¿Es divertido? ¿Es difícil? ¿Cómo es interactuar con otras personas? Como las propuestas, las votaciones, en general, ¿cómo te gusta? Bueno, es increíble estar rodeado de un grupo de personas muy inteligentes y a veces tenemos a Brenda y a mí, el hombre en sí mismo en la sala y es realmente humillante y sabes que la gente es muy inteligente y aportan casos particulares a los escenarios. Recuerdo una de las conversaciones que tuvimos sobre fechas. Un caballero mencionó un formato de fecha en particular que nunca habíamos escuchado, donde los meses varían y las fechas varían, ese tipo de cosas. También pueden citar las especificaciones ISO sin siquiera mirar y consultar y son un grupo increíble de personas y hay mucho que aprender muy influenciado por todas las personas inteligentes en la sala. Eso suena increíble. Así que invitamos a más personas a ver estas propuestas a comentar y muchas gracias por esta gran charla y quiero invitar a Metin al escenario.