Javascript es, sin duda, el lenguaje de programación interpretado del lado del cliente más importante de la actualidad. Su potencial es muy grande pero, a su vez, guarda en su interior una serie de sorpresas y curiosidades bastante llamativas. Aquí te presentamos 10 de estas curiosidades que (seguramente) no sabías (yo desde luego no tenía ni papa) y si quieres profundizar más, date un garbeo por el artículo fuente de los titanes de Smashing Magazine. Al lío:
- Null es un objeto (desde luego, paradójico)
- NaN es un número (otra paradoja más y el universo implosiona)
- array() ‘==’ False es True
- La función replace() acepta como parámetro funciones callback
- Las expresiones regulares se pueden testear con test() además de con match()
- Puedes falsear el alcance de una variable o función (algo muy útil la verdad)
- Las funciones se pueden ejecutar a si mismas... y al parecer sin caer en un bucle infinito ni nada
- Firefox no lee y devuelve los colores en hexadecimal sino en RGB
- 0.1 + 0.2 ‘!==’ 0.3 (¿otra paradoja? Boooooommm!!!)
- Undefined puede ser definido, es decir, que no es una palabra reservada (fail!)
Sin duda muy curioso, ¿conoces más secretos, sorpresas y curiosidades de Javascript?
Vía | Smashing Magazine
Comentarios
interesante
Sí, es un método esotérico que a menudo es denominado recursión. Casi nadie lo usa hoy en día... (¬¬)
Javascript tiene bastantes detalles curiosos (supongo que heredados de una primera definición no muy madura). Por ejemplo '' == '0' es false, mientras que 0 == '0' es true y se cumple que 0 == ''. Es fácil imaginar el porqué pero la igualdad debería ser una relación transitiva.
Aquí tenéis unas cuantas más.
Cómo que la recursión casi nadie la usa hoy en día?... #fail
Creo que tendria que haberse puesto un cartel que dijera sarcasmo (:
Creo que no notaste su sarcasmo...
Nada de recursión, mira el ejemplo en el artículo fuente y lo verás más claro.
Gracias por el enlace, muy interesante.
Saludetes.
Para entender la recursividad, hay que entender la recursividad.
¿Lo de undefined es como cuando en C/C++ pones?:
#define true false
#define false true
-- editado por última vez a las 22:17
Nono. No tiene nada que ver.
Undefined en javascript es el "valor" que no es tal. Es decir, que es un valor indefinido: que no está definido. No es null, es indefinido :).
Un saludo.
En javascript no necesitas declarar el tipo de varible.
var mivarible;
mivariable = 1;
//Asi defines mivariable como entero
// pero si sino hubiera asignacion mivariable es Undefined.
-- editado por última vez a las 03:47
No entiendo la 3 ni la 9 :(
si no me equivoco la 9 dice que 0.1 + 0.2 != 0.3 (!= es 'diferente').. esto debe ser por la aproximacion.. en vba (excel) recuerdo a a veces valores como 0.2 en realidad eran reconocidos por el computador como 0.200000000000012314 algo asi.
supongo que a eso se refiere (:
Lo siento, fallo mío de edición, ahora creo que se entiende mejor
Saludos
es un error intrínseco de los valores de coma flotante (float y double) mal gestionado por javascript. no se puede almacenar cualquier valor en estos tipos de datos. en Java por ejemplo existe BigDecimal para un uso más preciso de los valores enteros.
mucha info en Google: http://www.google.es/search?sourceid=chrome&ie=UTF-8&q=limitaciones+coma+flotante
La 7 de toda la vida se ha llamado Recursividad. Y es un método que se enseña en primero de carrera (aunque es una porquería y muy poco eficiente).
No es recursividad, ya que eso va a depender del uso que le des y no se donde has sacado eso de que la recursividad es una porquería y muy poco eficiente.
Los ingenieros tenéis la fea costumbre de creeros programadores...
Estos de las carreras les dicen 4 cosas y se creen programadores
¿Recursividad una porquería? Es la mejor forma de recorrer grafos, tanto en DFS como en BFS. Es más, para cualquier algoritmo que quieras aplicar sobre un grafo, si quieres usar loops tendrás que utilizar queues o stacks para ayudarte en la recorrida, de lo contrario no salen.
Porqueria poco eficiente? O.o si no fuera por la recursividad que seria de nosotros (ejemplo claro de uso de recursividad... quicksort) Y PD: Soy (dentro de unos anos mas) ingeniero :P
Ja porquería y poco eficiente? pues en que primaria estudias XD
la recursividad no es una porqueria, es una forma diferente de definir las cosas y con menos lineas de codigo. La cuestion es hacer algo que un ser humano entienda porque, como dijo aquella vez el profesor, "la computadora entiende todo".
Ahora, sobre eficiencia, estoy de acuerdo a medias y es por algo simple: la recursividad CONSUME MUCHOS RECURSOS. Esto se debe a que, recursivamente, el programa (compilador o lo que quieras) almacena en memoria los datos de entrada/salida que requiere y los recorre uno por uno del inicio hasta el final, lo cual utiliza mucha mucha ram (:
De todos modos, ningun paradigma en informatica es "porqueria".
En realidad la 7 son closure y lambda funciones(o funciones anónimas,temas de programación funcional).
Sobre la recursion si es mas lenta y tiene ciertos problemas,pero de verdad vas a estar estar horas haciendo una solución mas compleja cuando probablemente esta función no represente ni el 0.0001% de los recursos que use tu programa.
Todo algoritmo iterativo puede ser recursivo y viceversa.
-- editado por última vez a las 07:03
Es cierto lo que dices...
muchos confunden la recursividad con que una funcion se llame a si misma... si crees eso no entiendes la recursividad.
Y la recursividad no es tan eficiente como otros metodos, pero es muy util para diversos tipos de estructura y para abstraer mucho mejor tus funciones.
Es muy útil si sabe usarse. Con poco código y con una forma elegante se hacen verdaderas virguerias a base de condicionales en tareas repetitivas que otros solventan con bucles.
Un saludo.
interesante
¿qué tendrán que ver los ingenieros con el comentario del chaval? muchos se han equivocado con el tema de la recursividad, pero eso no tiene nada que ver con las capacidades de programación de los ingenieros.
Una de las bases de la IA són los métodos recursivos
-- editado por última vez a las 16:11
Ya hemos pillado los ingenieros y los universitarios. Un ingeniero bién puede ser programador, estudia en parte para ello. Si a ti te parecen 4 cosas o crees que hay un método de formación mejor, pues de acuerdo, pero esta generalización es injusta para muy buenos profesionales.
Es mas, la mayoría de ingenieros programan mejor que la mayoría de programadores de FP...
Se ve que no estudiaste mucho en primero de carrera. La recursividad simplifica muchísimo a la hora de tratar, precisamente, problemas intrínsecamente recursivos. ¿Que la recursividad es ineficiente? Es tan eficiente como el mismo algoritmo en su versión iterativa excepto en una cosa, el paso de valores en la pila de llamadas. Otra cosa a parte es que no sepas utilizarla correctamente.
La 7 no es recursivo, recomiendo mejor ver el articulo original contiene ejemplos en código fuente.
La 4 y la 5 me sean muy útiles.
Te das cuenta de estas cosas cuando te pegas un buen rato con errores que todavía aún no sabes como solucionaste, simplemente por mover una función de sitio o por cambiarle el nombre a alguna variable; tonterías del estilo, que te hacen perder el tiempo.
Lo de que null es un objeto fue una de mis primeras sorpresas, lo típico de ir poniendo alerts para saber por donde peta el script.
Luego te viene el jefe diciéndote, ¡Venga que sólo te he pedido un simple calendario!
De acuerdo Ingeniero o Programador nato, el que te pidan algo por citar el calendario y te digan pero es muy fácil por dentro es de (Si es fácil porque me pides que yo lo haga jajajaja)
Vaya sorpresas de JavaScript, haber si van descubriendo algunas otras sorpresas mas de Java script (muchas veces, por culpa de estas cositas uno se queda frente a la pantalla por horas y horas D:)
La 9 no es una cosa curiosa de Javascript, se da en muchos lenguajes debido al modo en el que se almacenan los números reales.
La primera conclusión no es correcta: null no es un objeto en Javascript.
En Javascript tenemos solo dos tipos de entidades: primitivas y objetos; null es una de esas cinco primitivas, de hecho, junto con undefined, las única que no posee un constructor que permita la conversión.
La evaluación typeof( null ) no puede utilizarse para demostrar lo contrario ya que realmente no se está evaluando el tipo del argumento: una coerción interna, convierte el valor null a booleano y de ahí extrae el tipo que resulta en un objeto.
Si recurrimos a comprobaciones más estrictas, vemos como null, efectivamente, no se corresponde con un objeto:
var a = null; null.__proto__; // null has properties
var a = null; a instanceof Object; // false
var a = null; a.constructor == Object; // a is null
La evaluación del typeof se trata más de una curiosidad del intérprete que de una característica real del lenguaje.
Saludos.
-- editado por última vez a las 15:33
La 8 no tiene nada que ver con Javascript.
Creo lo contrario, ya que tiene Firefox "su propio interprete por así decirlo de JavaScript" por ser del lado del cliente, y es fácil al cargar un archivo XML se debe cargar de otra forma en IE solo por que no interpreta de la misma forma a JavaScript
Por eso. Lo digo porqué no es una generalidad es parte del interprete de firefox, no de la especificación del lenguaje. Curiosidades/rarezas/anomalías de cada interprete hay un montón.
http://www.smashingmagazine.com/2011/05/30/10-oddities-and-secrets-about-javascript/
No creo no puso los ejemplos, aparte tradujo jajajaja, saludos
Me rindo ante la evidencia, Sherlock... lastima que ya indique en el post de donde he sacado la lista y ponga el mismo enlace que pones tu ¡2 veces!...
Los puntos 8 y 9 no son exclusivos de javascript, funcionan de acuerdo a la especificación IEEE 754 para representar números en coma flotante. Este método de representación tiene la ventaja de ofrecer exactitud con un amplio rango de órdenes de magnitud, precisamente es el método idóneo para realizar cálculos científicos. En uno de los ejemplos de la fuente aparece la igualdad
NaN == NaN; // falseNaN significa Not a Number y es el resultado de operaciones no definidas tales como la división por cero. Precisamente por eso la operación de igualdad de dos NaN debe devolver falso.Lo que vendría a demostrar que JavaScript apesta y apesta mal.
Pienso que JavaScript es muy flexible y permite hacer cosas de manera más sencilla que en otros lenguajes. Sin embargo la sintaxis se puede mejorar, sobre todo en lo relativo a la orientación a objetos.
La idea de que casi todo sean objetos y la capacidad de metalenguaje me parecen muy útiles.
El peor inconveniente es que cada navegador hace su implementación particular del estándar y en ciertas ocasiones puede provocar la explosión de varias cabezas de programador.
Bueno, comprenderás que discrepo, al menos en eso de la sencillez. Porque en eso de la flexibilidad podría estar de acuerdo: JS es tan flexible que le permite al programador hacer cualquier desastre :).
JS es un lenguaje que está atado al DOM (hay otro lenguaje así?) pero aún tenemos que "navegar" en la estructura del DOM y usar un método para devolver un puntero a un elemento que de todas formas ya tiene un identificador único. Absurdo.
Si tienes:
<div id="somediv">...¿Porque hay que hacer eso?:var midiv = document.getElementById("somediv");Cuando lo "intuitivo" es simplemente usar el identificador del div como un objeto y ya.¿Qué es eso de que está atado al DOM? Una cosa es el lenguaje y otra la librería de funciones y objetos que te permiten acceder al DOM.
Según tu definición de 'atar' también estaría atado a las matemáticas por la librería Math.
La 3 también se cumple en PHP.
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect