¿Qué pasa con JavaScript?. Un lenguaje que pronto cumplirá 20 años, pero del que siempre se debate como si fuera ayer cuando se propusiera por primera vez para controlar las dinámicas de nuestras páginas. Sin duda no existe una única razón por la que los programadores estamos tan polarizados hacia el mencionado lenguaje y de ellas, creo que pocas podrían explicarse de forma clara y objetiva. Dame diez programadores y encontraré no menos de cincuenta razones para usarlo y otras cincuenta para no usarlo.
Sabedor del jardín en el que me meto, me atrevo a comentar, analizar (por fuerza informalmente) tan variopinta e interesante cuestión.
Posición subjetiva
Intuyo que me resultará tremendamente difícil (si no imposible) comentar de forma objetiva el porqué otros programadores aman u odian un lenguaje. Inevitablemente también, deberé comentar lo positivo y negativo de determinadas características pero ¿positivo y negativo para qué?, ¿para quien?, ¿en que contexto?. Confío que sabrás graduar el peso de mis palabras en cada caso.
Me posicionaré entonces diciendo que, mucho se dice de JavaScript que "lo amas o lo odias", pero aventuro que somos muchos los que lo "amamos y odiamos". Lo amo porque es un lenguaje tremendamente plástico y expresivo, con una sintaxis muy sencilla y fácil de leer y combinar (otra cosa es la gramática); pero lo odio porque es anárquico, indisciplinado y, aunque él no tiene culpa, caótico en su aplicación última (el explorador web).
Por ello y a modo de aviso previo, amo JavaScript para jugar, y lo odio para trabajar.
JavaScript, el cajón de sastre
Es posible que no te guste la siguiente metáfora, pero una imagen que tengo fuertemente asociada con JavaScript es que es un cajón de sastre en el que todo entra y todo vale. Dicha aproximación la utilizo, quizás injustamente, con la mayoría de lenguajes dinámicos. Si dejamos a un lado la sintaxis y consideramos únicamente los elementos del lenguaje, éstos podríamos resumirlos en lo siguiente:
-
Cualquier cosa es un array asociativo (un diccionario).
-
Cualquier cosa se puede comportar como cualquier cosa (un número es una cadena, una función es un booleano, etc...).
Salvando la sintaxis, sólo estas dos características hacen de un lenguaje un "todo vale". Por supuesto que habría que analizar los detalles porque, por ejemplo en JavaScript, no podemos evaluar como función un número ¡pero podría hacerse sin cambiar la esencia de JavaScript! (en lugar de elevar una excepción, podría asumirse que evaluar un objeto como una función da como resultado el objeto mismo, es decir, la identidad).
Es muy posible que todos y cada uno de los elementos del lenguaje JavaScript hayan sido pensados y "puestos ahí" con un fin concreto y anticipado y que yo no sea capaz de ver pero, en conjunto, yo me atrevo a aventurar que el actual comportamiento de JavaScript ha emergido de forma "descontrolada", con decisiones bien pensadas y analizadas si, pero en hitos y por razones muy dispares tanto contextualmente como temporalmente. Con "descontrolada" no quiero decir sin sentido, quiero decir, que se ha ido adaptando y tomando soluciones de compromiso en una dificilísima situación contextual (ej. millones de antiguas páginas web y herramientas asociadas que deben seguir "funcionando").
Incertidumbre
No cabe duda que cada elemento del lenguaje habrá sido analizado y pensado meticulosamente por especialistas (o yo prefiero pensar que ha sido así), pero ello no hace al producto resultante mejor de lo que realmente es. Por ejemplo, que "cualquier cosa puede ser cualquier cosa" introduce una incertidumbre en el programador, ¿que resulta de la expresión "a + b"?, ¿y de la expresión "a || b"?, por supuesto que una vez analicemos todos los casos, "entenderemos" la forma en que funciona y la incertidumbre desaparecerá; sabremos codificar en JavaScript el comportamiento que deseamos, así, a priori únicamente podemos decir que, quizás, existen más reglas a tener en cuenta para saber expresar determinado comportamiento que deseamos (a priori y sin analizar nada más, ésto no lo hace ni mejor ni peor lenguaje).
Pero habrá que admitir que, cuando menos, algunos resultados son "chocantes":
Con sólo ver los ejemplos anteriores no es difícil ver como actúan ambos operadores, pero la conversión implícita a cadena de ciertos tipos ("null" y "undefined") parece razonablemente "desconcertante" o la curiosa (e ingeniosa) aplicación del operador (||), a simple vista, que la conmutación altere el tipo resultante es notoriamente chocante o también, el como se resuelven (ingeniosamente) las expresiones (undefined || null || undefined) es ya rizar el rizo.
La lista de cosas (que razonablemente son objetivamente) "chocantes" (o poco/nada intuitivas) es muy larga en JavaScript, como this o el resultado de la siguiente ordenación de números se hace lexicográficamente:
No tiene sentido enumerar aquí todas las cosas "chocantes" y por otro lado, no hay problema a priori con esas cosas, simplemente decimos "¡oh! bueno, por defecto la ordenación es lexicográfica, está bien".
Pero... ¿quién se atreve ahora a decir cómo se ordenará una lista de fechas en lugar de una de números?, porque claro, los números decimales tienen (prácticamente) la misma representación en todo el mundo, ¿pero las fechas?, ¿debemos suponer que la ordenación será lexicográfica y basada en la representación local y/o en las preferencias de usuario?. Pues por "chocante" (o no) que pueda parecer, también ordena lexicográficamente (¿era de esperar?).
Quizás lo más "gracioso" ¡es que ésto tampoco es un problema a priori!, para resolver la incertidumbre, basta con saber como funciona realmente la función sort (por ejemplo en ECMA-262/5.1).
Así, todas estas "curiosidades" no hacen, a priori, que JavaScript sea peor o mejor lenguaje. Por desconcertante que nos pueda parecer el operador (||) al principio, es una forma ingeniosa y divertida de "procesar predicados". Si JavaScript hubiera sido el primer lenguaje, probablemente esta forma sería "la normal" para nosotros, pero resulta que no ha sido así...
Radio de acción de JavaScript
Cuestión añadida y que no es específico del lenguaje, es que normalmente nuestro código JavaScript deberá correr en diferentes implementaciones (interpretes) y a la "originalidad" planteada antes, hay que añadir comportamientos para diferentes versiones, por ejemplo, terminar un array en el último elemento con o sin coma, tiene comportamiento diferente (por poner un ejemplo, en unos casos la última coma es ignorada y en otros se considera un último elemento "undefined").
Aunque esté ya muy alejado del propio lenguaje, si extendemos nuestro análisis al soporte que las plataformas dan al lenguaje (eventos, utilería, red, ...) habrá que aceptar que, al menos hasta hoy mismo (véanse cuotas de mercado de IE9 e inferiores) ha sido un auténtico calvario. Bien es cierto que ésto está mejorando notablemente.
Bien, bien, asumamos que tampoco eso es un "problema", esperamos poder detectar la versión en que corre nuestro código y actuar en consecuencia cuando procede en los casos en que no podemos escribir un código más general.
Así las cosas y así asumidas, cuando menos JavaScript (y pronto cumplirá 20 años) es un lenguaje de lo más "peculiar".
Complejidad combinada y el algoritmo de Dios
Sin duda JavaScript es un lenguaje sin control, si pensamos en las posibilidades que el propio lenguaje JavaScript nos ofrece y recordando el algoritmo de Dios, desde cierto punto de vista Dios elegiría JavaScript antes que muchos otros lenguajes (tipados y estrictos principalmente), por la sencilla razón de que Dios no necesita la gran mayoría de restricciones que imponen esos otros lenguajes. Dios podrá representar en JavaScript de forma bastante directa y sin trabas muchas de las "celestiales estrategias" que fueran menester. Y por supuesto no se vería afectado por la intrincada y curiosa red gramatical de la que hace gala JavaScript.
Pero no somos dioses, y la mayoría de los humanos necesitamos y gustamos de tener a nuestro alrededor elementos que nos den seguridad en lo que hacemos y JavaScript no da esa seguridad como si la dan otros lenguajes. Y ojo, porque ésto, tampoco hace a priori que sea mejor ni peor; sencillamente y objetivamente JavaScript no da esa seguridad que sólo los dioses no necesitan.
El término complejidad combinada está fuertemente relacionado con esta falta de seguridad, puesto que a medida que la cantidad de código aumenta, si no somos dioses, el control que nosotros podemos realizar explícitamente sobre la calidad del software decrece rápidamente.
Por tanto, podemos afirmar objetivamente que JavaScript no da seguridad al programador frente a las anteriores situaciones y éste (el programador) debe buscarlas en otro sitio (haciendo tests, por ejemplo).
Otra vez ésto, a priori, tampoco hace al lenguaje ni mejor, ni peor (simplemente no da la seguridad que sí dan otros lenguajes con las ventajas e inconvenientes que ello conlleve).
A posteriori
Todos los a priori mencionados anteriormente (y hay muchos más, pero no pretendo hacer un compendio) no hacían a JavaScript ni mejor ni peor. Son cosas que son como son y a cada programador pueden gustarle más o menos. Un programador que guste de hacer test para todo no verá ningún problema en que JavaScript "no sea seguro". Un programador que guste de implementar soluciones originales e ingeniosas no verá ningún problema que JavaScript no tenga soporte explícito a (por ejemplo) la programación orientada a objetos (con la seguridad que ello conlleva). Un programador que tenga muy buena memoria o dedique muchas horas al día a programar en JavaScript no entenderá que problema hay con la gramática de JavaScript. Y un largo etc...
Así como lenguaje, JavaScript es uno más, que te podrá gustar más o menos, que tiene ciertas ventajas y ciertos inconvenientes que cada cual valorará subjetivamente.
Amo y odio JavaScript
Sin duda hay muchas cosas que deberíamos agradecer a JavaScript y que sus diseñadores en sus diferentes etapas han sido inteligentes e ingeniosos en sus decisiones. Pero aquí no estamos para dar las gracias, estamos para desarrollar aplicaciones que funcionen, que sean robustas y se adapten a diferentes situaciones y contextos, que permitan introducir modificaciones y mejoras sin miedo a que se rompa el código, a poder utilizar las tecnologías que mejor se adapten a cada uno y en su contexto particular; estamos para minimizar los costes y aumentar la productividad.
Si a ti te funciona perfecto pero resulta, que aunque tomados uno a uno los puntos analizados anteriormente puedan parecer subjetivos, objetivamente, establecen un marco de trabajo que difícilmente puede considerarse óptimo y la prueba palpable de ello es que montañas de programadores (no tiene sentido aventurar porcentajes) odian JavaScript al menos, para trabajar con él.
Si eres de los que no soporta que la gente se queje de JavaScript piensa que, toda esa gente, está obligada a usar JavaScript y que ellos no se quejan de que tú lo uses, sino de que ellos tengan que usarlo.
(¿Existen alternativas?, ¿quien las suministra?, ¿quien las apoya?, ... son por supuesto cuestiones importantísimas que están fuera del alcance de este post)
