Hace tres décadas, en mayo de 1995, un joven ingeniero llamado Brendan Eich, recién incorporado entonces a Netscape Communications, se encerró durante diez frenéticos días para construir un prototipo funcional de un nuevo lenguaje de programación destinado a proporcionar interactividad a las páginas web.

Pero este mero experimento improvisado (un 'hack', como él mismo lo llamaría tiempo después) se terminaría convirtiendo en el motor de la web moderna, una herramienta omnipresente que hoy utilizan casi todos los sitios de Internet.

Cuando la web todavía era estática

En 1995, la World Wide Web atravesaba un momento decisivo: la navegación era esencialmente pasiva: el usuario leía texto, veía imágenes estáticas y seguía enlaces. Netscape, creadora del entonces revolucionario Netscape Navigator (el bisabuelo tanto de Mozilla Firefox como de Mozilla Thunderbird), vio un enorme potencial en la posibilidad de convertir esas páginas estáticas en entornos dinámicos y participativos.

Su objetivo era crear un lenguaje sencillo, accesible para diseñadores y profesionales sin formación profunda en programación. Era fundamental que se ejecutase dentro del navegador, sin necesidad de compilaciones complejas y sin requerir el conocimiento de lenguajes tradicionales como C o Java.

En Genbeta

Gemini, el protocolo alternativo al HTTP que promueve un Internet más ligero y seguro, más basado en el texto que en lo multimedia

Diez días que cambiaron Internet

Eich había sido contratado para trabajar con Scheme —un lenguaje funcional, elegante, pero poco conocido—, aunque la dirección de Netscape tenía otros planes: querían algo que "se pareciera" a Java, el lenguaje de moda por aquel entonces. Así que nuestro programador combinó influencias diversas:

• La sintaxis: Corchetes, puntos y comas, estructuras if y while, funciones declaradas con una estética familiar… todo inspirado en Java para satisfacer al departamento directivo.
• La semántica: heredada de Scheme, lenguaje que Eich admiraba. De ahí vienen las funciones de primera clase, las 'closures', la flexibilidad para manipular funciones como datos, y una forma de evaluar expresiones muy distinta a la de Java o C.
• El modelo de objetos por prototipos: tomado de Self. Así, en vez de adoptar la clásica herencia por clases (como en Java), Eich incorporó el enfoque de prototipos, donde los objetos se crean a partir de otros objetos. En 1995, esta idea era vista como exótica e incluso extraña por muchos programadores formados en lenguajes clásicos.

El resultado fue un híbrido sorprendente: ligero, flexible y lo suficientemente intuitivo como para ser adoptado por creadores de contenido web sin formación técnica avanzada. Aquel primer prototipo no era un lenguaje completo, sino una prueba de concepto interna... pero funcionaba, y eso bastó para que Netscape redoblara su apuesta. Y así terminó naciendo JavaScript.

La evolución de dicho prototipo todavía continuaría durante más de un año hasta su lanzamiento público en septiembre de 1995 y de la versión 1.0 en marzo de 1996. En aquel momento, Netscape y Sun Microsystems anunciaron conjuntamente el lenguaje y consiguieron el apoyo de 28 grandes compañías tecnológicas.

Paradójicamente, JavaScript ha terminado sobreviviendo a muchas de esas empresas —como Silicon Graphics, Digital Equipment Corporation o la propia Netscape—.

En Genbeta

JavaScript puede ayudarte a desarrollar aplicaciones de IA, y aquí tienes ejemplos. No todo es Python

Las prisas dejan huella

El desarrollo acelerado dejó un legado peculiar: sus inconsistencias, aún famosas entre los programadores. Resulta que JavaScript fue diseñado para ser tolerante: si el usuario cometía un error, lo ideal era que la página siguiera funcionando.

Y esa filosofía llevó, por ejemplo, a implementar un sistema extremadamente flexible —y a veces impredecible— de coerción de tipos. Ejemplos famosos:

• [] + [] produce "" (una cadena vacía).
• [] + {} produce "[object Object]".
• {} + [] produce 0 en algunos contextos.
• "5" - 2 da 3, pero "5" + 2 da "52".

Estos comportamientos se deben a reglas de conversión creadas rápidamente para compatibilizar cadenas, números y objetos sin romper el flujo del usuario, pero sin un diseño coherente a largo plazo. Sin embargo, estas imperfecciones no frenaron su éxito.

La 'era JavaScript'

Hoy JavaScript es mucho más que un lenguaje de navegador. Sus descendientes y ecosistemas relacionados se han expandido a prácticamente todos los ámbitos:

• Casi el 99 % de los sitios web utilizan JavaScript en su lado cliente.
• Con Node.js, se convirtió también un lenguaje de servidor.
• Frameworks como React, Angular o Vue dominan el desarrollo frontend.
• Se utiliza en aplicaciones móviles, escritorio, videojuegos y hasta en dispositivos embebidos.

En todas las encuestas de uso y popularidad, JavaScript sigue liderando como uno de los lenguajes más empleados del mundo.

Imagen | Marcos Merino mediante IA

En Genbeta | "Lo mejor que podemos hacer hoy con JavaScript es retirarlo": así habla el creador de JSON y autor de 'How JavaScript Works'

En el mundo del desarrollo de software, a priori pocas decisiones parecen ser tan técnicas —y, por tanto, teóricamente racionales— como la elección de un lenguaje de programación: se supone que se trata de comparar rendimiento, escalabilidad, herramientas o facilidad de mantenimiento. Pero en realidad, esta decisión es cualquier cosa menos objetiva.

Steve Francia, ingeniero con décadas de experiencia en empresas como Google y MongoDB, ha sido testigo de primera mano de cómo la subjetividad de esta clase de elecciones puede terminar costando millones de dólares, frenar la innovación y, en algunos casos, hundir empresas enteras.

Su conclusión es contundente: a la hora de la verdad, las decisiones sobre lenguajes no se toman con criterios técnicos, son identitarios. Un poco como los equipos de fútbol o la política...

Cuando cambiar de lenguaje cuesta una empresa

Francia relata una experiencia que tuvo al comienzo de su carrera, en una startup llamada Takkle. Tras un ascenso repentino, se encontró liderando un equipo que desarrollaba con PHP. Todo iba bien, hasta que un nuevo CTO, que era un referente de la comunidad Perl, decidió que debían reescribir todo el sistema en dicho lenguaje.

La decisión se justificó con un análisis técnico que, en retrospectiva, dice Francia, parecía más una excusa que una evaluación real.

El resultado fue devastador: la productividad se desplomó, el equipo tuvo que perder tiempo en aprender un nuevo lenguaje, el gasto mensual se duplicó y la empresa perdió su oportunidad en el mercado. Takkle, que era una prometedora red social universitaria, murió antes de poder competir, mientras que Facebook —casualmente, también construido en PHP en esas fechas— despegaba y se expandía.

La pregunta que persiguió a Francia durante años fue: ¿cómo pudo un líder tan experimentado tomar una decisión tan costosa?

En Genbeta

Es el lenguaje de programación más popular, pero vienen malos tiempos para él. Estas son las debilidades de Python

La respuesta llegó mucho después: no fue una decisión técnica, fue una decisión de identidad. El CTO no quería desarrollar la mejor plataforma posible; quería ser "un CTO de Perl". La reescritura no fue una estrategia tecnológica, sino el precio de sostener una identidad profesional.

El patrón que se repite en todas partes

Décadas después, Francia ha observado el mismo fenómeno una y otra vez. En Google, en MongoDB, en startups y grandes corporaciones. Equipos enteros discutían apasionadamente sobre lenguajes —C++, Java, Go, Python, Rust—, pero las argumentaciones técnicas eran sólo 'de cara a la galería'.

En un caso reciente, un vicepresidente de ingeniería propuso migrar a Rust un proyecto de 50 millones de dólares. Su presentación destacaba ventajas reales del lenguaje, pero curiosamente no había considerado alternativas obvias como Go, que superaba a Rust en varios de los criterios que el propio equipo había establecido.

Cuando Francia le preguntó si habían comparado otras opciones, el ejecutivo respondió: "En realidad, no. Todo el mundo está hablando de Rust".

Ese fue el momento de epifanía: la elección ya estaba hecha antes del análisis. No se trataba de un estudio técnico, sino de una justificación racional para una decisión emocional.

La ciencia detrás del sesgo

Las neurociencias han demostrado que cuando se desafían creencias centrales de nuestra identidad, nuestro cerebro reacciona como si estuviera siendo atacado físicamente. En estudios con resonancia magnética funcional (fMRI), los investigadores observaron que cuando una creencia periférica era cuestionada, el cerebro respondía con razonamiento lógico...

...pero cuando la creencia formaba parte de la identidad —como una ideología política o religiosa— se activaban la amígdala (centro del miedo) y la corteza insular (que procesa el dolor emocional y el asco). El cerebro no evaluaba evidencia: se defendía.

Los desarrolladores no son inmunes a este mecanismo. Evaluar un lenguaje alternativo puede percibirse, inconscientemente, como una amenaza a la propia identidad. Cambiar de opinión implicaría imaginar una versión distinta de uno mismo. Y por eso, incluso frente a datos objetivos, seguimos aferrados a nuestras preferencias.

En Genbeta

El kernel de Linux lleva desarrollándose 34 años. Un debate sobre lenguajes de programación está logrando intoxicar el proyecto

Una industria construida sobre la conversación equivocada

Cada vez que los desarrolladores discuten sobre lenguajes, hay dos conversaciones ocurriendo a la vez. Una es la visible, repleta de argumentos técnicos ("Go compila más rápido", "Python tiene la mejor biblioteca de machine learning"...) y otra es invisible, y la que más le importa a los interlocutores ("Soy un programador de Rust, y quiero ser reconocido como tal").

El problema es que la industria ha institucionalizado esta dinámica. Se hacen debates, benchmarks, matrices de decisión y comparativas que fingen objetividad. Pero si quien lidera la evaluación es un entusiasta de cierto lenguaje, el resultado está decidido desde el principio. La empresa simplemente gastará millones en validar una elección emocional con datos que la respalden.

El costo invisible de la identidad

El sesgo no solo afecta la productividad; tiene un costo financiero enorme. Estudios de la industria, como el de Stripe sobre el "coeficiente del desarrollador", estiman que los ingenieros dedican el 42% de su tiempo a gestionar deuda técnica (las consecuencias a largo plazo de tomar atajos en el desarrollo de software), buena parte de la cual surge de decisiones erróneas sobre el lenguaje y/o framework a usar.

Si cada cambio de lenguaje o de framework implica reaprender, rehacer y recontratar, el costo total puede representar hasta la mitad del presupuesto de desarrollo a lo largo de un producto.

Por ello, Francia propone un cambio de paradigma. En lugar de preguntarnos "¿qué lenguaje es mejor?", deberíamos plantearnos "¿Cuánto nos costará esta decisión?". El objetivo no es eliminar el factor emocional (eso sería imposible), sino hacer visibles los costos invisibles y permitir que las decisiones se tomen con base a métricas, en lugar de a 'lealtades'.

Imagen | Marcos Merino mediante IA

En Genbeta | El creador del 'Hola, mundo' y gurú de C ha probado a programar en Rust: "En otro lenguaje serían 5 minutos, con Rust me costó días" 

Durante casi una década, un pequeño detalle del idioma turco estuvo provocando que el lenguaje de programación Kotlin —uno de los pilares del desarrollo moderno para Android— generara errores aparentemente inexplicables. Lo que comenzó como un mensaje en un foro en 2016 terminó convirtiéndose en un sorprendente hito de la historia de la ingeniería de software: un idioma humano que consiguió 'romper' un lenguaje de programación.

Un error difícil de entender

En marzo de 2016, el ingeniero turco Mehmet Nuri Öztürk publicó un mensaje en el foro de Kotlin. Su código no compilaba, y el compilador mostraba un error críptico:

Unknown compiler message tag: INFO

Nadie sabía qué significaba. Kotlin acababa de lanzar su versión 1.0, y todo indicaba que se trataba de un fallo menor. Sin embargo, pasaron meses antes de que otro programador, Muhammed Demirbaş, sospechara que el problema no tenía nada que ver con el código… sino con el idioma del sistema operativo.

La “I” turca que confundió al compilador

En la mayor parte de lenguas con alfabeto latino, la letra "I" se convierte en "i" al pasar a minúsculas. Pero en turco existen dos variantes de la letra:

• "i" con punto → mayúscula “İ”
• "ı" sin punto → mayúscula “I”

Así, mientras "INFO".toLowerCase() en inglés produce "info", en turco devuelve "ınfo", con una ı sin punto. Esa diferencia minúscula provocaba que el compilador de Kotlin no encontrara la categoría de mensaje esperada y fallara con un error incomprensible.

El error se documentó oficialmente como KT-13631: "Compilation fails on Turkish locale because of locale-sensitive uppercasing". Pero quedó enterrado entre cientos de tickets y no se solventó. Nadie sospechaba que aquel detalle iba a causar más estragos años después.

En Genbeta

Así se convirtió Kotlin en el lenguaje de referencia para los desarrolladores en Android

Cuando las corrutinas heredaron el bug

En 2018, Kotlin lanzó su versión 1.3 con una de sus funciones estrella: las corrutinas, un sistema para manejar tareas asíncronas de manera elegante. Fue entonces cuando el problema lingüístico resurgió con fuerza.

El desarrollador turco Kemal Atlı reportó un error al actualizar su app:

java.lang.NoSuchMethodError: No static method boxİnt(I)Ljava/lang/Integer;

La clave estaba en el nombre del método: boxİnt(), con una “İ” mayúscula con punto. El compilador, al generar código para las corutinas, usaba la función capitalize() para construir nombres de métodos como boxInt(). Pero, al ejecutarse en un sistema configurado en turco, convertía “int” en “İnt”, y el compilador buscaba un método que no existía.

Ese error concreto se resolvió en 2019 al especificar explícitamente el uso del idioma inglés en la llamada a capitalize(Locale.US). Pero ya era evidente que el problema iba mucho más allá de una simple función.

Un tercer bug y la solución definitiva

Dos años después, otro desarrollador turco, Muhittin Kaplan, reportó un nuevo fallo: su sencillo programa con intArrayOf() fallaba con un NoSuchMethodError. De nuevo, el culpable era el mismo: el método decapitalize() había devuelto "ıntArray" (con ı sin punto) en lugar de "intArray".

Finalmente, la respuesta del equipo de Kotlin fue contundente: buscar y corregir todas las operaciones de cambio de mayúsculas/minúsculas dependientes del idioma en el compilador. En total, 173 líneas de código y 53 archivos fueron modificados, reemplazando las funciones toLowerCase(), toUpperCase(), capitalize() y decapitalize() por versiones independientes del 'locale'.

En mayo de 2021, con el lanzamiento de Kotlin 1.5, el histórico bug KT-13631 se cerró oficialmente, cinco años después de su primer reporte.

En Genbeta

China no sería una potencia tecnológica si este científico preso no hubiera descifrado cómo escribir mandarín con teclado QWERTY

Kotlin cambia su propio lenguaje por culpa de un idioma humano

El impacto fue tan profundo que el equipo de JetBrains publicó la propuesta KEEP-223: “Locale-agnostic case conversions by default”, para rediseñar por completo la forma en que Kotlin maneja las conversiones de mayúsculas y minúsculas.

A partir de Kotlin 1.5 se introdujeron las nuevas funciones uppercase() y lowercase(), que ignoran el idioma del sistema. Y desde Kotlin 2.1 (noviembre de 2024), el uso de las antiguas toLowerCase() y toUpperCase() genera un error de compilación. Incluso capitalize() desapareció definitivamente, reemplazada por replaceFirstChar { … }.

En otras palabras: el idioma turco obligó a cambiar la biblioteca estándar de Kotlin y a redefinir funciones que existían desde su nacimiento.

Más que un bug: una lección sobre lenguaje y cultura

Al final, un carácter sin punto fue suficiente para confundir compiladores, bloquear proyectos y obligar a los ingenieros de JetBrains a replantear cómo su lenguaje debía entender el texto. Pero el problema no estaba en la lengua turca ni en los programadores de Kotlin, sino en una presunción que demostró ser injustificada: que el 'alfabeto inglés' (la variante inglesa del alfabeto latino, siendo precisos) era el estándar universal para la informática.

Vía | Medium

Imagen | Marcos Merino mediante IA

En Genbeta | "Usar lenguaje natural no simplifica el trabajo". En 1979, esta leyenda de la programación ya vio venir los riesgos del 'vibe coding' 

Simon Højberg, ingeniero frontend, ha publicado en su blog un texto que es algo más que una crítica al uso de la IA en el desarrollo de software: no se queja porque la IA "venga a quitarnos el trabajo", sino porque —según él— está borrando la misma identidad cultural del programador.

La programación, dice, siempre fue un acto de precisión, artesanía y pensamiento lógico. Hoy, con las herramientas de inteligencia artificial generativa, está mutando en algo completamente contrario a esa idea: en el llamado vibe-coding (recordemos que una posible traducción literal podría ser 'programar por sensaciones').

De artesanos a 'operadores'

Durante décadas, los programadores se definieron como artesanos del pensamiento formal. Su tarea no era solo construir software, sino comprender profundamente los sistemas: cómo funcionan, cómo fallan y cómo se transforman.

En su ensayo, Højberg recuerda sus días programando frente a Vim, su editor de texto. Ahí, dice, encontraba el placer de la creación pura: resolver un rompecabezas lógico con las manos y la mente sincronizadas. Pero ese mundo —según él— se está evaporando:

"Hoy nos piden escribir especificaciones en Markdown en lugar de código. Ya no exploramos los rincones del sistema ni resolvemos acertijos [...] Ahora operamos una nube de agentes que piensan por nosotros".

El vibe-coding reemplaza el oficio por una especie de dirección de orquesta, donde el programador dicta órdenes en lenguaje natural y la IA ejecuta. El problema, dice Højberg, es que eso desconecta al ser humano de su propia herramienta. Ya no somos creadores, sino supervisores: y lo peor es que nos estamos acostumbrando a no entender lo que producimos.

En Genbeta

"Escribir código no es 'lo aburrido', es mi oficio". Este programador ha vuelto al modo texto para evitar la tentación de la IA

El retorno al caos

Para Højberg, el corazón del problema no es la IA en sí, sino el lenguaje con el que programamos cuando la usamos: el lenguaje natural. El nuestro, vaya.

"Los LLMs (modelos de lenguaje) son imprecisos por naturaleza. Tanto en sus propiedades como en la manera en que los instruimos: con lenguajes naturales que se pueden malinterpretar".

"Es curioso que hayamos elegido este enfoque para la computación, considerando cuánto nos incomoda a los programadores el no determinismo. Preferimos la previsibilidad [pero] el código generado por LLMs representa lo opuesto a eso: un caos inconsistente".

Durante más de 70 años, la computación evolucionó buscando la precisión. Los lenguajes de programación formales —desde el ensamblador hasta Python— fueron específicamente diseñados para eliminar la ambigüedad, y el ordenador debía hacer exactamente lo que el humano ordenara. Esa era, de hecho, la belleza del código: la posibilidad de dominar el caos del lenguaje humano mediante estructuras lógicas, reglas y tipos de datos claros.

Con la IA, afirma Højberg, esa claridad se desvanece. El código generado por un modelo de lenguaje puede cambiar con cada intento, aunque el 'prompt' sea el mismo... todo ello porque es probabilístico, no determinista. Y lo peor: puede parecer correcto, compilar incluso, y aun así estar profundamente roto.

Dijkstra tenía razón

Ojo, que Højberg no está solo en su cruzada. De hecho, para justificar su posición, cita a uno de los grandes filósofos de la computación: Edsger W. Dijkstra, pionero de la ingeniería de software y defensor acérrimo del rigor formal.

En 1979, Dijkstra escribió un breve (y ahora visionario) texto titulado “On the foolishness of natural language programming” ("Sobre la tontería de programar con lenguaje natural"). Allí advertía:

"Debemos desafiar la idea de que los lenguajes naturales simplifican el trabajo. [...] La virtud de los textos formales es que su manipulación, para ser legítima, debe cumplir solo unas pocas reglas simples. Son, cuando lo piensas, una herramienta asombrosamente efectiva para excluir todo tipo de sinsentidos que, al usar nuestras lenguas nativas, resulta casi imposible evitar".

Casi medio siglo después, Højberg rescata esa advertencia y la aplica a los sistemas de inteligencia artificial actuales. Su mensaje es claro: volver al lenguaje natural es un retroceso intelectual.

En Genbeta

Este programador, sobre los colegas que recurren a la IA: "No me importa cómo llegó el código a tu IDE, quiero que te importe"

Donde antes buscábamos precisión, ahora aceptamos probabilidad. Donde antes cultivábamos el pensamiento lógico, ahora confiamos en un modelo estadístico que 'adivina' lo que queremos decir.

La pérdida del rigor mental

Programar no es solo dar instrucciones a un ordenador: es una forma de pensar. Cuando un programador traduce su idea a código, está forzando su mente a formalizar, depurar y estructurar su razonamiento. Es ese proceso lo que genera comprensión... algo que con la IA se pierde, y el pensamiento formal se sustituye por el consumo pasivo.

"Hay algo en el código generado por IA que hace que mis ojos se nublen. Lo leo sin atención, abrumado y aburrido. Acepto errores invisibles, siempre que el programa compile".

El programador ya no necesita construir una 'teoría' interna del sistema, como decía el informático danés Peter Naur en su célebre texto 'Programming as Theory Building': Naur sostenía que lo más importante del proceso de programar no es el software resultante, sino el entendimiento que el programador desarrolla al hacerlo, sin esa comprensión, mantener y extender un sistema se vuelve imposible.

El vibe-coding destruye precisamente eso, el contacto directo con la complejidad: la IA oculta el proceso y ofrece resultados opacos... y, así, el código 'funciona' —hasta que deja de hacerlo—, y nadie sabe muy bien por qué.

Imagen | Marcos Merino mediante IA

En Genbeta | El inesperado paralelismo entre el 'vibe coding' y las tragaperras. Este programador explican cómo logran que el usuario se 'enganche' 

Durante la última década, Python ha sido el niño mimado del mundo de la programación: las universidades lo enseñan como primer lenguaje, los gigantes tecnológicos lo usan en ciencia de datos y miles de desarrolladores lo eligen por su sencillez. Se ha convertido en sinónimo de accesibilidad y productividad.

Pero en los pasillos de conferencias, en los repositorios de GitHub y en los foros de desarrolladores, cada vez resuenan más preguntas incómodas: ¿sigue siendo Python la mejor apuesta de futuro? ¿O estamos ante el inicio de un declive silencioso? Esta es la teoría que sostiene Devrim Ozcay, ingeniero de software en Huawei.

El espejismo del crecimiento

Las estadísticas parecen contundentes: Python encabeza rankings como el índice TIOBE o las listas de proyectos en GitHub. Sin embargo, dice Ozcay, al mirar de cerca descubrimos que gran parte de esta "popularidad" corresponde a principiantes que lo usan durante uno o dos años y luego lo abandonan. El resultado: una comunidad enorme, pero con escaso peso de desarrolladores experimentados. Es como un estadio lleno de aficionados que entran y salen sin llegar a formar un equipo sólido en el campo.

El fantasma del rendimiento (y la sombra de Rust)

Quienes trabajan con Python lo saben: el lenguaje es cómodo, pero bastante lento en comparación con alternativas modernas. Lo novedoso es cómo los desarrolladores están respondiendo a este problema: escribiendo partes críticas en Rust, un lenguaje más rápido y seguro.

Ya no se trata solo de extensiones en C (como en el pasado), sino de bibliotecas de Python reescritas casi por completo en Rust. Ejemplos como Polars (alternativa a pandas), Pydantic v2 (validación de datos) o Granian (servidor web ASGI) muestran una tendencia clara: hasta dentro de la propia comunidad Python, se busca escapar de sus limitaciones.

¿Demasiado fácil para ser bueno?

El marketing de Python siempre ha apostado por destacar su facilidad de uso. Esto atrajo a miles de nuevos programadores, pero al mismo tiempo generó una paradoja: un gran número de usuarios no profundiza en fundamentos como la gestión de memoria o la optimización.

El resultado es una espiral: código poco eficiente → más consumo de hardware → menos motivación para mejorar. Mientras tanto, quienes buscan construir sistemas de alto rendimiento optan por lenguajes que exigen comprender más a fondo lo que ocurre bajo el capó.

Un lugar secundario en las empresas

Aunque muchas grandes compañías usan Python, su papel suele ser periférico: scripts de automatización, análisis de datos, prototipos rápidos. Para sistemas centrales donde importan la confiabilidad y la velocidad, prevalecen lenguajes como Java, C# o Go. Esto refuerza la percepción de Python como una herramienta útil, pero sin poder aspirar al corazón tecnológico de las organizaciones.

Engañosa popularidad en IA

Python viene siendo conocido como "el lenguaje de la IA" desde hace ya tiempo. Sin embargo, lo cierto es que en bibliotecas como TensorFlow, PyTorch o NumPy (que son las que le han dado esa fama), el trabajo duro lo hacen C, C++ y CUDA. Python actúa meramente como una interfaz, una especie de "volante" que dirige un motor construido en otros lenguajes.

A medida que los modelos de IA se despliegan en móviles o sistemas embebidos, donde cada ciclo de CPU cuenta, esta capa extra se convierte en un lastre. Y muchas compañías ya están experimentando (aquí también) con Rust, Go o incluso TypeScript para pipelines de IA más eficientes.

En Genbeta

Este conocido hacker sorprende al decir que todo programador debería aprender C y ensamblador. Musk lo contrató para arreglar Twitter

Una fundación en números rojos

La Python Software Foundation (PSF) es la organización que financia el desarrollo central, mantiene el repositorio PyPI y coordina la comunidad. Sin embargo, sus últimos informes financieros muestran pérdidas millonarias y la necesidad de suspender programas de apoyo. En 2024, incluso tuvieron que pedir ayuda a empresas para poder organizar PyCon, la conferencia más importante del ecosistema. Que la institución responsable de la infraestructura del lenguaje esté al borde de la insolvencia genera un comprensible nerviosismo.

El talón de Aquiles: sostenibilidad

Buena parte del ecosistema de Python se mantiene gracias a trabajo voluntario y donaciones. Librerías críticas dependen de una o dos personas, lo que deja a la comunidad vulnerable al desgaste o abandono de esos mantenedores. La fragilidad financiera de la PSF es solo la punta del iceberg: la sostenibilidad a largo plazo está en juego.

Versiones nuevas que no despegan

Otro signo preocupante es la baja adopción de las versiones más recientes que va lanzando la citada fundación: apenas un 15% de los desarrolladores usa Python 3.13. Esto contrasta con lenguajes como Go o JavaScript, donde los equipos de desarrollo actualizan en cuestión de meses. El resultado es un ecosistema fragmentado, con una mayoría de proyectos estancados en versiones antiguas, lo que dificulta la innovación y la seguridad.

Herramientas que desesperan

El manejo de entornos virtuales y paquetes sigue siendo uno de los mayores dolores de cabeza para la comunidad: herramientas como pip, conda o poetry compiten entre sí y suelen generar conflictos. Mientras tanto, otros ecosistemas ofrecen experiencias más sencillas: Rust con su cargo, Go con sus módulos integrados, o JavaScript con npm y yarn. La respuesta en Python suele ser "usa Docker"... pero esa no es una solución, sino un parche.

¿Un futuro escrito en otros lenguajes?

Nadie (tampoco Ozcay) piensa que Python vaya a desaparecer mañana. Como ocurrió con COBOL, probablemente siga presente en universidades, scripts heredados y proyectos de ciencia de datos. Pero cada vez más indicios apuntan a que su rol como lenguaje de futuro está en entredicho, y que las energías innovadoras parecen moverse hacia otros horizontes: Rust por su seguridad y rendimiento, Go por su simplicidad en sistemas distribuidos, TypeScript por su popularidad en la web, o incluso nuevos jugadores como Kotlin y Zig.

Imagen | Marcos Merino mediante IA

En Genbeta | Su jefe se rio de él cuando le propuso usar Python: "Limítate a usar Excel, ya le cogerás el truco" 

Cuando hablamos de lenguajes de programación "difíciles" y/o "odiados", es relativamente habitual que surjan nombres como C++, Java, PHP o incluso JavaScript. Sin embargo, para muchos programadores veteranos, hay un lenguaje que se lleva la palma como el peor de todos: GW-BASIC.

A pesar de haber sido el punto de partida en la programación para miles de personas en los años 80, este lenguaje representaba una auténtica pesadilla en términos de usabilidad, estructura y mantenimiento del código.

El escritor y desarrollador Huw Collingbourne ha explicado en su canal de YouTube todas las razones legítimas para tenerle cierta "inquina" a este lenguaje.

Los orígenes de GW-BASIC

A principios de la década de 1980, la informática personal comenzaba a despegar. Los primeros PC con MS-DOS solían incluir, de forma gratuita, un lenguaje de programación básico: GW-BASIC. El nombre nunca tuvo un origen oficial claro; algunos lo atribuían a 'Gee Whiz' ("¡Caramba!", en inglés), como una expresión de sorpresa ante la programación de software.

La gratuidad y disponibilidad de GW-BASIC lo convirtieron en el primer lenguaje de muchos programadores autodidactas, pero también en la fuente de frustraciones que marcaron sus inicios.

Obstáculos que hoy resultan impensables

Y es que, comparado con cualquier lenguaje moderno, GW-BASIC parecía más un campo minado que un entorno de programación. Lo que para nosotros hoy es lo mínimo esperable en un lenguaje o en un editor, simplemente no existía en aquellos años.

I) La tiranía de los números de línea

El rasgo más característico (y temido) de GW-BASIC era la necesidad de numerar cada línea de código. Así, un programa típico podía comenzar con algo como:

10 LET X = 1
20 X = X + 1
30 IF X > 10 THEN GOTO 100
40 PRINT X
50 GOTO 20
100 END

¿Por qué se dejaban saltos de diez en diez? Fácil: para poder insertar nuevas instrucciones después. El problema surgía cuando el espacio intermedio no era suficiente: si querías añadir veinte líneas entre el 10 y el 20, te encontrabas con un callejón sin salida.

La única solución era mandar el flujo de ejecución a otra parte del código, a veces en la línea 5000 o 10000, generando lo que más tarde se conoció como 'código spaghetti': un enredo de saltos ininteligibles y difíciles de mantener.

II) GOTO: la receta para el caos

En lugar de estructuras modernas como funciones o procedimientos con nombres claros, GW-BASIC dependía de comandos GOTO y GOSUB. Estos trasladaban la ejecución a otra línea del programa, sin ofrecer contexto ni modularidad. El resultado era un laberinto de saltos donde seguir la lógica del programa era casi imposible.

Los programadores que venían de lenguajes más estructurados, o que luego pasaron a Pascal o C, recuerdan con horror la dificultad de depurar errores en medio de ese enredo de instrucciones.

III) La ausencia total de herramientas de depuración

Hoy en día damos por sentado que podemos detener la ejecución de un programa, inspeccionar variables, establecer puntos de ruptura e incluso visualizar la pila de llamadas. En GW-BASIC, nada de eso era posible. La única manera de entender qué estaba fallando era llenar el código con instrucciones PRINT estratégicamente colocadas:

100 PRINT "X vale "; X
110 PRINT "Entrando en el bucle"

Esto no solo ensuciaba el programa, sino que generaba aún más caos al obligar al programador a borrar, mover o añadir estas líneas de depuración improvisada.

IV) La imposibilidad de estructurar el código

GW-BASIC carecía de funciones y procedimientos con nombres significativos. Toda la lógica debía organizarse en una secuencia lineal, con saltos mediante GOTO o GOSUB. Esto significaba que no existía la reutilización real de código: cualquier comportamiento que se repitiera debía escribirse varias veces o resolverse con un salto a otra línea numerada.

El resultado era un monstruo difícil de leer, mantener o ampliar. En contraste, incluso los lenguajes contemporáneos como Pascal ya ofrecían módulos bien definidos, lo que marcaba la diferencia entre un programa caótico y uno comprensible.

En Genbeta

Esta monja creó el lenguaje BASIC (y se convirtió en la primera doctorada en computación) 24 años después de entrar en el convento

V) Tipado implícito y frágil

GW-BASIC tenía un enfoque 'liberal' en lo que a las variables respecta: no hacía falta declararlas. Bastaba con usarlas y el intérprete asignaba un tipo según el contexto. Esto, que hoy asociamos a lenguajes dinámicos modernos como Python o Ruby, en GW-BASIC era una trampa sin red de seguridad.

Un error de tipeo en el nombre de la variable (total frente a totla) podía crear una nueva variable sin avisar. Operaciones tan simples como sumar un número a una cadena podían provocar fallos catastróficos.

VI) Un editor rudimentario

El propio entorno de GW-BASIC era otra limitación: no había resaltado de sintaxis, ni autocompletado, ni ayuda contextual. El programador escribía a ciegas, sin soporte visual que le ayudara a detectar errores.

Para modificar un programa largo había que recordar el número exacto de la línea a editar. Insertar o eliminar fragmentos enteros se convertía en una tarea titánica, y más de un proyecto acababa abandonado porque reorganizarlo resultaba más complejo que volver a escribirlo desde cero.

VII) Sin archivos fuente legibles

Aunque GW-BASIC permitía guardar los programas, estos se almacenaban en un formato propio y no siempre fácil de compartir o versionar. La idea de un control de versiones —algo básico hoy en día con Git— era completamente impensable en aquel contexto. Cada copia del programa era, literalmente, la última y única versión válida, lo que hacía perder trabajo con frecuencia.

El contraste: Turbo Pascal y la programación estructurada

La salvación para muchos llegó con Turbo Pascal, lanzado a mediados de los 80. Este lenguaje introducía conceptos revolucionarios en comparación con GW-BASIC:

• Declaración explícita de variables.
• Procedimientos y funciones con nombres significativos.
• Tipado estricto y control de errores en tiempo de compilación.
• Herramientas de depuración básicas pero muy superiores.

Pasar de GW-BASIC a Turbo Pascal fue, para toda una generación, como pasar de un laberinto oscuro a una autopista bien iluminada. No solo facilitó escribir programas más fiables, sino que enseñó prácticas sólidas de programación que aún hoy siguen vigentes.

Al final, GW-BASIC puede considerarse un lenguaje de transición: incómodo, limitado y mal diseñado, pero que empujó a muchos hacia opciones mejores. Su legado más importante quizás no sea técnico, sino pedagógico: enseñó, a base de errores y frustración, cómo NO se debe programar.

Imagen | Marcos Merino mediante IA

En Genbeta | Bill Gates publica completo el "código más genial" que ha programado en su vida: esta joya fue la primera piedra de Microsoft

Las entrevistas de trabajo son un mecanismo esencial para lograr conseguir el talento que hace falta en tu empresa, y hay muchas formas de llevarlas a cabo de la mejor manera posible. Hoy vamos a ver una prueba de la que se está hablando en foros y redes para poder contratar a desarrolladores.

La han bautizado como entrevista de "bug squash" y tiene como valor que  puede reflejar el desarrollo de software cotidiano que una persona desarrolla día a día. Es decir, el candidato o candidata debe corregir errores usando diversos lenguajes de programación y no ciñéndose solo a unos pocos.

En Genbeta

Esto es lo más inteligente que puedes decir en una entrevista de trabajo para lograr el puesto, según un experto

El tema ya había sido debatido en Reddit pero una publicación de Jake Zimmerman, un ingeniero de software que ha trabajado en empresas como Stripe, Dropbox y que ahora es profesor de universidad, en su blog, ha puesto visibilidad a esta idea de entrevista y se ha comenzado a compartir en redes como LinkedIn.

Cómo funciona esta entrevista

Explica Zimmerman que necesitarás al menos una pregunta por cada lenguaje en el que deseas permitir que las personas realicen la entrevista. Puedes comenzar con algunos como JavaScript, Python, Java y C++, pero probablemente sea mejor luego ampliar a C#, Objective-C, Ruby, Go, Rust, etc. Si les pides a los candidatos que elijan y se ven obligados a elegir un lenguaje con cuyas herramientas no están familiarizados, es más difícil entender su desempeño.

En Genbeta

Por qué muchos programadores dicen que los lenguajes no importan: el secreto está en el pseudocódigo y la sintaxis

Una entrevista de "corrección de errores" es cuando se le pide a un ingeniero de software que identifique y corrija errores en repositorios de código desconocidos, simulando escenarios más realistas que los desafíos de codificación tradicionales.

Parece que esta opción está ganando popularidad, ya que se considera que está más relacionada con lo que hace realmente un ingeniero de software en su trabajo, por lo que, cuanta más experiencia tenga, es más probable que le vaya mejor.

Una entrevista de correcciones de errores: lo positivo

De acuerdo con Zimmerman, "hay muchas razones por las que me gusta esta entrevista". Por ejemplo, refleja el desarrollo de software cotidiano; es divertido ("porque corregir errores autónomos como este es lo que a muchos de nosotros más nos gusta de la ingeniería de software", añade); es fácil para el candidato autoevaluar su propio progreso porque va viendo si sabe hacer lo que le están pidiendo de forma objetiva, entre otros asuntos.

"Cuando alguien tiene el control total de sus herramientas, esta entrevista lo demuestra mejor que cualquier otra". Para pasar, debes convencer al entrevistador de que la técnica utilizada para encontrar el error es repetible y algo "científica". Y también concluye que "los candidatos que son buenos en esta entrevista lo son porque cuenta con una habilidad que han practicado día tras día durante toda su carrera".

En Genbeta

Procesos de selección interminables: "Llevo 10 entrevistas para una gran tech y quieren otra presentación para todo el equipo"

Por su parte, a los candidatos también parece gustarles este enfoque, ya que es más divertido que un «desafío de codificación» tradicional. El único inconveniente para el director de contratación parece ser el tiempo que lleva producir el script con errores (no es demasiado difícil ni demasiado fácil) y configurar y mantener el entorno de prueba.

Lo negativo de este tipo de procesos

Por su parte, uno de los principales problemas que los expertos ven es que redactar estas preguntas de entrevista lleva tiempo para que sea ideal y no cueste ni muchísimo poner solución al error ni sea muy fácil.

Además, para aquellos para los que sea más sencillo dar solución al error, probablemente querrán seguir utilizando los minutos restantes que el entrevistador le ofrezca para investigar y exponer toda su capacidad, como explica este experto.

En Genbeta

Los programadores españoles responden: cuál es el mejor lenguaje de programación según lo que quieras hacer

También se requiere al menos una pregunta por cada lenguaje que quieras que las personas usen. Si la prueba se ciñe a pocos lenguajes, la empresa puede estar perdiendo talento de gente que domina mucho más otros que no se han incluido en las pruebas.

Imagen | Foto de Nathana Rebouças en Unsplash

En Genbeta | Estos son los lenguajes de programación más demandados por las empresas y que menos desarrolladores dominan

Hace un par de años, repasábamos quién era Bjarne Stroustrup. Si no te apetece hacer clic (hazlo, está muy interesante) te lo resumimos en pocas palabras: se trata del creador del lenguaje C++, uno de los más usados del mundo desde su lanzamiento en 1985.

Por esas mismas fechas, en una mini (muy mini) vídeoentrevista concedida a la plataforma europea de empleo tecnológico Honeypot.io, desvelaba algo curioso sobre su vocación profesional: que terminó dedicándose a la programación "básicamente por un error".

Y es que, tras hacer la Selectividad, y tener que decidir en qué carrera matricularse, decidió que una de sus materias favoritas —Historia— era "una carrera pésima", aunque podía ser "un buen pasatiempo".

"Entonces elegí matemáticas. Pero mientras estudiaba matemáticas quería hacer algo práctico, algo que tuviera algún atractivo más allá de las matemáticas puras. Y me inscribí en lo que en Dinamarca se llamaba "matemáticas con datalogi". "Datalogi" es la palabra danesa para informática, pero yo entonces no lo sabía [Stroustrup entró en la universidad a finales de los 60], pensaba que era una rama de las matemáticas aplicadas".

"Así que me inscribí en esa asignatura y con el tiempo descubrí dos cosas: una, que no era tan bueno en matemáticas como pensaba, cosa que les sucede a la mayoría de los estudiantes de matemáticas, y que la programación era muy divertida […]. Así que todo comenzó cuando un estudiante ignorante escogió algo que no sabía qué era".

Llegó por error, se quedó porque sabía lo que hacía

Pero, como decíamos, por muy fortuita que fuera su llegada a este campo profesional, ha disfrutado de una larga, productiva y exitosa carrera… así que hace unos meses, en otra (igualmente breve) entrevista para Honeypot.io, Stroustrup aprovechaba para resumir sus consejos, tanto laborales como, en general, para la vida de los aspirantes a programador.

Empieza de manera contundente:

"No te especialices demasiado, no estés demasiado seguro de conocer el futuro".

Ambas frases están, claro, directamente relacionadas. Stroustrup explica a continuación que ha visto a demasiados jóvenes especializarse mucho en un campo y comprobar luego, un par de años más tarde, que quizá no lo habían hecho en el campo correcto… incluso si, efectivamente, sí era el correcto cuando empezaron a estudiar para el mismo.

Y es que la tecnología evoluciona que es una barbaridad. Así que, dicho con otras palabras:

"Sé flexible y recuerda que las carreras y los trabajos son algo a largo plazo".

Porque esos jóvenes que Stroustrup ha visto equivocarse apostando por la especialización "se terminan quemando en el proceso".

Y es que la formación de un programador no sólo ser amplia dentro de su campo…

"Mi propia educación fue bastante amplia: he trabajado con compiladores, con múltiples lenguajes —creo que he llegado a conocer dos docenas de ellos—, con arquitectura de máquinas, con sistemas operativos… y todo ese conjunto de habilidades resultó ser útil".

Pero también debe ser amplia fuera del mismo:

"Me encuentro con un montón de 'geeks junior' que piensan que lo único que importa es la especialidad de la informática: la programación o la inteligencia artificial o los gráficos o algo así. Y, bueno, no es así…".

"Nunca me arrepentí del tiempo que le dediqué a la historia y a las matemáticas. Las matemáticas te agudizan la mente, la historia te da una idea de tus limitaciones y de lo que pasa en el mundo".

En Genbeta

Bill Gates cuenta cómo consiguió convertirse en un gran desarrollador: este es su principal consejo

Y es que, según Stroustrup, cuando te formas básicamente lo que estás construyendo es una 'cartera de aptitudes', y por eso nos interesa que esa cartera tiene que ser lo más amplia posible, para ser capaces de reconocer y aprovechar las muchas oportunidades que se nos presentes.

En Genbeta

Más de 300.000 alumnos han estudiado este curso de Python de pago. Su creador decidió regalarlo y podemos hacerlo gratis

Pero ni siquiera se trata de poder aprovechar opciones laborales fuera de la propia programación, porque, incluso si encuentras el trabajo que buscabas en dicho campo, limitarte a codificar no te permitirá tener impacto en el mundo tecnológico, algo que "muchos nerds caricaturescos olvidan siempre".

"Piensan que si pueden escribir el mejor código, cambiarán el mundo. Pero tienes que ser capaz de escuchar. Tienes que ser capaz de comunicarte con tus futuros usuarios y aprender de ellos. Y tienes que ser capaz de comunicarles tus ideas".

Pero más allá de todo eso, nuestro protagonista cree que, a veces, los que se queman lo hacen sencillamente

"Porque no han pasado suficiente tiempo haciendo amistades y teniendo una vida fuera de la informática. […] Tómate tiempo para tener una vida equilibrada".

Haced caso a Stroustrup, gente. Que sabe de lo que habla.

Una versión anterior de este artículo se publicó en 2024.

Imagen | Marcos Merino mediante IA

En Genbeta | La Casa Blanca pidió a la industria que dejara de usar C/C++. Y están de acuerdo con Google en el lenguaje que debe sustituirlos

La web ha evolucionado enormemente desde sus inicios, pero en algunos aspectos cruciales sigue anclada en el pasado. Mientras tecnologías como WebAssembly (WASM) ganan terreno incluso en el servidor, las páginas web que usamos todos los días todavía funcionan con sistemas viejos como el DOM, HTML y CSS, que fueron creados hace décadas y no están pensados para las necesidades de hoy.

En su blog profesional, el desarrollador Steven Wittens ha expuesto con detalle esa idea (y dejado caer, al final, algunas posibles soluciones) en un texto que propone repensar, desde su misma base, los fundamentos del desarrollo web.

¿Qué es el DOM y por qué es un lío?

Cuando visitas una página web, tu navegador construye una especie de "árbol" interno para entender y mostrar el contenido. Ese árbol se llama DOM, que significa Document Object Model o "Modelo de Objetos del Documento".

Imagina que el DOM es como una maqueta de LEGO de la página, donde cada bloque representa un elemento: un título, una imagen, un botón, etc. Suena bien, ¿verdad? El problema es que este sistema se ha vuelto tan viejo y complicado que ya nadie lo entiende del todo bien… ni siquiera los expertos.

Por ejemplo, en Google Chrome, un solo bloque de esa maqueta (document.body, que es básicamente el cuerpo de la página) tiene más de 350 funciones y propiedades diferentes. Y si hablamos del estilo (colores, márgenes, tamaños), hay más de 660 opciones solo para eso.

Es como tener una caja de herramientas tan grande que ya no sabes qué usar, ni cómo. Además:

• Muchas herramientas están obsoletas (ya no se usan, pero ahí siguen).
• Varias hacen lo mismo, pero de formas diferentes.
• Algunas cambian cosas en la página de maneras inesperadas.

Debido a este caos, la mayoría de desarrolladores modernos evitan trabajar directamente con el DOM. Usan herramientas más fáciles y organizadas (como React o Vue), que simplifican todo.

Y aunque hay intentos por mejorar esto, como los Web Components (una forma más moderna de crear partes reutilizables de una página), llegaron tarde y no son muy populares porque son difíciles de usar.

HTML: ¿Y la semántica, dónde quedó?

HTML es el lenguaje básico con el que se construyen las páginas web. Su objetivo original era permitir que los sitios fueran claros y organizados: con títulos, párrafos, listas, artículos, comentarios… todo bien etiquetado.

Eso se llama semántica: usar etiquetas que explican qué es cada parte del contenido, no solo cómo se ve.

Pero, aunque han pasado más de 10 años desde que salió la versión vigente de HTML (HTML5), seguimos sin tener etiquetas para cosas tan comunes como un hilo de conversación (<thread>) o un comentario (<comment>). Eso significa que los desarrolladores tienen que improvisar y usar etiquetas genéricas como <div> o <article>, que no dicen claramente lo que representan.

En Genbeta

No suele considerarse a HTML y CSS lenguajes de programación... pero hay quien no está de acuerdo (y tienen buenos argumentos)

Además, las reglas para usar las etiquetas "correctamente" son confusas. Por ejemplo, según algunas guías, un artículo dentro de otro artículo podría considerarse un comentario... pero eso no tiene mucho sentido, ¿verdad?

Hoy en día, las grandes decisiones sobre cómo evoluciona HTML las toman principalmente los creadores de navegadores (como Google o Apple), no una comunidad abierta. ¿Y qué han hecho? Pues en lugar de rediseñar o simplificar HTML, han ido agregando pequeñas cosas nuevas aquí y allá, como quien sigue parcheando una prenda vieja.

CSS: ¿por qué alinear cosas en la web es tan difícil?

CSS (siglas en inglés de "hojas de estilo en cascada") es lo que usamos para darle forma y colores a una página web: tamaños, márgenes, colores, posiciones, etc. Pero a pesar de ser tan importante… muchas veces parece estar en contra nuestra.

¿Te ha pasado que simplemente quieres poner dos cosas una al lado de la otra, o que algo quede centrado en la pantalla, y por más que lo intentas no pasa lo que esperas? No estás solo.

El problema principal es que CSS no funciona como creemos.

Imagina que tienes una caja con dos cajones adentro y que quieres que cada cajón ocupe la mitad del espacio. Lógico, ¿no?

<div>
 <div style="height: 50%">...</div>
 <div style="height: 50%">...</div>
</div>

Pero CSS no lo entiende así. En realidad, necesita que primero le digas cuánto mide la caja grande. Si no lo haces, simplemente ignora tus instrucciones.

Esto es porque CSS trabaja de una forma algo rara: primero mira el contenido (lo que hay dentro) y luego decide qué tamaño debería tener el contenedor. Es como si compraras una caja para tus cosas... después de ver cuántas cosas tienes.

¿Cómo se soluciona eso? Bueno, el CSS moderno tiene herramientas como Flexbox, que ayudan a distribuir mejor el espacio entre elementos. Pero hasta esas herramientas cuentan con sus propios problemas.

SVG: potente pero caótico

SVG son las siglas en inglés de "gráficos vectoriales escalables". Es una tecnología que permite dibujar cosas como iconos, gráficos, logotipos o ilustraciones directamente dentro de una página web, sin que se vean borrosas al hacer zoom. Resulta útil porque...

En Genbeta

Así se ha ido complicando la arquitectura detrás de las aplicaciones web en los últimos 26 años

• Puedes cambiar el tamaño de un dibujo sin perder calidad.
• Puedes modificar colores, formas o posiciones con código.
• Incluso puedes hacer que reaccione al pasar el mouse o hacer clic.

Pero, aunque SVG sea tan polivalente, usarlo en combinación con HTML y CSS puede volverse un lío por varias razones:

• No 'habla el mismo idioma' que CSS: Aunque a veces puedes aplicar estilos CSS a los dibujos SVG, no siempre funcionan igual. Hay reglas que se comportan diferente o simplemente no aplican.
• Es complejo: Para hacer un dibujo, tienes que escribir instrucciones como <path d="M150 0 L75 200 L225 200 Z" />. ¡Sí, eso es un triángulo! Pero no es precisamente amigable a la vista ni fácil de entender.
• ¿Cuándo usar SVG y cuándo HTML?: A veces puedes hacer una figura con HTML y CSS, otras veces necesitas SVG. Pero no hay una regla clara. Elegir entre uno u otro puede depender de detalles técnicos molestos.
• Algunas cosas útiles solo están en SVG: Por ejemplo, si quieres detectar clics en formas con bordes irregulares (como una estrella), SVG lo hace fácil. HTML y CSS... no tanto.

La pesadilla del 'kitbashing web'

A lo largo de los años, el desarrollo de interfaces web ha evolucionado a base de "parchar" las herramientas existentes. Esto ha dado lugar al fenómeno del kitbashing, un término tomado del modelismo donde se ensamblan modelos a partir de piezas que no estaban diseñadas para funcionar juntas. En la web, esto se traduce en construir interfaces sofisticadas combinando HTML, CSS y SVG en formas para las que nunca fueron concebidos.

Esto ocurre porque HTML y CSS no fueron pensados originalmente para hacer aplicaciones. Se crearon para mostrar documentos, como artículos o noticias, no para hacer cosas como editores de texto tipo Google Docs o chats como WhatsApp Web.

Ejemplos de lo difícil que puede ser:

• Un chat que se quede pegado abajo (como en WhatsApp):
  Parece algo básico, ¿no? Pero lograr que la ventana del chat se quede abajo cuando llega un nuevo mensaje requiere escribir código personalizado cada vez. No hay una forma fácil y automática de hacerlo con HTML y CSS.
• Copiar y pegar texto con formato: Si alguna vez copiaste texto de una página web y lo pegaste en otro lugar, sabrás que a veces se conserva el color o el estilo… y a veces no. Hacer que eso funcione bien en una app web requiere "trucos invisibles", como poner elementos escondidos fuera de la pantalla para que el sistema entienda qué se está copiando.
• Listas y tablas muy largas (como una hoja de cálculo): Mostrar muchos datos (como en Excel) es difícil en una web. Si lo haces directamente, la página se vuelve lenta. Para solucionarlo, los desarrolladores tienen que "engañar" al navegador: solo muestran una parte de la lista y cambian lo que se ve a medida que el usuario se desplaza.
• Cajas que se vean bien en diferentes tamaños de pantalla: Ajustar el diseño para que se vea bien en un celular y en una computadora suena lógico, pero hacerlo con HTML y CSS puede ser muy complicado. A veces hay que escribir muchas reglas específicas, o usar herramientas externas que tratan de hacerlo más fácil.

En Genbeta

Estos son los errores que todo desarrollador web debería evitar (si no quiere perder tiempo y energía), según este experto

Canvas: ¿una solución?

Ante las limitaciones evidentes del DOM y CSS, algunos desarrolladores y estándares emergentes han puesto sus ojos en una alternativa radical: usar <canvas> como plataforma principal para renderizar interfaces. La propuesta más notable en esta línea es HTML-in-Canvas, que plantea la idea de renderizar fragmentos de HTML dentro de un <canvas>, permitiendo personalizar completamente su presentación visual.

Suena atractivo: ¿por qué no aprovechar la potencia gráfica de Canvas para superar las deficiencias del modelo de caja y de estilo del navegador? Pero este enfoque trae consigo una gran cantidad de obstáculos tanto técnicos como filosóficos.

Para empezar, la API propuesta sigue estando atada al DOM, lo que significa que los elementos a renderizar deben seguir existiendo dentro del árbol de documentos para ser interpretables. Esto introduce una contradicción: si necesitas <canvas> para librarte del DOM, ¿por qué seguir dependiendo de él para dibujar?

Además, para lograr interactividad, el sistema obliga a reimplementar el modelo de interacción desde cero: gestión de eventos de mouse, teclas, estados de foco, accesibilidad... todo debe recrearse manualmente.

Se trata de un sistema donde el desarrollador asume el control absoluto, pero también la carga completa, como si estuviera desarrollando usando un motor de videojuegos.

Uno de los principales argumentos a favor de usar canvas es que “al menos es programable”. Pero en realidad, es un recurso extremadamente limitado:

• No tiene acceso directo a fuentes del sistema ni a APIs nativas de layout de texto.
• No ofrece herramientas nativas para manejar accesibilidad, localización o compatibilidad móvil.
• No permite reusar eficientemente estilos, efectos ni interacciones predefinidas del navegador.

¿Y entonces, qué?

Después de todo lo que hemos visto, queda claro que el modelo actual de cómo se construyen las páginas web —usando HTML, CSS y el famoso DOM— está roto, pero eso no significa que no haya solución. De hecho, según Wittens es totalmente posible mejorar todo esto… si nos atrevemos a cambiar las bases. Así que, ¿qué deberíamos hacer?

Empezar con una estructura más clara

Hoy en día, cuando haces una web, terminas mezclando muchas cosas: contenido, estilo y comportamiento. Todo está enredado.
Lo ideal sería separar mejor:

• Lo que se muestra (el diseño).
• Cómo se comporta (la interacción).
• Qué significa cada cosa (la semántica).

En Xataka

La web se ha convertido en un lugar horrendo para mucha gente. Así que están reconstruyendo su versión 1.0 como refugio

Tener estos tres aspectos separados haría que todo fuese más fácil de desarrollar, mantener y escalar.

Diseñar pensando en cómo se hacen apps hoy

Las páginas web de hoy ya no son solo documentos, son aplicaciones completas, como redes sociales, editores de texto, videojuegos… Y para eso necesitamos herramientas más modernas. Cosas como React, Vue o Svelte existen precisamente porque el sistema base (HTML+CSS+DOM) no da la talla.

Así que ¿por qué no rediseñar esas bases para que lo moderno ya venga incorporado?

• Que los cambios en la pantalla sean automáticos cuando cambie algo en el sistema.
• Que podamos mover elementos o cambiar estilos sin pelear con reglas raras de CSS.
• Que el código sea fácil de leer, escribir y entender.

Ya hay ejemplos funcionando

Wittens insiste en que no estamos hablando de fantasías, pues ya hay proyectos reales que ya están probando cómo se podría hacer todo esto mejor. Uno de ellos, por ejemplo, es Use.GPU, un sistema visual hecho con tecnología nueva llamada WebGPU. ¿Qué logra?

• Interfaces mucho más rápidas y suaves.
• Diseños con menos líneas de código.
• Posicionamiento de elementos que por fin tiene sentido (sí, centrar cosas es fácil).
• Efectos visuales sin trucos raros ni dolores de cabeza.

Y esto lo ha hecho una sola persona, con un sistema más claro y moderno que toda la maquinaria actual del navegador.

También hay navegadores nuevos como Servo y Ladybird que están empezando de cero. No arrastran todo el peso de 30 años de web, así que pueden tomar decisiones más inteligentes desde el principio.

Imagen | Marcos Merino mediante IA

En Genbeta | En esto consiste la labor de un desarrollador Full Stack: un perfil laboral todoterreno

Aprender a programar es algo a lo que cada vez más usuarios se apuntan, ya sea a través de distintos niveles académicos, cursos, o de forma autodidacta. Y si bien en Genbeta hemos hablado de infinidad de recursos para aprender a escribir código en múltiples lenguajes de programación, esta web de la que te vamos a hablar es genial para aquellos curiosos que se quieran aventurar en el genial mundo de la programación.

Exercism es un sitio web que recopila recursos de todo tipo para ayudar a los usuarios a aprender a programar. La página incluye ejercicios de hasta 77 lenguajes de programación, todo ello de manera gratuita.

Una web para aprender a programar de forma divertida y fácil

Si alguna vez te has planteado aprender algún lenguaje de programación como Python, JavaScript, Java, C++, C#, Rust y otros tantos, Exercism es una buena guía para comenzar.

El aprendizaje funciona a modo de reto para el usuario, donde en cada lección aprendemos fundamentos básicos de diversos temas. La idea es que el usuario vaya escribiendo código y que esto sirva para ir pasando a niveles más avanzados.

Exercism insiste en que su método será siempre gratis, y se apoya en una gran comunidad con el fin de colaborar y hacer que nuevos miembros puedan aprender a programar. Todas las contribuciones son de libre distribución, aunque sus responsables también aceptan donaciones.

Para comenzar en Exercism, lo único que debe hacer el usuario es registrarse de manera gratuita y escoger el lenguaje de programación que desea practicar. Si bien dispone de niveles para todo tipo de usuarios, Exercism se notará algo menos frustrante si el usuario llega con algunas nociones, aunque sean muy básicas.

En Genbeta

El curso gratis online más famoso para aprender a programar acaba de empezar y aún puedes apuntarte: de Harvard y con certificado

En total, más de un millón y medio de usuarios utilizan los recursos de Exercism para aprender a programar. Además, si te encuentras en problemas con tu código, siempre puedes contar con su comunidad, siendo una de las bases más valiosas de la web. Y es que Exercism cuenta con más de 11.500 mentores, personas que voluntariamente ayudan a otros usuarios a aprender a programar.

Por ponerle alguna pega, merece la pena destacar que la web se encuentra totalmente en inglés. Así que si quieres comenzar a utilizar esta página también sería recomendable que al menos te sepas manejar un poco con el idioma (o tirar de traductor).

Una versión anterior de este artículo se publicó en 2024.

En Genbeta | De todos los cursos de programación que hay, estos son los 13 a los que yo me apuntaría