javascript El Efecto Ornitorrinco.Oct 1st, 2015

El Efecto Ornitorrinco

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. 1

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.

Efecto ornitorrinco. Entiende a tu mascota, no la intentes cambiar.

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:

  • 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.
  • 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
  • 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.

Deja tu comentario