por Javier Vélez Reyes
«Cuando el ornitorrinco fue descubierto por primera vez por los europeos en 1798, el capitán John Hunter, segundo gobernador de Nueva Gales del Sur, envió un bosquejo y la piel de un ejemplar a Gran Bretaña. A la vista de tan extraño animal, los científicos británicos creyeron encontrarse ante una broma pesada. George Shaw, que en 1799 hizo la primera descripción del ornitorrinco en la revista Naturalist’s Miscellany, afirmó que era imposible no haber mostrado dudas sobre su autenticidad y Robert Knox creyó que podría haber sido creado por algún taxidermista asiático. Se creía que alguien había cosido el pico de un pato al cuerpo de un animal parecido a un castor. Shaw incluso utilizó unas tijeras para comprobar si había suturas en la piel disecada.» (ver el texto completo en wikipedia).
La nueva especie del capitán Hunter no era un ni un pato ni un castor ni una nutría sino un animal con hocico en forma de pico de pato, cola de castor y patas de nutria. Pese a la presión de la comunidad científica ni Hunter ni Shaw mantuvieron un serio diálogo con la especie para convencerla de que debería decidirse por una de las tres morfologías ya conocidas. Simplemente aceptaron que un ornitorrinco es eso, un ornitorrinco.
Sin embargo los informáticos no somos así. Nosotros no queremos ni mimamos paternalmente a nuestro lenguaje como los biólogos cladistas hacen con cada nueva especie descubierta. Nosotros exigimos y vapuleamos a nuestra criatura – en este caso JavaScript – para demandar que se acerque a nuestra forma de pensar porque como toda buena religión, la nuestra es la única y verdadera. Y claro, el pobre JavaScript, tiene que intentar adaptarse a la orientación a objetos para acoger a las hordas de librepensadores que llegan de otros lenguajes como los hunos imponiendo un sistema de tipos fuerte y un sistema robusto de clases para soportar los principios SOLID. O para exigirle encarecidamente que nos de soporte a la encapsulación que es forma doctrinal para articular un sistema de objetos mínimamente computable.
A este efecto, cada vez más extendido en la comunidad mundial de desarrollo, yo he dado en llamarle en mis últimos debates con colegas de la profesión ‘Efecto Ornitorrinco’. La mayoría de las voces detractoras advierten, no sin cierta razón, que JavaScript no es una especie sino un lenguaje de programación. Una herramienta hecho por y para humanos dirigida a facilitarnos la vida en nuestros problemas de desarrollo.
Pero,… ¿de verdad JavaScript no es una especie? ¿Acaso no se le reconoce una clara evolución adaptativa? ¿Existe un mínimo objetivo común o concomitante entre el JavaScript del año 95 y el de nuestros días?
Javascript es un lenguaje vapuleado y vilipendiado con injustos ataques muchas veces más vinculados a la falta de entendimiento y empatía de los desarrolladores exigentes con su pragmática de uso que con una crítica argumentada y racional. Mimemos a nuestra criatura. JavaScript no tiene tipos fuertes, ni soporta sustitución Liskoviana ni cierra los objetos con encapsulación porque no debe. Si lo que buscas es un pato, un castor o una nutria, deja al ornitorrinco bucear en paz. Si lo que quieres es Java, no uses JavaScript.
Veamos porque mola que JavaScript sea tan raro:
A. Sobre tipado. Los sistemas de tipos débiles permiten, entre otras cosas, articular una programación dinámica mucho más flexible de la conseguida con sistemas estáticos. Estos últimos presentan evidentes ventajas en robustez a costa de complicar el sistema de tipos, dificultar las estrategias de compilación y sacrificar tal dinamismo.
B. Sobre SOLID. En JavaScript es imposible articular plenamente los principios SOLID precisamente porque ante un sistema de tipos débiles no se puede restringir el abanico de subtipos candidatos que encajan en un punto de extensión liskoviana. Por contra esto permite articular un nuevo concepto mucho más interesante de conformancia débil dentro del contexto de lenguajes dinámicos como es el uso de contratos parciales según el cual a cada objeto se le exige en cada colaboración que disponga exclusivamente de los métodos necesarios para articular dicha colaboración. Esto conjugado con técnicas meta-programáticas que van dirigidas a adaptar en tiempo de ejecución al objeto con nuevos métodos y propiedades potencia aún más la expresividad dinámica del lenguaje
C. Sobre encapsulación. En JavaScript, nativamente, no existe soporte a la encapsulación, aunque si se han identificado diversas técnicas y patrones para emularla. Nuevamente hay que reclamar que la comunidad tiende a confundir la encapsulación con la protección de la información. La primera – completamente prescindible en sentido estricto – articula mecanismos estáticos para la privatización de información sensible (desarrollados en tiempo de compilación o interpretación). Es un mecanismo que plantea la OOP como una actividad defensiva ante ataques ajenos. Desde una perspectiva de seguridad su defensa resulta imposible de sostener por motivos obvios. La protección de la información por contra se basa en el principio de diseño esencial de la OOP según el cual el cliente de una clase se compromete a no hacer depender el comportamiento de su clase de ciertos métodos y atributos que se consideran a todos los efectos una estrategia de implementación «privada» de la clase proveedora. Este uso del término «privado» es la madre de esta confusión común. Por tanto, en OOP no es imprescindible exigir encapsulación sino al menos un compromiso de protección de información entre proveedor y cliente.
En resumen defiendo la idea de que en general los informáticos debemos madurar para entender el lenguaje sobre el que trabajamos antes de deformarlo exigiendo que se adapte a nuestros gustos e intereses particulares.
Efecto ornitorrinco: Entiende a tu mascota, no la intentes cambiar.
Javier Vélez Reyes
Ph. D. Computer Science
@javiervelezreye
Novedades
HTTP2 para programadores. Enviar mensajes del servidor al cliente con Server Sent Event (sin WebSockets)
En esta charla, organizada por MadridJS, Pablo Almunia nos muestra cómo la mayoría de nosotros cuando oímos hablar por primera vez de HTTP2 nos ilusionamos con las posibilidades que presumiblemente se abrían para el desarrollo de soluciones web avanzadas y cómo muchos nos sentimos defraudados con lo que realmente se podía implementar.
En esta charla podemos ver cómo funciona el HTTP2, que debemos tener en cuenta en el servidor para hace uso de este protocolo y, sobre todo, cómo podemos enviar información desde el servidor al cliente de forma efectiva y fácil. Veremos con detenimiento cómo por medio de los Server-Sent Events (SSE) podemos recibir en el cliente datos enviados desde el servidor sin utilizar websocket, simplificando enormemente la construcción de aplicaciones con comunicación bidireccional.
Observables en Javascript con Proxies
En esta charla, organizada por MadridJS, Pablo Almunia nos habla de la observación reactiva de objetos en Javascript por medio de Proxy. Se describe paso a paso cómo funcionan los Proxies y en que casos pueden ser nuestro mejor aliado. Veremos que no hay que tenerles miedo, son bastante sencillos de utilizar, y nos ofrecen una gran abanico de posibilidades.
Aplicaciones JAMStack, SEO friendly y escalables con NextJS
En esta charla de Madrid JS, Rafael Ventura nos describe las funcionalidades clave de NextJS, nos muestra en vivo cómo desarrollar una completa aplicación JAMStack con Server Side Rendering (SSR) y Static Site Generation (SSG) y termina mostrando como publicar esta aplicación en Vercel.
Stencil JS: mejora el Time To Market de tu producto, por Rubén Aguilera
En esta charla Rubén Aguilera nos cuenta los problemas que tienen muchas empresas a la hora de sacar productos accesibles, vistosos y usables en el Time To Market que requiere Negocio y cómo podemos minimizar este tiempo gracias al DevUI con StencilJS para adecuar una aplicación de Angular a las exigencias del mercado en tiempo record.
«Si lo que buscas es un pato, un castor o una nutria, deja al ornitorrinco bucear en paz. Si lo que quieres es Java, no uses JavaScript»
Es interesante hacer el ejercicio de preguntarse porque hay ciertos lenguajes siempre en el punto de mira, y cual es la razón de ello. No es por su naturaleza que se les critica, sino por la naturaleza de su contexto, y la incapacidad de libre elección.
La frase citada, fuera de contexto, es completamente defendible. Pero a mi modo de ver, no es este el foco del conflicto. El foco del conflicto radica en que tanto si la naturaleza del proyecto requiere de versatilidad y flexibilidad, o por lo contrario, de robustez y claridad estructural, no hay elección, solo hay ornitorrincos en el ecosistema del navegador web. Antaño esta limitación del ecosistema no era evidente, pero cada vez más, hay proyectos web de tal envergadura y complejidad, que requieren tipados fuertes, compiladores útiles, y claridad estructural. La fricción aumenta, las limitaciones (no del lenguaje, del ecosistema!) se hacen patentes, y la gente empieza a alzar la voz.
El problema es que frecuentemente el foco de las quejas es erróneo; Javascript no es un mal lenguaje per se, sino que ha dejado de ser el lenguaje correcto para muchos de los proyectos web, y que aun así no tienen (tenían) elección. Del mismo modo, Java no es un lenguaje demasiado complejo ni demasiado estricto, sino que lo es para algunos proyectos que aún así les es impuesto el lenguaje por razones ajenas.
El problema que yo veo que es que realmente yo no quiero usar JavaScript pero me veo «obligado» a ello.Así que lo intento transformar en «Java» porque es realmente lo que me gustaría seguir usando. Y cuando veo que no puedo hacer lo mismo, para lo que pasa.
Para los «Javeros» mi opinión es que empecemos a usar TypeScript y dejemos de quejarnos de JavaScript.