Hoy he puesto un poco la tele normal en el salón. Me ha dado por vivir peligrosamente, anuncios incluidos. Fijaos si llevaba tiempo sin ponerla que ni siquiera había hecho la resintonización tras el segundo dividendo digital. Gracias a eso, ya sabéis, las redes 5G nos darán un montón de alegrías. Va a ser una fies.
El caso es que me he puesto a sintonizar los canales y luego a crear la lista de favoritos con los que solemos tener disponibles en casa. He tardado un rato en lidiar con el tema porque elegir la lista de favoritos como lista predefinida no es trivial en mi tele LG. Menos mal que he estudiado una carrera superior. Fiu.
Tras la aventurilla me he puesto a darme un paseo por la tele normal, cambiando de canales para ver qué ponían. La cuestión no es si había algo que me interesara -me he quedado con el ‘Fast N’Loud’ de DMax viendo a los flipaos yanquis arreglando coches- sino cómo ha sido la experiencia de cambiar a de canal en la TDT.
Es horrible.
No sé si es ya cuestión de mi tele o no. Quizás sea que mi sintonizador está algo anticuado, pero lo cierto es el tiempo que se tarda en cambiar de un canal a otro es horripilante: unos dos segundos según mis cálculos. ¿Cómo es posible que en 2020 nos enfrentemos a una experiencia así? Normal que la gente no quiera ver la tele normal: no solo es que la programación pueda no ser ideal: es que la propia experiencia de usuario es regular.
Eso me ha recordado un tema recurrente que aparece en Hacker News cada cierto tiempo. En él se afirma que «prácticamente todo en un ordenador es perceptiblemente más lento de lo que era en 1983». El tema original es un hilo de Twitter que podéis leer todo seguido aquí y habla básicamente de cómo todo lo que hacíamos en un ordenador parecía ir más rápido hace 40 años.
Evidentemente no todo iba más rápido, pero había cosas que sí lo hacían. Sobre todo las que afectaban a la interacción de usuario. Aquí el autor se flipaba un poco y mencionaba cómo las interfaces en modo texto eran mucho más rápidas que las basadas en una interfaz gráfica de usuario. Lo eran, creedme.
Tenemos un ejemplo en Midnight Commander, aquel explorador de archivos de la era MS-DOS que permitía que hiciéramos todo tipo de operaciones sobre ficheros a golpe de tecla. Escribí sobre ello en 2014, y es un ejemplo de ese debate del que hablaba el autor. En diversas aplicaciones que corrían en MS-DOS las cosas parecían funcionar de forma instantánea, pero ahora las esperas son normales en un montón de procesos que tienen que cargar un montón de datos. Navegar por internet es más espectacular que nunca en contenidos, pero cada página es también más pesada.
Incluso escribir se ha vuelto extrañamente lento en un PC. No lo notáis normalmente, pero es así. Lo explicaba un maravilloso post de Dan Luu en el que este desarrollador súper friqui analizaba la latencia de un montón de teclados de equipos portátiles y sobremesa. Si miráis esa página os daréis cuenta de que al tipo le gustan las cosas rápidas, y eso se nota en la propia web porque usa HTML crudísimo, sin florituras. Aún así se las arregla para explicar con claridad meridiana algo sorprendente: la latencia de un Apple IIe (una máquina de 1983) es la más baja con diferencia de todos los equipos que había toqueteado, algunos de los cuales eran de 2016 o 2017, como un Lenovo X1 Carbon que casi cuatriplicaba esa latencia (de 30 a 110 ms).
El análisis posterior es muy friqui (demasiado) pero explica porqué el Apple IIe era tan rápido. La razón fundamental era que con los años las máquinas se han hecho más complejas. Pueden hacer más cosas y las pueden hacer realmente rápido, pero eso no siempre significa que todo sea más rápido que hace 40 años.
El debate en Hacker News es larguísimo y reconozco que no lo he leído todo, pero es que tenéis debates igual de largos en ediciones previas de esa noticia que como decía es recurrente allí. Mucha gente pone ejemplos claros de cómo funcionaban las cosas y cómo funcionan, así que si os mola el tema, os dejo que disfrutéis con la discusión.
Un último ejemplo curioso: escribir este post en mi blog directamente hace que note claramente la latencia entre teclado y pantalla: escribo tan rápido que noto que la pantalla muestra los caracteres demasiado lento. O más bien, todo lo que hace que aparezcan en pantalla (estoy escribiendo en la nube en un servidor que está por ahí con un software -WordPress- que también añade su propia latencia en el editor) de forma sensiblemente lenta. Quizás haya formas de mejorar esa respuesta, pero me alucina lo que han hecho por ejemplo con Microsoft Word desde hace años.
No sé si lo habéis notado, pero cuando escribís en Word la experiencia es mucho más fluida. Microsoft hace algo -no sé qué es- que yo percibo de una forma curiosa: es como si los caracteres aparecieran antes incluso de que yo los tecleara, como si en Word la pantalla fuera a 144 Hz y en WordPress fuera a 15 Hz. ¿Os pasa a vosotros? No he logrado encontrar datos sobre esto en internet, pero el truco es una chulada y hace que la experiencia con el procesador de texto de MS sea estupenda al menos en esa sensación de que la latencia es mínima. Bien por Microsoft, que ha logrado que Word vaya (o parezca ir) tan rápido como lo hacía en 1983. Quizás más.
Quizá es lo que más odio en esta época: que los desarrolladores les importa un pepino considerar el rendimiento al desarrollar aplicaciones y se vayan por cosas tan pesadas como Electron y les importe un comino la experiencia del usuario “porque máquina sobra en estos días”.
Ya no hay tanto cariño y empeño por desarrollar la experiencia de usuario más placenteras y fluidas para usar.
E incluso esto se traduce en los dispositivos de Apple, que muchos “usuarios” (por no decir fanboys) siguen empeñados en decir que la experiencia con dispositivos Apple es la mejor. En el iPhone más páginas son un horror navegar por ellas a comparación de una laptop por el pésimo rendimiento.
Por eso siempre estoy en contra de usar app que usen un backend más lento.
Rayos, no puedo editar el comentario 🙁
Que horrores de ortografía, Dios mío.
La verdad es que un poco rarito sí ha quedado redactado el comentario. ¿Seguro que no eres una IA? 😛
¿Comparando un servicio en la nube con una aplicación instalada en local en temas de latencia? XD
Precisely. Ahí está el tema: preferimos usar servicios en la nube porque están en la nube y son, como dicen los ingleses, ‘convenient’. Cómodos, convenientes, compensa a pesar de la latencia.
Luego nos quejamos de ella, pero es que comparar una y otra es injusto. Cada opción tiene sus ventajas y desventajas. La GUI de las aplicaciones facilita y acerca la interacción con esas aplicaciones: puedes tardar más en hacer lo mismo que metiéndote en consola de comandos y usando flags a cascaporrillo, pero eso no significa que una u otra opción sean mejores.
Lo importante, como siempre, es que esas opciones sean mejores para ti.
Últimamente me ha dado por quitar el polvo a un kit de iniciación de Arduino que compré allá por las navidades de 2016. En su momento fue un poco «pain in the ass» instalar el controlador y que el entorno de desarrollo reconociera la plaquita para transferir lo compilado. Probé que funcionara y ahí se quedó por falta de tiempo.
Ahora han puesto en funcionamiento un entorno de desarrollo en la nube que, previa instalación de un programa residente en Windows, es una delicia de usar a pesar del lag evidente. Tener tu entorno de desarrollo para este tipo de proyectos en la nube, que funcione «out of the box» la comunicación bidireccional con la placa a través de un puerto serie virtual y que tengas la descripción de los ejemplos, su código y su esquema a golpe de click es una gozada.
Podría ser más purista obligándome a usarlo bajo Linux, sin tocar la GUI y compilando yo mismo las librerías y mandando el código a la placa a través de comandos de consola, pero entonces tal vez todavía estaría poniendo a punto el entorno y no tendría el proyecto «razonablemente» avanzado.
Eso me interesa, en casa tenemos un kit de esos y nos pasó exactamente lo mismo, así que si puedes pasarme el enlace genial Land.
https://create.arduino.cc/
En «Getting Started» te ponen un asistente web para descargarte el «plugin» que he comentado antes. Una vez instalado, entras en «Arduino Web Editor» y a codificar. Puedes usar la cuenta de Google para identificarte o crearte una propia. Dentro del editor, en «Examples» tienes organizados los ejemplos por categorías y una vez cargas uno en el editor, en los comentarios en la cabecera del código, tienes el enlace (simple click) a la descripción del ejemplo, explicaciones, etc.
Buah chaval!!! yo empezé con word perfect cuando no era wyswyg. Aquello si que era rápido. Era instantáneo. En un 286 con 640 KB de RAM!!!. Además, si dividías la pantalla, veías las marcas de formato que iba insertando, con lo que te preparaba para aprender html cinco años después. Luego le añadieron soporte de ratón, con lo que se fueron olvidando los atajos de teclado.
Si, la latencia crece exponencialmente con los años.
Yo con WordStar. Horroroso, según recuerdo, pero claro, aquello empaña el hecho de que probablemente la latencia era mínima.
¿Pero qué ordenador teníais en el 83? Mi 8086 tardaba literal 5 minutos en encender. No, los ordenadores no son más lentos ahora que antes.
Evidentemente hay cosas que son mucho más rápidas, pero si lees un poco el tema te darás cuenta de que la cosa va de otros escenarios.
Con respecto a la TDT, tenemos que tener en cuenta que el proceso de cambiar de canal implica cambiar de frecuencia un modulador para elegir un canal u otro y que éste se estabilice, sincronizar la emisión física con la recepción local (la QAM es bastante sensible a ello), y para terminar, tanto el el stream de datos de vídeo como el de audio debe de llenar buffers para reproducirse de forma sincronizada (a nadie le gusta que el audio llegue antes o después que la escena que se ve)
En función de lo complicada que sea la transmisión QAM (16, 64, o hasta 256 bits en la nueva TDT), dependiendo de los tamaños de buffer, y sobretodo, dependiendo de la potencia del hardware usado, pues esto tardará más o menos.
Antiguamente con la analógica no ocurría dicha cuestión por propia naturaleza. Los procesos analógicos son prácticamente instantáneos a menos que no quieras que sea así (véase líneas de retardo). Nada más hay que tomar una radio FM o AM y ver lo rápido que se sintoniza tras mover el dial.
Con respecto a lo rápido que va Word, pienso que en dicho programa hacen como en los videojuegos, tomar el teclado en «raw» en vez de dejar al SO que tome el control del cuadro donde se escribe, al igual que ocurre cuando hacemos algún programita con un cuadro de texto en C, C++, C#, etc. De hecho, esto se puede ver con la animación suave del cursor de escritura, algo que no ocurre en prácticamente ningún programa.
Un saludo.
Qué buena explicación Josemi, gracias por esos buenos datos.
Lo de los canales es increíble… en general lo de los televisores es increíble… mucho smarttv y no vale para nada.
¿Por qué no puedes subir a tu cuenta del Smarttv el orden de los canales y marcar desde ahí un orden que te guste y a partir de ese momento que siempre se replique en tus televisores? Y si cambia un canal de frecuencia que él automáticamente cambie la frecuencia en tu canal.
A ver si algún día se van dando cuenta de eso y más cosas… ahora que empiezan a hacer mandos a distancia con bluetooh que no hay que apuntar… tal vez se den cuenta de este y otros detallitos en unos 20 o 30 años.
Por cierto… yo soy un poco especial… y me gusta que en todos los televisores todos los canales estén iguales… cosa casi imposible si lo haces solo con el mando… en su momento encontré una aplicación para Windows que permite ordenar los canales de forma rápida y sencilla usando teclado y ratón.
A ver si tienes suerte y tu televisor está entre la lista de soportados: https://github.com/PredatH0r/ChanSort