La mayoría de las personas scripters suelen confundir rapidez con optimización. Así, cuando intentan hacer valer sus argumentos, explican, mediante código, que su realización es más rápida.

Como se sabe ya desde hace mucho tiempo, la rapidez muchas veces está reñida con la estabilidad en cuanto a la programación se refiere. Yo puedo elegir realizar un bucle mucho más rápido que la realización de la llamada a un alias. Sin embargo, cuando estamos operando con características reales, no suele ser la mejor opción.

Por ejemplo, imaginémonos que debemos realizar un bucle que tome como parámetro de entrada los usuarios de un canal y nos de como salida una sencilla cadena con todos ellos.

Mediante un buble while se podría obtener inmediatamente el resultado, pero ¿qué pasaría si el parámetro de entrada se retrasara unos segundos? Pues nos devolvería una cadena partida, errónea o, incluso, no devolvería nada.

Para solucionar éste problema se suele utilizar un retraso virtual, que puede ser un contador o un timer. De ésta forma, aun evitando la posible nula salida, tendremos como resultado que, lo que al principio pensabamos realizar eficientemente y rápido, nos encontramos ahora con un código dependiente, enlentecido e inestable. Si añadimos un timer para esperar a tener todos los valores de entrada, un timer que debería ser preconfigurado por nosotros a un tiempo no escalable y prefijado, la rapidez, que era lo que se perseguía, quedaría gravemente mermada.

Así, lo que en un princpio se podría rechazar por lentitud, como sería la llamada a un alias que se activara en un raw dependiente de la notificación, por parte del servidor, de la finalización de envio de los datos que requiramos, resulta ser ahora la manera más precisa y óptima de codificar.

Éste es un claro y sencillo ejemplo para plasmar que un código rápido no es siempre la mejor opción, y que la rapidez no lleva consigo, obligatoriamente, la optimización.