En este caso, los libros de los que voy a hablar son:

• How to tell if your cat is plotting to kill you, por Matthew Inman
• Algorithms in a Nutshell, por George Heineman, Gary Pollice y Stanley Selkow
• The Grand Design, por Stephen Hawking
• HTML5 Games, por Jacob Seidelin

How to tell if your cat is plotting to kill you

por Matthew Inman

Este es el libro de Matthew Inman, mejor conocido como The Oatmeal, un escritor de web comics que tiene un humor algo explícito y muy sarcástico. Amante de los animales y la ciencia, fue mucho mejor conocido por las respuestas ultra-sarcásticas que da a quienes lo amenazan legalmente (ver caso FunnyJunk, la respuesta de FunnyJunk y la demanda de FunnyJunk por defamación). Si algo quiero compartir de los comics de Oatmeal es su increíble tributo a la vida de Tesla: Why Nikola Tesla was the greatest geek that ever lived, y la seguidilla de posts en donde él usó su fama para salvar la torre Wardenclyffe y convertirla en un museo.

Volviendo al libro, es una recopilación de muchos de los comics que están online y una compilación de varios otros que no lo están. El estilo de humor es el mismo, por lo que si te gusta lo que ves online, probablemente te guste el libro. No es extremadamente extenso, y la naturaleza de los comics hace que sea de lectura rápida. Literalmente, lo leí en 10 minutos.

Quiero alardear un poquito sobre el hecho de que Matthew Inman (“el chico de los gatos”, según se refirieron a él en la librería) visitó nuestra ciudad el año pasado y aprovechamos a saludar y pedirle un autógrafo. A diferencia de lo que sus comics nos hacen pensar, él es una persona de buena presentación, en buena forma física, joven y muy amable.

Resumiendo: buen humor, aunque no destacable, simple. Libro corto.

Algorithms in a Nutshell

por George Heineman, Gary Pollice y Stanley Selkow

Este libro tiene una muy buena premisa y propósito: hacer entender el concepto detrás de los algoritmos más comunes que se utilizan en el mundo de la informática. Básicamente: ordenamiento, asociación, recorrida de grafos, recorrida de árboles, búsqueda. Desafortunadamente, el libro sufre de varios problemas que lo hace muy difícil de seguir, como por ejemplo:

• Hay elementos de los cuales se dan sus definiciones matemáticas, asumiendo que el lector ya tiene conocimiento sobre esas bases (recordemos que el libro es para entender los algoritmos — ¿quizá la premisa no tiene en cuenta la audiencia que querría hacer esto?)
• Los gráficos utilizados como ejemplos son demasiado pequeños para ser parte de un libro. Literalmente cuesta mucho trabajo verlos.
• Hay muchas explicaciones que se basan en ejemplos puntuales y no en generalidades. Entiendo el uso de un ejemplo para, precisamente, ejemplificar, pero no para deducir relaciones matemáticas entre objetos y llamarlo una ley.
• Extensas tablas de datos, a veces con pocas conclusiones al respecto. Es útil para comparar resultados si uno mismo se propone repetir toda la investigación que los autores hicieron, pero no para, nuevamente, entender los algoritmos.
• Se efectúan análisis de espacio (memoria) que son específicos a entornos o lenguajes, pero no en cuanto a aspectos generales de la información utilizada.
• Existen casos en donde las explicaciones no logran identificar los elementos que son bases para lograr la intuición del algoritmo. Como un buen ejemplo, la explicación de la búsqueda en grafos habla de colores para identificar el estado de análisis y basa sus conclusiones en base al tamaño o extensión de la frontera de búsqueda — cuando nunca se definió qué era esa frontera.
• El código de ejemplo no está escrito para ser legible, en muchos casos incluso está optimizado. La elección de los lenguajes tampoco es la más feliz (C, con un bajo nivel innecesario, Java con una sobre-ingeniería sobre la jerarquía de objetos). En los ejemplos hay poco de algoritmo y mucho de detalles de implementación.

En definitiva, tuve una mala experiencia pero no fue totalmente negativa. Logré entender varios de los puntos que querían hacerse y logré sacar algunas cosas del libro. Además, podría ser útil como material de referencia (si es que uno trabaja en C o en Java, porque hay muy poco pseudocódigo).

The Grand Design

por Stephen Hawking

Personalmente, pensé que este libro se centraría en la controversia de Hawking afirmando que no se requiere un Dios para tener al universo de la forma en la que hoy existe, y más aún con toda la polémica de las teorías del Diseño Inteligente. (Esa es una discusión que no abordaré aquí.)

Sin embargo, aunque menciona estos puntos, el libro está centrado en explicar el progreso de la ciencia desde los más antiguos mitos (¡recomiendo muchísimo el segundo capítulo, es la corta historia de toda la ciencia!), explicar el método científico y dar a entender también cuáles son las últimas teorías más válidas y por qué. Cubre, sin ir demasiado en detalle, la teoría de cuerdas, las previas teorías del Big Bang y la relatividad. Cuenta algunos hechos fascinantes sobre la mecánica cuántica y por qué realmente es más complicada de lo que podemos imaginar.

Un punto muy importante que también explica es el principio antrópico y cómo ha hecho la ciencia para responder esas respuestas. Estén satisfechos o no con esa respuesta, está claro que expone una respuesta a esos problemas y lo explica de una forma muy amena, no hace falta ser un físico teórico para comprender de qué se habla. Como siempre, me quito el sombrero ante Hawking por su capacidad de explicar temas tan complejos de una forma tan simple.

HTML5 Games

por Jacob Seidelin

Este es uno de esos libros que, como Algorithms in a Nutshell, tiene muy buena intención pero la forma de llevar a cabo sus explicaciones no son tan buenas. Sin embargo, a diferencia de ese ejemplo, este sí tiene un contenido con bases mucho más fáciles de comprender, incluso para aquél que no esté totalmente familiarizado con la programación JavaScript.

El libro nos lleva sobre las posibles opciones al momento de desarrollar juegos HTML5 siguiendo la línea de un ejemplo práctico, de principio a fin. En este caso, nos cuenta cómo implementar un juego del tipo match-three, haciendo un clon simple de Bejeweled.

A lo largo del libro, introduce varias herramientas y técnicas pero nunca se detalla en totalidad ninguna de ellas, en pos de seguir adelante con el ejemplo planteado. Personalmente creo que esto distrae del objetivo de educar sobre las posibles opciones y cuándo elegir una u otra, pero no deja de ser un libro instructivo por eso. De la misma forma, se van introduciendo distintas tecnologías hasta el punto necesario para el ejemplo.

Así, el libro es una buena introducción como para tener una idea básica de qué cosas se pueden hacer y de qué forma se harían, pero no es un compendio de posibilidades, ni es extremadamente detallado en las capacidades que las tecnologías mencionadas nos ofrecen. Cabe aclarar, que eso es difícil de lograr de todos modos ya que estas se encuentran aún en un proceso de cambio. Son los riesgos de escribir un libro sobre un tema tan actual.

Por último, quería mencionar que el libro hace caso a las buenas prácticas aunque no las hace una parte central del mismo. Pero es bueno saber que no se sacrifica la calidad de código por llevar adelante un ejemplo. Eso es un punto a favor.

Una amiga mía preguntó en DeviantArt: ¿por qué favean? ¿Qué hacen con sus favoritos?

La pregunta me parece un poco más profunda de lo que aparenta ser en una primera leída. Los favoritos y la forma en la que se usan pueden ser un fenómeno de internet en sí mismo y la cultura 2.0. Quisiera hablar un poco de eso.

En caso de que estén viviendo debajo de una roca (en cuyo caso, felicitaciones por haber llegado a este blog), los favoritos son generalmente un mecanismo por el cual podemos expresar nuestro gusto particular por contenido disponible en alguna aplicación. Se puede expresar de distintas formas, pero lo que lo distingue de un like de Facebook es que tenemos la posibilidad de volver a ellos y mostrarlos, o no, públicamente. Podemos generar una colección propia de favoritos que luego podremos usar para varias cosas.

Esta capacidad plantea una serie de preguntas, porque si disponemos la capacidad de clasificarlos, ¿de qué forma los clasificamos? En casos contados, esa clasificación ya viene dada por nosotros, como GitHub que nos permite indicar nuestro soporte por un proyecto o indicar nuestro soporte Y estar actualizados sobre un proyecto. En casos como esos la decisión es obvia. Pero en otros casos en donde nosotros podemos definir esa clasificación, ¿qué criterio se usa?

Otra pregunta que se nos plantea es qué utilidad le damos a estos favoritos, puesto que tenemos la posibilidad de volver a ellos y de compartirlos. Pueden ser para mostrar apoyo a un artista o al creador de la obra en general, o puede ser para usar de referencia futura, puede ser para generar una colección virtual temática, o puede ser para sólo juntar cosas que nos gustan (y en ese caso, ¿cuál es el mínimo de “me gusta” que debe tener algo para elegirlo como favorito?).

Como extra, en general los favoritos se muestran junto con nuestro perfil al conviertirlo en favoritos. De alguna forma, nuestro perfil entonces tendrá contenido que elijamos de alguien más — nuevamente la pregunta es: ¿qué criterio utilizar?

Favoritos públicos

Existen sitios como DeviantArt o Twitter, en donde los favoritos son públicos. De alguna forma, cualquiera que visite el perfil puede ver los favoritos de uno y darse cuenta de qué es lo que nos agrada. En mi caso personal, no sólo hago de mis favoritos cosas que me gustan, sino cosas que me agradan tanto que estoy dispuesto a asociarlas conmigo. Tanto como si estuviera al lado de un extraño y decirle “Este es el tipo de cosas que me gustan”. Son favoritos que estoy dispuesto a compartir, aunque no lo hago activamente. Las redes sociales disponen de una forma de compartirlo (por ejemplo, Twitter y su Retweet), mientras otras no (DeviantArt, para usar los mismos ejemplos).

Yo rara vez vuelvo a revisar esos favoritos, pero probablemente debería. Con el tiempo, el criterio de uno cambia, y muchas cosas de antes ya no son tan valiosas o tan asociables con nosotros.

Favoritos privados

Existen sitios como Tumblr (o Google Reader, ¡por un mes más!), en donde los favoritos son privados. En este caso los uso como referencia personal, de cosas a las que me interesa volver en el futuro. Cosas que quiero revisar, o leer o investigar con posteridad. La integración de servicios fue una herramienta muy importante para que yo pudiera centralizar todo eso (por ejemplo, un starred de Google Reader se va a Instapaper, un favorito de Twitter se va a Instapaper, etc.)

No tengo posibilidad de mostrar estos y de alguna forma tengo una libertad más privada de elegir lo que me gusta y lo que no. Es como no preocuparse en decorar, si nadie va a verlo.

Suelo pensar que la mayoría de nosotros hace algo parecido, pero hay un pequeño detalle: no son exactamente 100% privados. Por ejemplo, Tumblr le informa al publicador original a quién le gustan sus obras, o Feedly indica a cuánta gente le gustó un artículo en particular. ¿Supongo que también puede utilizarse el favorito como una forma particular de mostrar apoyo? Yo no lo hago de esa forma.

Casos híbridos

Hay casos híbridos, como Youtube, en donde los favoritos pueden ser públicos o privados, o mejor aún, los privados pueden compartirse con un grupo selecto. Google+ y Facebook son también ejemplos.

Aquí yo hago ambas cosas que mencioné antes, desde guardar referencias a mostrar cosas que me gustaría que se asociaran conmigo, a utilizarlos para compartir cosas que un grupo particular de gente que conozco disfrutaría.

Por ejemplo, uno de los favoritos implícitos de Youtube es Watch Later, una lista privada en donde guardamos las cosas que nos gustarían ver después. Otra puede ser una lista privada de música que tengo para cuando quiero escuchar, pero que no me interesa que todos vean públicamente, o videos graciosos que me sacan una sonrisa y no necesariamente quiero asociados conmigo.

¿Y ustedes?

Me interesa escuchar alternativas, ¿cómo trabajan ustedes con los favoritos?

Las preguntas son:

• ¿Qué criterio usan para “favoritear” algo?
• ¿Comparten esos favoritos con otra gente? ¿Y de qué  forma?
• Pasado el tiempo, ¿vuelven a sus favoritos? ¿Con qué propósito?

Debería aclarar que no estoy de acuerdo con todos los puntos mencionados como negativos o siquiera problemas, pero respeto el artículo original del autor sin interrupciones.

Sin más, los dejo con el artículo. Si pueden leer el original, lo recomiendo.

Prefacio

Soy quejoso. Me quejo sobre un montón de cosas. Hay mucho en el mundo de la tecnología que no me gusta, y eso realmente es de esperar — programar es una disciplina irrisoriamente joven, y ninguno de nosotros tiene la más mínima idea de lo que estamos haciendo. Combinen eso con la Ley de Sturgeon, y tengo una vida llena de cosas sobre las que protestar.

Esto no es lo mismo. PHP no es meramente raro de usar, o inapropiado para lo que yo quiero, o subóptimo, o contra mi religión. Puedo decir cualquier tipo de cosas buenas sobre lenguajes que evado, y todo tipo de cosas malas sobre lenguajes que disfruto. Adelante, ¡pregunten! Crea conversaciones interesantes.

PHP es la única excepción. Virtualmente cualquier característica de PHP está rota de alguna forma. El lenguaje, el framework, el ecosistema, son todos simplemente malos. Y no puedo siquiera remarcar ninguna cosa particular porque el daño es demasiado sistémico. Cada vez que intento compilar una lista de quejas sobre PHP, me quedo estancado en esta búsqueda en profundidad descubriendo más y más trivia fatal. (Por tanto, un fractal.)

PHP es una vergüenza, una mancha en mi oficio. Está tan roto, pero tan elogiado por cada amateur emocionado a quien todavía le queda aprender algo más, hasta ser exasperante. Tiene míseras pocas cualidades redentoras que prefiero olvidarme que existe completamente.

Pero tengo que quitarme esto de encima. Así que aquí va, un último intento.

Una analogía

Se me acaba de escapar esto explicando mi frustración a Mel y ella insistió en que lo reprodujera aquí:

No puedo siquiera decir qué está mal con PHP porque — okay. Imagina que tienes, eh, una caja de herramientas. Un conjunto de herramientas. Se ve bien, con las cosas comunes ahí.

Sacas un desarmador, y ves que es uno de esos raros de cabecitas triples. Okay, bueno, eso no es demasiado útil para tí, pero imaginas que puede servir a veces.

Sacas un martillo, pero disgustado ves que tiene las cuñas de ambos lados. De todos modos, aún sirve, me refiero a que puedes golpear los clavos con la parte del centro de la cabeza sosteniéndolo de lado.

Sacas una de las pinzas, pero no tienen esas superficies ásperas; es plana y suave. Eso es menos útil, pero aún ayuda a girar las tuercas, así que de todos modos está bien.

Y así sigues. Cada cosa en la caja es de alguna forma rara y estrafalaria, pero quizá no tanto como para hacerla inútil. Y no hay ningún problema claro con el conjunto como un todo; todavía tiene todas las herramientas.

Ahora imagina que conoces a millones de carpinteros usando esta herramienta que te dicen “hey bueno, ¿cuál es el problema con estas herramientas? ¡Es todo lo que he usado y han funcionado bien!” Y los carpinteros te muestran las csasas que han hecho, en donde cada habitación es un pentágono y el techo está de cabeza. Y golpeas en la puerta principal y todo colapsa hacia adentro y todos te gritan por romper su puerta.

Eso es lo que está mal con PHP.

Postura

Yo aseguro que las siguientes cualidades son importantes para hacer a un lenguaje productivo y útil, y PHP las viola desenfrenadamente. Si no estás de acuerdo en que estas son cruciales, bueno, no puedo imaginar que estaremos de acuerdo en nada.

• Un lenguaje debe ser predecible. Es un medio para expresar ideas humanas y tener a una computadora ejecutándolas, por lo que es crítico que la comprensión humana de un programa sea de hecho correcta.
• Un lenguaje debe ser consistente. Cosas similares se ven similares, cosas diferentes se ven diferentes. Conocer parte del lenguaje debería ayudar en aprender y comprender el resto.
• Un lenguaje debe ser conciso. Los nuevos lenguajes existen para reducir el modelo estándar de otros lenguajes viejos. (Todos podríamos escribir en código máquina.) Un lenguaje debe entonces buscar introducir nuevos modelos estándares propios.
• Un lenguaje debe ser confiable. Los lenguajes son herramientas para resolver problemas; deberían minimizar cualquier nuevo problema que introducen. Cualquier “gotchas” son distracciones masivas.
• Un lenguaje debe ser debuggeable. Cuando algo sale mal, el programador debe arreglarlo, y necesitamos toda la ayuda que podamos obtener.

Mi posición es por tanto:

• PHP está lleno de sorpresas: mysql_real_escape_string, E_ALL
• PHP es inconsistente: strpos, str_rot13
• PHP requiere de un modelo estándar: checkeo alrededor de llamadas a APIs de C, ===
• PHP es descascarado: ===, foreach ($foo as &$bar)
• PHP es opaco: no hay stack traces por default o for fatales, el reporte de errores es complejo

No puedo proveer un párrafo de comentario para cada problema explicando por qué falla en estas categorías, o esto sería interminable. Espero que el lector, digamos, piense.

No comentes con estas cosas

He estado mucho en discusiones sobre PHP. Escucho muchos argumentos muy genéricos que están solo diseñados para detener la conversación inmediatamente. No me vengas con estos por favor. :(

• No me digan que “los buenos programadores pueden escribir buen código en cualquier lenguaje”, o que los malos programadores bla, bla, bla. Eso no significa nada. Un buen carpintero puede martillar un clavo con una roca o un martillo, pero ¿cuántos carpinteros ves martillando con rocas? Parte de lo que hace a un buen desarrollador es la habilidad para elegir las herramientas con las que trabaja mejor.
• No me digas que es responsabilidad de los programadores memorizar mil excepciones y comportamientos extraños. Sí, esto es necesario en cualquier sistema, porque las computadoras apestan. Eso no significa que no hay un límite superior por cuánto payaseo es permitido en un sistema. PHP no es nada sino excepciones, y no está bien cuando pelear con el lenguaje de hecho toma más esfuerzo que escribir tu programa. Mis herramientas no deberían crear más trabajo neto para que yo haga.
• No me digas que “así es cómo funciona la API de C”. ¿Cuál es el punto de usar un lenguaje de alto nivel si todo lo que provee son utilidades de cadenas y un montón de wrappers de C textuales? ¡Sólo escriban C en ese caso! Aquí, incluso hay una librería CGI para él.
• No me digas que “eso es lo que te pasa por hacer cosas raras”. Si dos características existen, algún día, alguien va a encontrar una razón para usarlas juntas. Y nuevamente, esto no es C; no hay especificaciones, no hay necesidad para “comportamiento indeterminado”.
• No me digas que Facebook y Wikipedia están construidos en PHP. ¡Ya lo sé! Podrían estar también escritos en Brainfuck, pero mientras haya gente inteligente todavía peleando con las cosas, ellos pueden sobreponerse a los problemas con la plataforma. Por todo lo que sabemos, el tiempo de desarrollo podría haber sido duplicado o reducido a la mitad si huberan sido escritos en otro lenguaje; estos datos de por sí no significan nada.
• Idealmente, ¡no me digas nada! Este es mi gran intento; si esta lista no hiere tu opinión de PHP, nada nunca lo hará, así que deja de discutir con un tipo en internet y ve a hacer un sitio cool en tiempo récord para demostrar que estoy equivocado. :)

Observación al margen: me encaaaaaaaaanta Python. También podría felizmente hablarte lo que quieras quejándome sobre él, si realmente quisieras que lo haga. No aseguro que sea perfecto; simplemente he balanceado sus beneficios contra sus problemas y he concluído que es lo mejor que se ajusta a las cosas que quiero hacer.

Y nunca he conocido a un programador de PHP que puede hacer lo mismo con PHP. Pero me he encontrado con muchos que son rápidos para disculparse por cualquier cosa y todo lo que PHP hace. Esa mentalidad es terrible.

PHP

Lenguaje central

CPAN ha sido llamada la “librería estándar de Perl”. Eso no dice mucho sobre la librería estándar de Perl, pero deja ver el punto de que un núcleo sólido puede construir cosas grandes.

Filosofía

• PHP fue originalmente diseñado explícitamente para no-programadores (y, leyendo entre líneas, no-programas); y no ha escapado sus raíces bien. Una cita escogida desde la documentación de PHP 2.0, respecto de + y amigos haciendo conversión de tipos:

Una vez que comienzas a tener operadores separados para cada tipo, comienzas a hacer el lenguaje mucho más complejo. i.e., no puedes usar ‘==’ para stings [sic], ahora usarías ‘eq’. No veo el punto, especialmente para algo como PHP en donde la mayoría de los scripts serán generalmente simples y en muchos casos escrito por no-programadores que quieren un lenguaje con una sintaxis lógica básica y no tiene una curva de aprendizaje muy elevada.

• PHP está construido para mantenerse resoplando a todo costo. Cuando se encuentra con la opción de hacer algo sin sentido o abortar con un error, hará algo sin sentido. Cualquier cosa es mejor que nada.
• No hay una filosofía de diseño clara. El antiguo PHP fue inspirado en Perl; la gran librería estándar stdlib con parámetros “out” es de C; las partes orientadas a objetos fueron diseñadas como C++ y Java.
• PHP toma grandes cantidades de inspiración de otros lenguajes, pero aún así logra ser incomprensible para aquellos que conocen esos lenguajes. (int) se ve como C, pero int no existe. Los namespaces usan \. La nueva sintaxis de los arrays resulta en [key => value], único entre cualquier lenguaje con hashes literales.
• El tipado débil (i.e., conversión silenciosa automática entre strings/números/et al) es tan complejo que cualquier esfuerzo menor de programación ahorrado no lo vale.
• Funcionalidad nueva pequeña es implementada como sintaxis nueva; mucho de lo que está hecho con funciones o cosas que parecen como funciones. Excepto por el soporte de clases, que mereció un montón de nuevos operadores y keywords.
• Algunos de los problemas listados en esta página tienen soluciones de primera mano — si estás dispuesto a pagarle a Zend por arreglos para su lenguaje de programación open-source.
• Hay mucha acción a distancia. Considera este código, tomado de los documentos de PHP en algún lado.
  @fopen(‘http://example.com/archivo-no-existente’, ‘r’);
  
  ¿Qué hará?
  • Si PHP fue compilador con –disable-url-fopen-wrapper, no funcionará. (La documentación no dice que significa “no funcionará”; ¿devuelve null, tira una excepción?)
  • Si allow_url_fopen está deshabilitado en php.ini, aún no funcionará. (¿Cómo? Ni idea.)
  • Dado el @, el warning sobre el archivo no existente no será mostrado.
  • Pero será mostrado si scream.enabled está seteado en php.ini.
  • Pero no si el error_reporting correcto no está seteado.
  • Si es mostrado, a donde va exactamente depende de display_errors, nuevamente en php.ini. O ini_set.
• (continuación del punto anterior)
  No puedo saber cómo esta inocua llamada  a función se comportará sin consultar seteos de compilación, configuraciones a nivel servidor y configuraciones hechas en mi programa. Y todo esto es comportamiento intrínseco.
• El lenguaje está lleno de estado global implícito. mbstring usa un set de caracteres global. func_get_arg y compañía se ven como funciones regulares, pero operan en la función que se ejecuta actualmente. Manejo de errores y excepciones tienen defaults globales. register_tick_function setea a una función global para ser ejecutada en cada tick — ¡¿qué?!
• No hay soporte de threading en absoluto. (No es sorprendente, dado lo anterior.) Combinado con la falta de un fork incorporado (mencionado abajo), esto hace que la programación paralela sea extremedamente difícil.
• Partes de PHP están prácticamente diseñadas para producir código con bugs.
  • json_decode devuelve null para entradas inválidas, aunque null es también un objeto perfectamente válido para ser decodificado como JSON — esta función es completamente poco fiable a menos que también llames a json_last_error cada vez que la uses.
  • array_search, strpos y funciones similares devuelven 0 si encuentra la aguja en la posición cero, pero falso si no la encuentran en absoluto.
• (continuación del punto anterior)
  Permíteme expandirme en esa última parte un poco.
  En C, las funciones como strpos devuelven -1 si el item no es encontrado. Si no checkeas por ese caso e intentas usarlo como índice, llegarás a memoria basura y tu programa explotará. (Probablemente. Es C. ¿Quién demonios sabe? Estoy seguro de que hay herramientas para esto, como menos.)
  En, digamos, Python, el método equivalente, .index arrojarán una excepción  si el ítem no es encontrado. Si no checkeas por ese caso, tu programa explotará.
  En PHP, estas funciones devuelven falso. Si usas FALSE como índice, o haces casi cualquier cosa con él excepto comparar con ===, PHP silenciosamente lo convertirá a 0 para tí. Tu programa no explotará; en cambio, hará lo equivocado sin aviso, a menos que recuerdes incluir el código estándar alrededor de cada lugar en donde uses strpos y ciertas otras funciones.
  ¡Esto está mal! Los lenguajes de programación son herramientas; se supone que deben trabajar conmigo. Aquí, PHP ha activamente creado una sutil trampa para que yo caiga en ella, y yo debo estar atento incluso con cosas mundanas como operaciones de cadena y comparaciones de igualdad. PHP es un campo minado.

He escuchado una buena cantidad de historias sobre PHP y sus desarrolladores de muchos lugares. Estas son de la gente que ha trabajado en el núcleo de PHP, ha debuggeado el núcleo de PHP, interactuado con los desarrolladores del núcleo. Ni una sola historia ha sido un elogio.

Entonces debo poner esto aquí, porque vale la pena repetirlo: PHP es una comunidad de amateurs. Muy poca gente diseñándolo, trabajando en él o escribiendo código en él parece saber lo que están haciendo. (Oh, querido lector, ¡tú eres por supuesto una rara excepción!) Ellos que sí logran tener una pista tienden a alejarse a otras plataformas, reduciendo la competencia promedio del todo. Este, aquí mismo, es el mayor problema con PHP: es absolutamente el ciego guiando a los ciegos.

Okay, de vuelta a los hechos.

Operadores

• == es inútil
  • No es transitivo.  “foo” == TRUE, y “foo” == 0… pero, por supuesto, TRUE != 0.
  • == convierte a números cuando es posible (123 == “123foo”… aunque “123″ != “123foo”), lo que significa que convierte a punto flotante cuando es posible. Entonces, cadenas largas hexadecimales (como por ejemplo, digamos, hashes de passwords) pueden ocasionalmente compararse a true cuando no lo son. Ni JavaScript hace esto.
  • Por la misma razón, “6″ == ” 6 “, “4.2″ == “4.20″, y “133″ == “0133″. Pero nota que 133 != 0133 porque 0133 es octal. ¡Pero “0×10″ == “16″ y “1e3″ == “1000″!
  • === compara valores y tipo… excepto con objectos, ¡en donde === es solamente verdadero si ambos operandos son el mismo objeto! Para objetos == compara ambos valores (de cada atributo) y tipo, que es lo que === hace para cualquier otro tipo. ¿Qué?
• La comparación no es mucho mejor.
  • Ni siquiera es consistente: NULL < -1, y NULL == 0. El ordenamiento es por tanto no determinístico; depende del orden en el que los algoritmos de ordenación comparan los elementos.
  • Los operadores de comparación tratan de ordenar arrays de dos maneras distintas: primero por tamaño, luego por elementos. Sin embargo, si tienen el mismo número de elementos, pero diferente conjunto de claves, son incomparables.
  • Los objetos se comparan como mayores a cualquier otra cosa… excepto otros objetos, en donde nunca son menores o mayores.
  • Para un == con tipado más seguro, tenemos ===. Para un < con tipado más seguro tenemos… nada. “123″ < “0124″, no importa lo que hagas. El casting tampoco ayuda.
• A pesar de la locura de más arriba, y el rechazo explícito de los pares de operadores numéricos y de cadena de Perl, PHP no sobrecarga +. + es siempre adición y . es siempre concatenación.
• El operador de indexado [] también puede ser escrito {}.
• [] puede ser usado en cualquier variable, no sólo cadenas y arrays. Devuelve null y no arroja ningún warning.
• [] no puede partir/rebanar, sólo devuelve elementos individuales.
• foo()[0] es un error de sintaxis. (Arreglado en PHP 5.4.)
• A diferencia de (¡literalmente!) cualquier otro lenguaje con un operador similar, ?: es asociativo a izquierda. Entonces esto:
  $arg = ‘T’;
  $vehicle = ( ( $arg == ‘B’ ) ? ‘bus’ :
  ( $arg == ‘A’ ) ? ‘airplane’ :
  ( $arg == ‘T’ ) ? ‘train’ :
  ( $arg == ‘C’ ) ? ‘car’ :
  ( $arg == ‘H’ ) ? ‘horse’ :
  ‘feet’);
  echo $vehicle
  imprime horse.

Variables

• No hay forma de declarar una variable. Las variables que no existen son creadas con un valor nulo cuando son usadas por primera vez.
• Las variables globales necesitan una declaración global antes de ser usadas. Esta es una consecuencia natural de lo anterior, por lo que sería perfectamente razonable, pero las variables globales no se pueden siqueira leer sin una declaración explícita — PHP en su lugar silenciosamente creará una variable local con el mismo nombre. No estoy consciente de otro lenguaje con problemas de ámbitos similares.
• No hay referencias. Lo que PHP llama referencias son en realidad alias; no hay nada que sea un paso atrás, como las referencias de Perl, y no hay identidad de pasaje-por-objeto como en Python.
• El referenciamiento infecta una variable como ninguna otra cosa en el lenguaje. PHP es de tipado dinámico, por lo que las variables generalmente no tienen tipo… excepto las referencias, que adornan definiciones de funciones, sintaxis de las variables, y asignaciones. Una vez que una variable ha sido convertida en referencia (que puede pasar en cualquier lugar), está atorada como referencia. No hay una forma obvia de detectar esto y de-referenciarla requiere destruir la variable completamente.
• Okay, mentí. Hay “Tipos SPL” que también infectan a las variables: $x = new SplBool(true); $x = “foo”; fallará. Es como un tipado estático.
• Una referencia puede ser hecha a una key que no existe en una variable no definida (que se convierte en un array). Usar un array no existente por lo general genera un aviso, pero este no.
• Las constantes son definidas por una llamada a una función que toman una cadena; antes de eso, no existían. (Esto podría de hecho ser una copia del comportamiento de use constant de Perl.)
• Los nombres de las variables son sensibles a mayúsculas y minúsculas. Las funciones y nombres de clases no lo son. Esto incluye nombres de métodos, que hace que camelCase sea una elección extraña para la nomenclatura.

Conceptos

• array() y otra docena de conceptos no son funciones. array por cuenta propia no significa nada. $func = “array”; $func(); no funciona.
• El desempaquetado de arrays puede hacerse con la operación list($a, $b) = …. list() es sintaxis función-simil como array. No sé por qué a esto no se le dio una sintaxis propiamente dedicada, o por qué el nombre es tan obviamente confuso.
• (int) está obviamente diseñado para verse como C, pero es un token único; no hay nada llamado int en el lenguaje. Inténtalo: no sólo var_dump(int) no funciona, arroja un error de parseo porque el argumento se parece como el operador de casting.
• (integer) es un sinónimo para (int). También están (bool) / (boolean) y (float) / (double) / (real).
• Hay un operador (array) para castear a arrays y (object) para castear a objetos. Suela loco, pero hay al menos un uso: puedes usar (array) para tener un argumento de una función que sea o un item simple o una lista y tratarlo de forma idéntica. Excepto que no puedes hacerlo con seguridad, porque si alguien pasa un único objeto, castearlo a un array producirá un array conteniendo los atributos del objeto. (Castear a object produce la operación inversa.)
• include() y compañía son básicamente el #include de C: tiran el contenido de otro archivo de código fuente en el tuyo. No hay sistema de módulos, ni siquiera para código PHP.
• No hay algo como funciones o clases anidadas o locales. Son sólo globales. Incluir un archivo pone sus variables en el ámbito de la función actual (y le da al archivo acceso a tus variables), pero pone las funciones y clases en el ámbito global.
• Agregar a un array se hace con $foo[] = $bar.
• echo es algo estilo instrucción, no una función.
• empty($var) es tan extremadamente no-función que cualquier cosa excepto una variable, por ejemplo, empty($var || $var2), es un error de parseo. ¿Por qué en la Tierra tiene el parser que saber sobre empty?
• Hay sintaxis redundante para los bloques: if (…): … endif;, etc.

Manejo de errores

• El único operador de PHP es @ (de hecho, tomado prestado de DOS), que silencia errores.
• Los errores de PHP no proveen stack traces. Debes instalar un handler para que los genere. (Pero no puedes hacerlo para errores fatales — ver abajo.)
• Los errores de parseo de PHP generalmente sólo escupen el estado de parseo y nada más, haciendo una comilla olvidada terrible para debuggear.
• El parser de PHP se refiere, por ejemplo, a :: internamente como T_PAAMAYIM_NEKUDOTAYIM, y al operador << como T_SL. Digo “internamente” pero igual que arriba, esto es lo que se le muestra al programador cuando :: o << aparecen en el lugar equivocado.
• Mucho del manejo de errores es en la forma de imprimir una línea a un log en el servidor que nadie lee y seguir adelante.
• E_STRICT está ahí, pero no parece prevenir mucho y no hay documentación sobre lo que en realidad hace.
• E_ALL incluye todas las categorias de errores — excepto E_STRICT. (Arreglado en 5.4.)
• Es raramente inconsistente entre lo que está permitido y lo que no. No sé cómo E_STRICTaplica acá, pero estas cosas están permitidas:
  • Intentar acceder a una propiedad no existente en un objeto, i.e., $foo->x. (Warning.)
  • Usar una variable como un nombre de función, o nombre de variable, o nombre de clase. (Silencioso.)
  • Tratar de usar una constante no definida. (Notice.)
  • Tratar de acceder una propiedad de algo que no es un objeto. (Notice.)
  • Tratar de usar un nombre de variable que no existe. (Notice.)
  • 2 < “foo” (silencioso)
  • foreach (2 as $foo); (warning)
• (continuación del punto anterior)
  Y estas cosas no lo están:
  • Tratar de acceder una constante de una clase no existente, i.e., $foo::x. (Error fatal.)
  • Usar una cadena constante como un nombre de funci’on, o nombre de variable, o nombre de clase. (Error de parseo.)
  • Tratar de llamar a una función indefinida. (Error fatal.)
  • No poner un punto y coma en la última instrucción en un bloque o archivo. (Error de parseo.)
  • Usar list y cualquier otro quasi-elemento incorporado como nombre de método. (Error de parseo.)
  • Subindicar el valor devuelto por una función, i.e., foo()[0]. (Error de parseo; permitido en 5.4, ver arriba.)
• (continuación del punto anterior)
  Hay otros buenos ejemplos de otros errores de parseo extraños en algún otro lado en esta lista.
• El método __toString no puede arrojar excepciones. Si intentar, PHP … er… arrojará una excepción. (De hecho, un error fatal, que podría ser aceptable, excepto…)
• Los errores de PHP y las excepciones de PHP son dos bestias completamente distintas. No parecen interactuar para nada.
  • Los errores de PHP (los internos, y las llamadas a trigger_error) no se pueden atrapar con try / catch.
  • De forma similar, las excepciones no desatan manejadores de errores instalados por set_error_handler.
  • En su lugar, hay un set_exception_handler separado que maneja excepciones no atrapadas, porque envolver al punto de entrada de tu programa en un bloque try es imposible en el modelo mod_php.
  • Los errores fatales (por ejemplo, new ClassDoesntExist()) no pueden ser atrapados por nada. Muchas de las cosas inofensivas arrojan errores fatales, terminando tu programa forzosamente por razones cuestionables. Las funciones de cierre aún se ejecutarán, pero no pueden obtener un stack trace (corren al nivel más alto) y no pueden fácilmente determinar si el programa terminó por error o por haberse completado.
• No hay una construcción finally, haciendo al código que envuelve otro código (poner manejador, correr el código, quitar el manejador; monkeypatch, correr un test, quitar el monkeypatch) tedioso y difícil de escribir. A pensar que la orientación a objectos y las excepciones fueron en su mayor parte copiadas de Java, esto es deliberado, porque finally “no tiene mucho sentido en el contexto de PHP”. ¿Eh?

Funciones

• Las llamadas a funciones aparentemente son algo caras.
• Algunas funciones incorporadas interactúan con las funciones que devuelven referencias en, ehm, una manera extraña.
• Como está mencionado en algún otro lado, muchas cosas que parecen funciones o se ven como que deberían ser funciones, son de hecho construcciones del lenguaje, de forma que nada que trabaje con funciones trabajará con ellas.
• Los argumentos de las funciones pueden tener “implicación de tipos”, que es básicamente tipado estático. Pero no puedes requerir que un argumento sea un int, o string, u object, u otro tipo “del núcleo”, incluso cuando cualquier función incorporada usa este tipo de tipado, probablemente porque int no es nada en PHP. (Ver arriba sobre (int).) Tampoco puedes usar las decoraciones de pseudo-tipos usada tanto en las funciones incorporadas: mixed, number, o callback. (callableestá permitido desde PHP 5.4.)
  • Como resultado, esto:function foo(string $s) {}
    foo(“hello world”);produce el error:PHP Catchable fatal error: argument 1 passed to foo() must be an instance of string, string given, called in…
  • Puedes notar que el “implicado de tipo” dado no tiene que existir; no hay ninguna clase string en este programa. Si intentas usar ReflectionParameter::getClass() para examinar el implicado de tipos de forma dinámica, entonces negará que la clase no existe, haciendo imposible obtener el nombre de la clase.
  • El valor devuelto por una función no puede ser tipado.
• Pasar los argumentos de una función a otra función (dispatching, no raro) es hecho llamando a call_user_func_array(‘other_function’, func_get_args()). Pero func_get_args arroja un error fatal en tiempo de ejecución, quejándose que no puede ser un parámetro de función. ¿Cómo y por que es esto siquiera un tipo de error? (Arreglado en PHP 5.3.)
• Las clausuras requieren explícitamente nombrar cada variable sobre la que se cerrará. ¿Por qué no puede el intérprete detectarlo solo? Como que destroza el propósito de la característica. (Okay, es porque usar una variable en algún punto, en cualquier punto, la crea a menos que se le diga explícitamente lo contrario.)
• Las variables sobre las que se cierra la clausura son “pasadas” por la misma semántica que otros argumentos de función. Eso es, arrays, strings, etc., serán “pasados” a la clausura por valor. A menos que uses &.
• Ya que las variables sobre las que se cierra la clausura son efectivamente argumentos automáticamente pasados y no hay ámbitos anidados, una clausura no se puede referir a métodos privados, incluso si está definido dentro de una clase. (¿Posiblemente arreglado en 5.4? No está claro.)
• No hay argumentos nombrados a las funciones. De hecho, se rechazaron explícitamente por los desarrolladores porque “ayuda a código más desprolijo”.
• Los argumentos de función con valores por defecto pueden aparecer antes que los argumentos de función sin ellos, incluso aunque la documentación aclara que esto es raro e inútil. (Entonces, ¿por qué permitirlo?)
• Los argumentos extras a una función son ignorados (excepto con funciones incorporadas, que arrojan un error). Los argumentos faltantes se asumen nulos.
• Las funciones “variadicas” requieren pelear con func_num_args, func_get_arg y func_get_args. No hay sintaxis para algo así.

Orientación a Objetos (OO)

• Las partes procedurales de PHP están diseñadas como C, pero la parte objeccional (jo jo) están diseñadas como Java. No puedo sobreenfatizar lo discordante que esto es. El sistema de clases está diseñado alrededor del lenguaje Java de bajo-nivel que es naturalmente y deliberadamente más limitado que los contemporarios de PHP, y estoy perplejo.
  • Todavía debo encontrar alguna función global que siquiera tenga una letra mayúscula en su nombre, pero aún así varias clases importantes incorporadas usan nombres de métodos camelCase y tienen métodos de acceso getFoo al estilo Java.
  • Perl, Python y Ruby, todos tienen algún concepto de acceso a “propiedad” vía código; PHP sólo tiene el torpe __get y sus amigos. (La documentación inexplicablemente se refiere a esos métodos especiales como “sobrecarga”.)
  • Las clases tienen algo como la declaración de variables (var y const) para atributos de clase, mientras que la parte procedural del lenguaje no.
  • A pesar de la pesada influencia de C++/Java, donde los objetos son medianamente opacos, PHP generalmente trata a los objetos como hashes bonitos — por ejemplo, el comportamiento por defecto de foreach ($obj as $key => $value) es para iterar sobre cada atributo accesible del objeto.
• Las clases no son objetos. Cualquier tipo de metaprogramación se debe referir a ellas con nombres en cadenas, igual que las funciones.
• Los tipos incorporados no son objetos y (a diferencia de Perl) no se pueden hacer parecer objetos de ninguna forma.
• instanceof es un operador, a pesar que las clases fueron una adición tardía y que mucho del lenguaje está construido en funciones y sintaxis orientada a funciones. ¿Influencia de Java? ¿Las clases no son de primera clase? (No sé si lo son.)
• • Pero sí hay una función is_a. Con un argumento opcional indicando si se permite al objeto ser en realidad una cadena nombrando una clase.
  • get_class es una función; no hay operador typeof. Parecido a is_subclass_of.
  • Esto no trabaja en tipos incorporadas, sin embargo (de nuevo, int no es nada). Para eso necesitas is_int, etc.
  • También, el lado derecho debe ser una variable o una cadena literal; no puede ser una expresión. Eso causa… un error de parseo.
• ¿!clone es un operador!?
• Los atributos de objetos son $obj->foo, pero los atributos de clases son Class::$foo. ($obj::foo intentará convertir $obj a string y usarlo como nombre de clase.) Los atributos de clase no pueden accederse desde los objetos, los espacios de nombres están completamente separados, haciendo que los atributos de clase sean completamente inútiles para polimorfismo. Los métodos de clase, por supuesto, están excemptos de esta regla y pueden ser llamdos como cualquier otro método. (Me han dicho que C++ también hace esto. C++ no es un buen ejemplo de OO correcta.)
• También, un método de instancia puede ser llamado de forma estática. (Class::method()). Si se hace desde otro método, esto es tratado como una llamada regular a un método en el $this actual. Creo.
• new, private, public, protected, static, etc. ¿Intentando ganar desarrolladores de Java? Soy consciente que esto es más una cuestión de gusto, pero no sé por qué esto es necesario en un lenguaje dinámico — en C++, mucho de esto se trata de compilación y resolución de nombres en tiempo de compilación.
• PHP tiene soporte de primera clase para “clases abstractas”, que son clases que no pueden ser instanciadas. El código en lenguajes similares logra esto arrojando una excepción en el constructor.
• Las clases derivadas no pueden sobreescribir métodos privados. Las sobreescrituras (overrides) de métodos públicos no pueden siquiera ver, menos llamar, a los métodos privados de la clase padre. Problemático para, digamos, mocks de testing.
• Los métodos no se pueden nombrar, por ejemplo, “list”, porque list() es sintaxis especial (no una función), y el parser se confunde. No hay razón por la que esto debería ser ambiguo, y hacer monkeypatching de la clase funciona bien. ($foo->list() no es un error de sintaxis).
• Si una excepción es lanzada mientras se evalúan los argumentos de un constructor (por ejemplo, new Foo(bar()) y bar() la arroja), el constructor no será llamado pero el destructor lo será. (Esto está arreglado en PHP 5.3).
• Las excepciones en __autoload y los destructores causan errores fatales. (Arreglado en PHP 5.3.6. Entonces ahora un destructor podría arrojar una excepción literalmente en cualquier lugar, dado que es llamado en el momento en donde el contador de referencias deja el zero. Hmm.)
• No hay constructores o destructores. __construct es un inicializador, igual que el __init__ de Python. No hay método que puedas llamar en una clase para reservar memoria y crear un objeto.
• No hay inicializador por defecto. Llamar a parent::_construct() si la clase padre no define su propio __construct es un error fatal.
• OO trae consigo una interfaz de interador que partes del lenguaje respetan (por ejemplo, for…as), pero nada incorporado (como los arrays) implementa la interfaz. Si quieres un iterador de array, debes envolverlo en un ArrayIterator. No hay maneras incorporadas de encadenar llamadas o partir collecciones o trabajar de alguna otra forma con los iteradores como objetos de primera clase.
• Las interfaces como Iterator se reservan unos beuenos métodos sin prefijos. Si quieres que tu clase sera iterable (sin el comportamiento por defecto de iterar en todos sus atributos), pero quieres usar un método común como key, o next, o current, bueno, lástima.
• Las clases pueden sobrecargar cómo se convierten a strings y cómo actúan cuando son llamadas, pero no cómo se convierten a números ni a ningún otro tipo incorporado.
• Las cadenas, números y arrays todos tienen conversiones a cadena; el lenguaje recae fuertemente en esto. Las funciones y las clases son cadenas. Aún así, intentar convertir un objeto incorporado o definido por el usuario (incluso una clausura) a un string causa un error si no se define __toString. Incluso echo se convierte en propenso a errores.
• No hay sobrecarga para igualdad u ordenamiento.
• Las variables estáticas dentro de los métodos de instancias son globales; tienen el mismo valor en todas las instancias de la clase.

Librería estándar

Perl es “algo de construcción necesaria”. Python es “baterías incluidas”. PHP es “de todo y más, pero es de Canadá y ambas llaves dicen C“.

General

• No hay sistema de módulos. Puedes compilar extensiones PHP, pero las que se carguen son especificadas en php.ini, y tus opciones son que una extensión exista (e inyecte sus contenidos en el espacio de nombres global) o no.
• Como los espacios de nombres son una característica reciente, la librería estándar no está dividida para nada. Hay miles de funciones en el espacio de nombres global.
• Pedazos de la librería son terriblemente inconsistentes de otros.
  • Guión bajo versus sin guión bajo: strpos / str_rot13, php_uname / phpversion, base64_encode / urlencode, gettype / get_class.
  • “to” versus “2″: ascii2ebcdic, bin2hex, deg2grad, strtolower, strtotime.
  • Objeto+verbo versus verbo+objeto: base64_decode, str_shuffle, var_dump versus create_function, recode_string.
  • Orden de argumentos: array_filter($input, $callback) versus array_map($callback, $input), strpos($haystack, $needle) versus array_search($needle, $haystack).
  • Confusión de prefijos: usleep versus microtime.
  • Funciones insensitivas a mayúsculas y minúsculas que varían en donde la i va en el nombre.
  • Alrededor de la mitad de las funciones de arrays comienzan con array_. Las otras no.
  • htmlentities y html_entity_decode son inversas una de la otra, con convenciones de nombre completamente distintas.
• De todo y algo más. La librería incluye:
  • Bindeos a ImageMagick, bindeos a GraphicsMagick (que es un fork de ImageMagick), y un puñado de funciones para inspeccionar datos EXIF (que ImageMagick ya puede hacer).
  • Funciones para parsear bbcode, un tipo de markup muy específico utilizado por un puñado de paquetes de foros.
  • Demasiados paquetes XML. DOM (orientado a objetos), DOM XML (no), libxml, SimpleXML, “XML Parser”, XMLReader/XMLWriter, y otra media docena de acrónimos que no puedo identificar. Hay seguramente algún tipo de diferencia entre estas cosas y eres libre de averiguar cuál es.
  • Bindings para dos procesadores específicos de tarjetas de crédito, SPPLUS y MCVE. ¿Qué?
  • Tres maneras de acceder a una base de datos MySQL: mysql, mysqli, y la cosa esa de abtracción PDO.

Influencia de C

Esto merece su propio título, porque es tan absurdo y aún así permea al lenguaje. PHP es un lenguaje de programación de alto nivel dinámicamente tipado. Aún así una porción masiva de la librería estándar son aún wrappers muy finos sobre APIs de C, con los siguientes resultados:

• Parámetros “out”, incluso a pesar de que PHP puede devolver hashes ad-hoc o múltiples argumentos con poco esfuerzo.
• Al menos una docena de funciones para obtener el último error de un subsistema en particular (ver más abajo), a pesar de que PHP ha tenido excepciones por ocho años.
• Verrugas como mysql_real_escape_string, a pesar de que tiene los mismos argumentos que mysql_escape_string, sólo porque es parte de la API C de MySQL.
• Comportamiento global para funcionalidad no-global (como MySQL). Usar múltiples conexiones a MySQL aparentemente requiere pasar un identificador de conexión en cada llamada a función.
• Los wrappers son realmente, realmente finos. Por ejemplo, llamar a dba_nextkey sin llamar a dba_firstkey generará un error de segmentación.
• Hay un conjunto de funciones ctype_* (por ejemplo, ctype_alnum), que mapean a las funciones de detección de clases de caracteres de C de nombres similares, a pesar de, digamos, isupper.

Genericismo

No hay ninguno. Si una función tiene que hacer dos cosas ligeramente distintas, PHP simplemente tiene dos funciones.

¿Cómo ordenas en orden inverso? En Perl podrías hacer sort { $b <=> $a }. En Python, podrías hacer sort(reverse=True). En PHP hay una función separada llamada rsort().

• Funciones que buscan un error de C: curl_error, json_last_error, openssl_error_string, imap_errors, mysql_error, xml_get_error_code, bzerror, date_get_last_errors, ¿otras?
• Funciones que ordenan: array_multisort, arsort, asort, ksort, krsort, natsort, natcasesort, sort, rsort, uasort, uksort, usort.
• Funciones que encuentran texto: ereg, eregi, mb_ereg, mb_eregi, preg_match, strstr, strchr, stristr, strrchr, strpos, stripos, strrpos, strripos, mb_strpos, mb_strrpos, más las variaciones que hacen reemplazos.
• Hay muchos alias también, lo que ciertamente no ayuda al tema: strstr / strchr, is_int / is_integer / is_long, is_float / is_double, pos / current, sizeof / count, chop / rtrim, implode / join, die / exit, trigger_error / user_error, diskfreespace / disk_free_space, …
• scandir devuelve un listado de archivos en un directorio dado. En lugar de (potencialmente útil) devolverlos en el orden del directorio, la función devuelve los archivos ya ordenados. Y hay un argumento opcional para obtenerlos en orden alfabético inverso. No había, aparentemente, suficientes funciones de ordenamiento. (PHP 5.4 agrega un tercer valor para la dirección del ordenamiento que deshabilitará el ordenamiento.)
• str_split partirá una cadena en pedazos de igual tamaño. chunk_split parte una cadena en pedazos de igual tamaño y luego los une con un delimitador.
• Leer archivos requiere un conjunto separado de funciones dependiendo del formato. Hay seis grupos separados de esas funciones, todas con APIs diferentes, para bzip2, LZF, phar, rar, zip y gzip/zlib.
• Ya que llamar a una función con un array como sus argumentos es tan raro (call_user_func_array), hay algunos pares como printf / vprintf y sprintf / vsprintf. Estos hacen lo mismo, pero una función toma argumentos y la otra toma un array de argumentos.

Texto

• preg_replace con la opción /e (eval) hará un reemplazo de los resultados encontrados con una cadena de texto, y luego la evalúa.
• strtok está aparentemente diseñado desde la función C equivalente, la que ya es una mala idea por varias razones. Dejando de lado que PHP puede fácilmente deolver un array (mientras esto es raro en C), o que el mismo hack que strtok(3) usa (modificando la cadena en-el-lugar) no es usada aquí.
• parse_str parsea un query string, con ninguna indicación en su nombre. También actúa igual que register_globals y arroja el query en tu ámbito local como variables, a menos que le pases un array para que popule. (No devuelve nada, por supuesto.)
• explode se rehusa a separar cadenas con un limitador vacío o faltante. Todas las otras implementaciones de separación de cadenas hace algo útil en este caso; PHP en cambio tiene una función completamente separada, confusamente llamada str_split y descripta como “convierte una cadena a un array”.
• Para formatear fechas, está strftime, que actúa como la API de C y respeta el lugar. También está date, que tiene una sintaxis completamente distinta y sólo funciona en inglés.
• “gzgetss – Obtiene una línea desde un puntero a un archivo gz y remueve las etiquetas HTML.” Me estoy muriendo por conocer la serie de circunstancias que llevaron a la concepción de esta función.
• mbstring
  • Es todo sobre “multi-byte”, cuando el problema son los conjuntos de caracteres.
  • Aún así opera en cadenas comunes. Tiene un conjunto de caracteres “por defecto” global. Algunas funciones permiten un conjunto específico, pero luego aplica a todos los argumentos y el valor de retorno.
  • Provee funciones ereg_*, pero esas están obsoletas. preg_* no tienen suerte, aunque pueden entender UTF-8 pasándoles un indicador PCRE específico.

Sistema y reflexión

• Hay, en general, muchas funciones que bordean la línea entre texto y variables. compact y extract son sólo la punta del iceberg.
• Hay muchas formas de ser dinámico en PHP, y en una primera mirada no hay una diferencia obvia o beneficios orelativos. classkit puede modificar clases definidas por el usuario; runkit lo suplanta y puede modificar cualquier cosa definida por el usuario; las clases Reflection* pueden reflexionar en la mayor parte del lenguaje; hay una buena cantidad de funciones individuales para reportar propiedades de funciones y clases. ¿Son estos subsistemas independientes, relacionados, redundantes?
• get_class($obj) devuelve el nombre de la clase del objeto, get_class() devuelve el nombre de la clase de la función que lo llama. Dejando de lado que esta única función hace dos cosas radicalmente distintas: get_class(null) funciona como el segundo. Por tanto no se lo puede confiar en un valor arbitrario. ¡Sorpresa!
• Las clases stream_* permiten implementar objetos de flujos de datos personalizados para usar con fopen y otros elementos inherentes archivezcos. “tell” no puede ser implementado por razones internas. (También hay MUCHAS funciones involucradas con este sistema.)
• register_tick_function aceptará un objeto clausura. unregister_tick_function no; en lugar de eso arroja un error quejándose de que la clausura no puede ser convertida a cadena.
• php_uname te cuenta sobre el sistema operativo actual. A menos que PHP no pueda decir en qué está corriendo, en cuyo caso te cuenta sobre el sistema operativo en el que fue compilado. No te avisará si esto ocurrió.
• fork y exec no son propios del lenguaje. Vienen con la extensión pcntl, pero no está incluida por defecto. popen no provee un pid.
• El valor de retorno de stat es cacheado.
• session_decode es para leer una cadena de sesión PHP arbitraria, pero sólo funciona si ya hay una sesión activa. Y deja el resultado en $_SESSION, en lugar de devolverlo.

Misceláneos

• curl_multi_exec no cambia curl_errno cuando ocurre un error, pero sí cambia curl_error.
• Los argumentos de mktime son, en orden: hora, minuto, segundo, mes, día, año.

Manipulación de datos

Los programas no son más que grandes máquinas que mastican datos y escupen más datos. Varios lenguajes grandiosos están diseñados alrededor de los tipos de datos que manipulan, desde awk hasta Prolog, hasta C. Si un lenguaje no puede manejar datos, no puede hacer nada.

Números

• Los enteros tienen signo y tienen 32 bits en plataformas de 32 bits. A diferencia de todos los contemporarios de PHP, no hay promoción automática a bigint. Por lo que puedes terminar con sorpresas como tamaños de archivos negativos, y tu matemática puede funcionar diferentemente basada en la arquitectura del CPU. Tu única opción para enteros más grandes es usar las funciones wrapper GMP o BC. (Los desarrolladores han propuesto añadir un nuevo tipo, separado, de 64 bits. Esto es locura.)
• PHP soporta sintaxis octal con un 0 inicial, por lo que, por ejemplo, 012 será el número diez. Sin embargo, 08 se convierte en el número cero. El 8 (o 9) y cualquier dígito posterior desaparecen. 01c es un error de sintaxis.
• 0×0+2 produce 4. El parser considera el 2 como parte simultánea del literal hexadecimal y como un literal decimal separado, tratando esto como 0×002 + 2. 0×0+0×2 muestra el mimo problema. Extrañamente, 0×0 +2 es todavía 4, pero 0×0+ 2 es correctamente 2. (Esto se arregló en PHP 5.4. Pero también se volvió a romper en PHP 5.4 con el nuevo prefijo literal 0b: 0b0+1 produce 2.)
• pi es una función. O hay una constante, M_PI.
• No hay operador de exponenciación, sólo la función pow.

Texto

• No hay soporte Unicode. Sólo ASCII trabajará confiablemente. Existe la extensión mbstring, mencionada arriba, pero apesta un poco.
• Lo que significa que usar las funciones incorporadas en texto UTF-8 lo corrompe.
• Similarmente, no hay concepto de, por ejemplo, comparaciones de mayúsculas o minúsculas fuera de ASCII. A pesar de la proliferación de versiones insensitivas a la capitalización de las funciones, ninguna de ellas considerará é igual a É.
• No puedes encomillar claves en interpolación de variables, es decir, “$foo['key']“ es un error de sintaxis. Puedes des-encomillarlo (lo que sí generaría una advertencia en cualquier otro lugar!), o usar ${…}/{$…}.
• “${foo[0]}” está bien. “${foo[0][0]}” es un error de sintaxis. Poner el $ dentro está bien en ambos casos. ¿Mala copia de la sintaxis similar de Perl (con semánticas radicalmente distintas)?

Arreglos

Oh…

• Este tipo de datos actúa como lista, hash ordenado, conjunto ordenado, lista dispersa, y ocasionalmente alguna combinación extraña de esos. ¿Cómo se desempeña? ¿Qué tipo de uso de memoria habrá ahí? ¿Quién sabe? De cualquier modo, no es como si tuviera otras opciones.
• => no es un operador. Es una construcción especial que sólo existe dentro de array(…) y la construcción foreach.
• El indexado negativo no funciona, ya que -1 es una clave válida como 0.
• A pesar de que esta es la única estructura de datos del lenguaje, no hay sintaxis corta para él; array(…) es la sintaxis corta. (PHP 5.4 trae “literales”, [...].)
• La construcción => está basada en Perl, que permite foo => 1, sin comillas. (Eso es, de hecho, porque existen en Perl; de otra forma es sólo una coma.) En PHP no puedes hacer esto sin obtener una advertencia; es el único lenguaje en su nicho que no tiene forma aprobada de crear un hash sin encomillar las claves de cadena.
• Las funciones de arreglos por lo general tienen comportamietno confuso o inconsistente porque tienen que operar en listas, hashes o quizá una combinación de los dos. Consideren array_diff, que “computa la diferencia de los arreglos”.
  $primero = array(“foo” => 123, “bar” => 456);
  $segundo = array(“foo” => 456, “bar” => 123);
  echo var_dump(array_diff($primero, $segundo));
  ¿Qué hará este código? Si array_diff trata sus argumentos como hashes, obviamente estos son diferentes; las mismas claves tienen distintos valores. Si los trata como listas, aún son distintas; los valores están en orden distinto.
  En realidad array_diff considera a estos iguales, porque los trata como conjuntos, compara solamente valores e ignora el orden.
• En una vena similar, array_rand tiene el extraño comportamiento de seleccionar claves al azar, que no es tan útil para el caso más común de necesitar elegir de un listado de opciones.
• A pesar de lo mucho que el código PHP recae en preservar el orden de las claves:
  array(“foo”, “bar”) != array(“bar”, “foo”)
  array(“foo” => 1, “bar” => 2) == array(“bar” => 2, “foo” => 1)
  Dejo como ejercicio al lector averiguar qué ocurre si los arreglos son mezclas. (Yo no lo sé.)
• array_fill no puede crear arreglos de tamaño cero, en lugar de eso emitirá una advertencia y devolverá falso.
• Todas de las (muchas…) funciones de ordenamiento operan en-el-lugar y no devuelven nada. No hay forma de crear una copia ordenada; hay que copiar el arreglo manualmente, luego ordenarlo, y luego usarlo.
• Pero array_reverse devuelve un nuevo arreglo.
• Un listado de cosas ordenadas y algunos mapeos de claves a valores suena como una gran manera de manejar argumentos de funciones, pero no.

No arreglos

• La librería estándar incluye “Quickhash”  una implementación OO de “clases específicas fuertemente tipadas” para implementar hashes. Y, efectivamente, hay cuatro clases, cada una tratando una combinación distinta de tipos de claves y valores. No está claro por qué la implementación incorporada de arreglos no puede optimizar para estos casos extremadamente comunes, o lo que la performance relativa es.
• Hay una clase ArrayObject (que implemente cinco interfaces distintas) que puede envolver a un arreglo y permitirle actuar como objeto. Las clases de usuario pueden implementar las mismas interfaces. Pero sólo tienen un puñado de métodos, la mitad de los cuales no se parecen a las funciones incorporadas, y las funciones incorporadas de arreglos no saben cómo operar con un ArrayObject o cualquier otra clase parecida a arreglos.

Funciones

• Las funciones no son datos. Las clausuras son de hecho objetos, pero las funciones comunes no. No puedes referirte a ellas con sus nombres; var_dump(strstr) emite una advertenia y asume que querías la cadena literal “strstr”. No hay manera de discernir entre una cadena arbitraria y una “referencia” a función.
• create_function es básicamente un wrapper alrededor de eval. Crea una función con un nombre común y la instala globalmente (para que nunca sea recolectada por el recolector de basura — ¡no la uses en un bucle!). De hecho no sabe nada sobre el ámbito actual, por lo que no es una clausura. El nombre contiene un byte NUL para que nunca pueda entrar en conflicto con una función común (porque el parser de PHP falla si hay un NUL en el archivo, en algún lado).
• Declarar una función llamada __lambda_func romperá create_function — la implementación real es llamar a eval, crear la función llamada __lambda_func, e internamente renombrarla al nombre roto. Si __lamda_func ya existe, la primera parte arrojará un error fatal.

Otros

• Incrementar (++) un NULL produce 1. Decrementar (–) un NULL produce NULL. Decrementar una cadena de la misma forma la deja sin cambios.
• No hay generadores.

Framework web

Ejecución

• Un único archivo php.ini compartido controla partes masivas de la funcionalidad de PHP e introduce reglas complejas respecto de qué se antepone a qué y cuándo. El software PHP que espera ser instalado en máquinas arbitrarias tiene que reescribir configuraciones de todos modos para normalizar su entorno, lo que derrota en mayor parte el uso de un mecanismo como php.ini de todos modos.
  • PHP busca a php.ini en varios lugares, por lo que puede (o puede que no) ser posible que se anteponga al de tu host. Sólo un archivo de esos será parseado, sin embargo, por lo que no puedes sobreescribir un par de configuraciones y terminar ahí.
• PHP básicamente corre como CGI. Cada vez que una página es alcanzada, PHP recompila toda la cosa antes de ejecutarse. Incluso los frameworks de juguete de servidores de Python no actúan así.
  Esto ha llevado a un mercado completo de “aceleradores de PHP” que sólo compilan una vez, acelerando PHP hasta el nivel de cualquier otro lenguaje. Zend, la compañía detrás de PHP, ha hecho esto parte de su modelo de negocios.
• Por un tiempo algo largo, los errores PHP iban al cliente por defecto — supongo que para ayudar durante el desarrollo. No creo que esto siga siendo verdad, pero todavía veo el error de mysql siendo escupido al principio de alguna página.
• PHP está lleno de extraños “huevos de pascua”, como producir el logo de PHP con el argumento correcto. No sólo es esto completamente irrelevante a construir tu aplicación, sino que permite a cualquiera detectar si estás usando PHP (y quizá incluso estimar aproximadamente la versión), a pesar de cuántas configuraciones mod_rewrite, FastCGI, proxy inverso o Server: tengas.
• Las líneas en blanco antes o después de los tags <?php … ?>, incluso en librerías, cuentan como texto literal y es interpolado en la respuesta (o causa errores de “cabeceras ya enviadas”). Tus opciones son o estrictamente evitar líneas extras al final de cada archivo (el siguiente luego de ?> no cuenta), o simplemente evitar el token de cerrado ?>.

Implantanción

La implantación por lo general se cita como una de las mayores ventajas de PHP: copiar algunos archivos y listo. En verdad, eso es mucho más fácil que correr un proceso completo como puede que tengas que hacer en Python, Ruby o Perl. Pero PHP deja mucho que desear.

En todas partes estoy en favor de correr las aplicaciones web como servidores de aplicación y hacer proxies reversos a ellos. Toma un esfuerzo mínimo configurar esto y los beneficios son muchos: puedes manjar tu servidor web y tu aplicación separadamente, puedes correr tantos o tan pocos procesos de la aplicación en tantas máquinas como quieras sin necesitar más servidores web, puedes correr la aplicación con un usuario diferente con cero esfuerzo, puedes cambiar de servidores web, puedes bajar la aplicación sin tocar el servidor web, puedes hacer implantación continua solo cambiando unos puntos fifo, etc. Malear tu aplicación a tu servidor web es absurdo y no hay una buena razón para hacerlo más.

• PHP está naturalmente atado a Apache. Correrlo separadamente, o con cualquier otro web server requiere igual de trabajo (posiblemente más) que implantar cualquier otro lenguaje.
• php.ini se aplica a cada aplicación en cualquier lugar. Hay un único archivo php.ini, y aplica globalmente; si estás en un server compartido y necesitas cambiarlo, o si corres dos aplicaciones que necesitan configuraciones distintas, no tuviste suerte; tienes que aplicar la unión de todas las configuraciones y diferenciarlas desde dentro de las aplicaciones mismas usando init_set o en el archvio de configuración de Apache o en .htaccess. Si puedes. También wow, hay un montón de lugares que necesitas checkear para darte cuenta de cómo una configuración está obteniendo su valor.
• Similarmente, no hay forma de “aislar” una aplicación PHP y sus dependencias del resto del sistema. ¿Correr dos aplicaciones que requieren diferentes versiones de una librería, o incluso de PHP mismo? Comienza construyendo una segunda copia de Apache.
• La aproximación de “un montón de archivos”, aparte de hacer el ruteo un gran dolor de trasero, también significa que debes cuidadosamente abilitar o deshabilitar lo que está de hecho visible, porque tu jerarquía de URLs es también tu árbol de código entero. Los archivos de configuración otros “parciales” necesitan guardas C-simil para prevenir que sean cargados directamente. El ruido de control de versiones (e.g., .svn) necesita protección. Con mod_php, todo en tu sistema es un punto potencial de entrada; con un servidor de aplicación, hay un sólo punto de entrada y la única URL controla si es invocada.
• No puedes hacer una actualización continua de un montón de archivos que corren estilo-CGI, a menos que quieras crashes y comportamiento indefinido a medida que los usuarios llegan a tu sitio a medio camino de la actualización.
• A pesar de lo “simple” que es de configurar Apache para que corra PHP, hay trampas sutiles incluso ahí. Mientras la documentación de PHP sugiere usar SetHandler para hacer que los archivos .php corran como PHP, AddHandler parece funcionar igual de bien, y de hecho Google me da el doble de resultados para él. Aquí está el problema.
  Cuando usas AddHandler, le estás diciendo a Apache que “ejecutar esto como php” es una posible forma de ejecutar archivos .php. ¡Pero! Apache no tiene la misma idea de las extensiones de archivos que cualquier otro humano en el planeta tiene. Está diseñado para soportar, digamos, index.html.en siendo reconocido ambos como inglés y como HTML. Para apache, un archivo puede tener cualquier número de extensiones simultáneamente.
  Imagina que tienes un formulario de subida de archivos en un directorio público. Para asegurarte que nadie suba archivos php, solo verificas que no tengan una extensión .php. Todo lo que un atacante tiene que hacer es subir un archivo llamado foo.php.txt; tu formulario no verá el problema, pero Apache lo reconocerá como PHP y lo ejecutará alegremente.
  El problema aquí no es “usar el nombre de archivo original” o “no validar mejor”, el problema es que tu servidor web está configurado para correr cualquier código con el que se encuentre — precisamente la misma propiedades que hace a PHP “fácil de implantar”. CGI requería, +x, que era algo, pero PHP ni siquiera eso. Y esto no es un problema teórico; he encontrado muchos sitios actuales con este problema.

Características faltantes

Considero todas estas ser de distinto nivel de crítico para construir una aplicación web. Parece razonable que PHP, con su mayor punto de venta siendo que es un “lenguaje web”, debería tener algunas de ellas.

• No hay sistema de templates. Está PHP en sí mismo, pero nada que funcione como un gran interpolador más que un programa.
• No hay filtros de XSS. No, “recuerda usar htmlspecialchars” no es un filtro XSS. Esto es.
• No hay protección CSRF. Te toca hacerlo a tí.
• No hay API estándar de base de datos. Cosas como PDO tienen que envolver cada llamada individual a la API para abstraer las diferencias.
• No hay ruteo. Tu website se ve exactamente igual que tu sistema de archivos. Muchos desarrolladores han sido engañados en pensar que mod_rewrite (y .htaccess en general) es un sustituto aceptable.
• No hay autenticación o autorización.
• No hay servidor de desarrollo. (“Arreglado” en 5.4. Llevó a la vulnerabilidad de Content-Length de más abajo. También, tienes que portar todas tus reglas de rewrite a una cosa que envuelve PHP, porque no hay ruteo.)
• No hay debugging interactivo.
• No hay un mecahismo de implantación coherente; sólo “copiar todos estos archivos al servidor”.

Seguridad

Límites del lenguaje

La reputación de seguridad pobre de PHP es en mayor parte porque toda datos arbitrarios de un lenguaje y los tira en otro. Esto es mala idea. “<script>” puede no significar nada en SQL, pero ciertamente lo hace en HTML.

Haciendo esto peor está el grito común por “sanitizar tus entradas”. Esto está completamente equivocado; no puedes mover una varita mágica para hacer que un montón de datos estén inherentemente “limpios”. Lo que necesitas es hablar el lenguaje: usar placeholders con SQL, usar listas de argumentos cuando se generan procesos, etc.

• PHP completamente alienta el “sanitizado”: hay una extensión de filtrado de datos entera para hacer eso.
• Todos los addslashes, stripslashes y otros sinsentidos relacionados-a-slashes son distracciones que no ayudan en nada.
• No hay, hasta lo que puedo decir, una forma segura de instanciar un proceso. SÓLO puedes ejecutarlo a través de una cadena por la línea de comandos. Tus opciones son escapar como loco y esperar que la línea de comandos por defecto use el escapado correcto, o pcntl_fork y pcntl_exec manualmente.
• Ambos escapeshellcmd y escapeshellarg existen con descripciones vagamente similares. Noten que en Windows, escapeshellarg no funciona (porque asume semántica de la línea de comandos Bourne) y escapeshellcmd sólo reemplaza un montón de puntuación con espacios porque nadie puede entender cómo funciona el escapado de comandos de Windows (que puede silenciosamente romper todo lo que estés intentando hacer).
• Los bindeos originales incorporados para MySQL, todavía ampliamente usados, no tienen forma de crear instrucciones preparadas.

Al día de hoy, la documentación de PHP sobre inyección SQL recomienda prácticas locas como checkeo de tipos, usando sprintf y is_numeric, manualmente usando mysql_real_escape_string en todos lados, o manualmente usar addslashes en todos lados (que ¡”puede ser útil”!). No hay mención de PDO o parametrización, excepto en los comentarios de los usuarios. Me quejé de este hecho específicamente a un desarrollador de PHP al menos hace dos años, estaba alarmado, y la página nunca cambió.

Inseguro-por-defecto

• register_globals. Está desactivado por defecto desde hace un tiempo ya, y se fue en 5.4. No me importa. Es una vergüenza.
• include aceptando URLs HTTP. Igual.
• Comillas mágicas. Tan cerca a seguro-por-defecto y aún así tan lejos de comprender el concepto totalmente. E, igual.
• Puedes, digamos, escanear una red usando el soporte XML de PHP, y abusando su soporte ubicuo de nombres-de-archivos-como-URLs. Sólo libxml_disable_entity_loader() puede arreglar esto, y el problema sólo está mencionado en los comentarios del manual.

Núcleo

El intérprete de PHP mismo ha tenido algunos problemas de seguridad fascinantes.

• En 2007 el intérprete tuvo una vulnerabilidad de desbordamiento de enteros. El arreglo comenzó con if (size > INT_MAX) return NULL; y se fue en picada desde allí. (Para aquellos que no estén cómodos con el C: INT_MAX es el mayor entero que entrará en una variable, nunca. Espero que puedan darse cuenta del resto desde ahí.)
• Más recientemente, PHP 5.3.7 se las arregló para incluir una función crypt() que permitiría, en efecto, a cualquiera loggearse sin un password.
• El servidor de desarrollo de PHP 5.4 es vulnerable a una denegación de servicio, porque toma el header Content-Length (que cualquiera puede setear a cualquier cosa) y trata de alocar eso en memoria. Esto es una mala idea.

Podría seguir desenterrando más, pero el punto no es que hay X exploits — el software siempre tiene bugs, pasa, no importa. La naturaleza de estos es horripilante. Y no me puse a buscar estos; sólo aparecieron en mi puerta en los últimos meses.

Conclusión

Algún comentarista ha correctamente señalado que no tengo una conclusión. Y, bueno, no tengo una conclusión. Si llegaste hasta aquí, asumo que estabas de acuerdo conmigo antes de haber comenzado. :)

Si sólo sabes PHP y estás curioso de aprender algo más, dale un intento al tutorial de Python y trata con Flask para la parte web. (No soy un fanático de su lenguaje de templates, pero cumple con su trabajo.) Desarma las piezas de tu aplicación, pero son aún las mismas piezas y deberían ser lo suficientemente familiares. Podría escribir un post real sobre esto más tarde; una intrducción remolino a un lenguaje entero y tecnologías web no pertenece aquí abajo.

Más tarde o para projectos más grandes podrías querer Pyramid, que es nivel-medio, o Django, que es una monstruosidad compleja que trabaja muy bien para construir sitios como el de Django.

Si no eres un desarrollador para nada pero aún leiste esto por alguna razón, no estaré feliz hasta que cualquiera en el planeta haya pasado por Aprender Python de la Manera Difícil, así que ve a hacer eso.

Está también Ruby on Rails y algunos competidores que no he usado nunca, y Perl sigue vivo y coleando con Catalyst. Lee cosas, aprende cosas, construye cosas, vuélvete loco.

Créditos

Gracias a los siguientes por la inspiración:

• PHP Turtles
• PHP Sadness
• PHP WTF
• YourLanguageSucks
• PHP in contrast to Perl
• La densa, furiosa e inspiracional bronca de Pi
• PHP is not an acceptable COBOL
• La documentación PHP
• un montón de fanáticos y contra-fanáticos PHP
• y, por supuesto, Rasmus Lerdorf por su salvaje mala interpretación de la mayoría de Perl

Háganme saber si tienen adiciones, o si estoy (¡con hechos!) equivocado sobre algo.

Entre finales del año pasado y comienzos de este vi varias películas que nunca comenté por aquí. Tengo mis ideas anotadas al respeto pero pasado el tiempo no creo que valga la pena dedicarle un post a cada una. Las razones son dos: por un lado habría demasiado post sobre películas, y por otro lado, han perdido relevancia al no ser tan actuales.

Entonces, las películas que recibirán mi calificación aquí serán (sin ningún orden en particular):

• Hotel Transylvania
• Paranormal Activity 4
• Wreck it Ralph
• The Man With the Iron Fists
• Life of Pi
• Don’t be afraid of the dark
• Cirque Du Soleil: Worlds Away
• Mama
• The Croods

Hotel Transylvania

Una de las películas del 2012 que más me gustó fue Hotel Transylvania. A pesar de lo predecible e infantil de su trama, realmente está llena de pequeños gags que la hacen divertida desde comienzo a final.

Es raro ver una película de animación que le de un tono renovado a los monstruos de terror, aunque lo sea ligeramente. Esta es una de esas, en donde, más allá de algunos ridículos, eso se da y con un pre-supuesto algo razonable: según la historia, Drácula construyó un hotel para monstruos, porque la humanidad les tiene miedo y se vuelve violenta hacia ellos. Por tanto, viven en el secreto y sólo se juntan una vez por año para celebrar en Halloween, cuando viajar y ser vistos no es un gran problema.

Pero la trama se centra en una historia más personal. La hija de Drácula, Mavis, siempre vivió encerrada en su castillo/hotel y se muere por conocer el mundo. Cumpliendo ahora ciento diechiocho años (adolescente para vampiros) quiere salir a conocer el mundo y su padre sabe cómo tratar con ese problema… hasta que un humano mismo entra, perdido, al hotel.

No hay mucho más que decir, la historia no es profunda y la animación es muy buena, pero no sobresaliente. La película en sí es tierna cuando debe serlo y graciosa cuando tiene la oportunidad. Quizá resaltaría que hay un poco de profundidad para Drácula cuando él comparte u historia y motivación personal. Para aquellos que sepan a qué momento me refiero, yo creo que podría haber sido más interesante si resultara que un personaje común a él y a Mavis tuviera más en común con Jonathan. Ustedes entenderán.

En fin, es una película entretenida, colorida y graciosa. Más de lo que en general puedo decir de las peliculas de Adam Sandler, pero la voy a aceptar. Le doy 3 zorrinitos de 5.

Paranormal Activity 4

Realmente no esperaba mucho de esta película, y no obtuve demasiado. La primera película me había gustado mucho: era novedosa en la forma en la que presentaba los hechos (bueno, medianamente), y parecía tener una historia por detrás. La segunda la extendió un poco, intentando explicar algunas cosas pero sin ahondar demasiado. La tercera fue una película que podría perderse en la historia sin lamentos para la humanidad y la cuarta fue irrelevante. En serio, irrelevante, porque la conexión con las películas anteriores es demasiado vaga.

No puedo decir que me gustara porque abusan del recurso del shock-terror, es decir, simplementer asustar a uno con ruidos fuertes y cosas que aparecen súbitamente. El terror psicológico que la historia generaba lo tenía más elaborado en las primeras dos películas.

Otra película que nadie recordará el siglo que viene. Le otorgo 2 de 5 zorrinitos.

Wreck it Ralph

Por el contrario, Wrick it Ralph me sorprendió para bien. Ciertamente no esperaba una historia compleja, y si bien no requiere de una atención detallista, esta película le da a su historia algunos vuelcos sorprendentes, quizá predecibles, pero comprensibles y factibles. No me pareció que ninguno de los hechos que ocurrieron fueran sacados de la galera y me agradó mucho la forma en la que los problemas se complicaron de muchas formas.

Más aún, me encantó que esta, como tantas otras películas, le da al villano buenas razones. Bueno, realmente no, pero no quiero spoilear la película. Digamos que mientras transcurren los eventos, se ven distintos puntos de vista sobre un problema, y cada punto de vista es, en cierta forma, válido. Eso hace el conflicto moral muy interesante, y ciertamente aquí ocurrió.

Por último, tiene muchos chistes ingeniosos y para los amantes de los videojuegos, miles de referencias para buscar.

Le doy 4 de 5 zorrinitos.

The Man With the Iron Fists

Esta película califica de bizarra, y no estoy seguro de si esa fue la intención. Al menos yo, es lo que esperaba y no me desilusionó, pero no la categorizaría de esencialmente buena. La historia se presenta en una mezcla de película de artes marciales con un héroe americano (¿por qué?) y una historia de clanes y traiciones. La realización del título de la película aparece ya muy avanzada la trama y no es racional. Sólo mirenlá sin expectativas y no se aburrirán.

Debo decir que lo que más me gustaron fueron las escenas de acción. De la forma en la que lo esperaba, muchas de ellas se mostraron como hermosas coreografías con violencia y gore incluido.

Le otorgo 2 de 5 zorrinitos.

Life of Pi

Me gustó el concepto, pero me decepcionó el final. Por alguna razón, es de esas películas extremadamente largas que no resultan divertidas pero tampoco aburren completamente. Lentamente cultiva conceptos que luego utiliza en otras partes de la historia, a veces a modo de enseñanza y a veces con la intención de demostrarnos que es fácil equivocarse. Está llena de pequeños chistes e ironías que no siempre son graciosos, de alguna forma haciéndolo similar a la vida real, y de historias que parecen ser iluminadoras sólo según la vista que se les de. Creo que muchos la encontrarán similar a Big Fish.

Sé que está basada en un libro del mismo nombre, pero no he leído nada al respecto.

Le doy 3 de 5 zorrinitos.

Don’t be afraid of the dark

Esta película me llamó la atención porque la estaría “remixando” Guillermo del Toro, quién se ha hecho en su fama un director que sabe utilizar el terror psicológico como un elemento para sus películas. Sin mayores rodeos, me sentí profundamente decepcionado, en múltiples niveles. La película no es más que una recopilación de clichés de terror, uno tras el otro, incluyendo el final y todo.

Aún así, a defensa de Guillermito, puedo decir que esta película no es de él, sino que él sólo quiso rehacerla por lo que personalmente significaba para él. Es posible que él se haya encontrado muy limitado por una película que en definitiva él no había escrito, y era aterrorizante en los 70′s.

En fin, le doy un sólo zorrinito de 5.

Cirque Du Soleil: Worlds Away

Siendo de Cirque Du Soleil, esperaba un gran despliegue de habilidades, luces y colores, y sin duda lo obtuve. La trama es simple pero la forma en la que se desarrolla no lo es, y lo menciono como algo positivo. El desarrollo es puramente interpretativo, mucha danza y acrobacia, en ocasiones de forma simultánea. Juegos de luces, música de distintos estilos, agua, plataformas móviles, acróbatas de destreza increíble, de fuerza sorprendente o de coreografìas magníficas.

Más aún, toda la película transcurre con al menos unas pocas palabras, y el resto es puramente no-verbal. Y de hecho, casi totalmente desprovista de referencias culturales específicas, excepto por un puñado de personajes.

Es una película ciertamente distinta de a lo que estamos acostumbrados. Yo le otorgo 3 de 5 zorrinitos.

Mama

Le dí otra oportunidad a Guillermo Del Toro, esta vez con una película que, por su trailer, aparentaba jugar con la adaptación de la sociedad a monstruos. Obviamente no me quedó muy claro el trailer porque la película no tenía nada que ver con eso. De hecho, de alguna forma también cayó en el cliché, y de alguna forma sigue la misma estructura que seguía Don’t Be Afraid of The Dark, como había comentado antes.

Dos pequeñas que no se adaptan a la sociedad ven algo que nadie más ve y… bueno, el resto lo pueden adivinar sin que lo escriba.

Le doy 2 zorrinitos de 5, sólo porque me cayó bien la personaje principal.

The Croods

Brave The Croods es la nueva película de Pixar Dreamworks, en este caso sobre una familia cavernícola que sobreviven gracias al miedo de la guerra de lo salvaje y a la protección de sus tradiciones. Pero Mérida Eep, la hija pelirroja, siente que su vida no puede continuar de esa forma y decide desafiar a su padre cuando descubre que hay una forma distinta de hacer las cosas. Ella se deja llevar por la brujería la ciencia de Guy y la batalla entre tradición y nuevas ideas comienza con altas y bajas para que eventualmente todos encuentren un final feliz en la capacidad de aceptar cosas nuevas y el punto de vista de los demás.

Ahora que está de moda el planteo de ciencia vs. religión me habría gustado que esta película planteara un sutil argumento de posiciones dogmáticas contra ideas abiertas. Parecía ir para aquel lado, pero creo que podría haber utilizado muchos más elementos que, además de hacer la analogía más exacta, le habría dado más dramatismo a la película. ¿Recuerdan como siempre menciono que las películas animadas caen en un doble-dramatismo? (¿En el momento en donde algo ocurre mal, algo ocurre peor y ya nadie confía en el héroe?) Bueno, no ocurrió aquí.

Por otro lado, me causó mucha gracia pensar que estaba viendo una versión cavernícola de Family Guy, en algún capítulo en donde el personaje principal sea Meg.

Realmente creía que me habría gustado esta película. Me entretuvo, pero no mucho más que eso. De todos modos, hay gags interesantes, un perezoso musical (que curiosamente andan de moda en internet) y la invención de cosas que riman con Grug.

Le doy 2 zorrinitos de 5 por la buena base.

En la entrega pasada hablamos sobre cómo comenzó el juego de Arkanoid, ahora continuaremos ese camino sobre la construcción del escenario de juego.

En esa instancia cubrimos la estructura general de los archivos, la inicialización del objeto canvas, los estilos a usar y la inicialización de las opciones. Dejamos algo pendiente, que era el escenario, en un objeto ArkanoidStage. En ese post no expliqué qué hacía este objeto o como trabajaba. Hoy comenzaremos por ahí. Lo que describiremos en este post está cubierto en el commit 90e6…abd9.

Introducción del escenario

Ya tenemos generado el objeto canvas y las opciones para comenzar a dibujar sobre el contexto. Ahora, toda esa lógica de dibujado debería ser encerrada en algún objeto que pueda coordinar los elementos a dibujar — o a no dibujar (por ejemplo, cuando un bloque desaparezca). Por otra parte, este objeto podrá hacer los cálculos de tamaños según el tamaño del escenario (una de las opciones que ya inicializamos).

Para eso introducimos la clase ArkanoidStage.

Como podrán ver, la declaración de clases en JavaScript no es realmente muy distinta de una función. En realidad, es una función, que funciona como generadora de los objetos y ámbito limitador de sus acciones. Los argumentos de esta función serán los parámetros actuales que son pasados al constructor (no hablaré de los parámetros formales porque no son realmente necesarios para el pasaje de los mismos). Como preferencia personal, declaro los parámetros a recibir para tener en cuenta en el futuro. Más aún, es más fácil hacer validaciones sobre ellos si es que quisiéramos.

Los parámetros que ArkanoidStage recibirá son tres: el contexto sobre el que se dibujará, el alto y el ancho del escenario. Asumiremos desde ahora que todas las distancias están medidas en píxeles, y que la coordenada (0, 0) es la esquina superior izquierda de la pantalla, aumentando hacia abajo y hacia la derecha.

Una buena idea para el cálculo de los dibujos a realizar es plantear una grilla. Para eso, decidiremos primero el tamaño de los bloques como una porción del ancho y alto disponible. De esta forma, el juego será siempre el mismo independientemente del tamaño de la ventana del navegador. Para eso, el escenario calcula blockHeight y blockWidth. Estamos considerando que en una pantalla de juego podrán entrar 10 bloques horizontalmente, y 50 bloques verticalmente. ¿Cómo surgieron estos números? Simplemente me gustaron, y encontré que la proporción entre ellos era bastante aceptable. Por supuesto, esto puede cambiar a gusto.

Ya que estamos calculando tamaños, es importante notar que hay un elemento que no sigue esta regla: la pelota del juego. A ella la haremos un poco más grande que el tamaño de un bloque, algo así como un bloque y medio de alto (su menor dimensión). Para eso entonces, calcularemos el radio de la pelota como un 80% del tamaño de un bloque, lo que nos dará una pelota de 1.6 bloques-alto de diámetro.

Por último, el escenario comenzará dibujando nuestro primer objeto: El jugador. Como el jugador posee lógica propia (movimiento fuera de la grilla, velocidad incremental), vamos a hacer una clase propia para este objeto. Pero por ahora, vamos a instanciarlo y a pedirle que se dibuje (líneas 7 y 8). Lo que el jugador necesitará es:

• el contexto (para dibujarse),
• un color (para dibujarse),
• el alto de un bloque (ya calculado para sus dimensiones)
• el ancho de un bloque (ya calculado para sus dimensiones)
• el ancho del escenario (para poder calcular sus movimientos)
• el alto del escenario (sólo por consistencia — pero en retrospectiva, podría haber eliminado esta parte)

Finalmente, nuestro escenario no tiene nada que devolver porque es quién se encargará de todo en el futuro. Por supuesto que la decisión podría ser otra, pero este es el camino que decidí tomar.

Como nota extra, notarán que no me preocupó escribir esto en el global scope. Como toda la lógica estará encerrada en cada uno de los objetos, me parece aceptable. Para aplicaciones reales o más complejas, aconsejaría encerrar en un namespace, que no sería más que una variable global a la que estas funciones se le van anexando. En este caso, no lo veo realmente necesario.

El jugador

El jugador será el primero de los elementos que se dibuje en nuestra pantalla, y eso ya agrega varias responsabilidades a resolver. El dibujado en sí no debería ser una responsabilidad del jugador, sino las características que lo hacen un jugador (como su posición y su movimiento). Por supuesto, también debe dibujarse pero esa no es una característica única de él. ¡Esto suena a herencia de objetos!

Por tanto, planteando que tendremos varios objetos que van a dibujarse, podemos partir desde entidades básicas que sabrán dibujarse. Llamemos a esa DrawableEntityBase. Siguiente a esto, habrá  dos tipos de entidades distintas que se dibujarán. Unas de ellas son bloques (cuadrados), como los bloques objetivos y el jugador. La otra será la pelota, que tendrá forma circular. Como el dibujado actual varía entre estos, DrawableEntityBase deberá delegar a sus clases hijas el dibujado, por lo que deberemos emular una clase abstracta, o una virtual que no haga nada por defecto. Prefiero emular una abstracta por mayor consistencia y forzar a que las clases hijas implementen su dibujado.

Por ahora nos ocuparemos de los bloques, y a estos los llamaremos DrawableBlock, heredando de DrawableEntityBase.

Y finalmente, entre los bloques, tendremos tanto a los bloques objetivos como al jugador. Concentrémosnos en el jugador por ahora, y creemos una clase para él: ArkanoidPlayer, heredando de DrawableBlock. Hasta este momento, esta es nuestra herencia de clases:

Vamos a un poco de código.

DrawableEntityBase

Lo primero a determinar es qué necesitará cualquier objeto que se pueda dibujar en pantalla. Está claro que necesitará el contexto 2D del canvas para dibujarse, y finalmente un color a ser usado para dibujarse. Esto tiene sentido si asumimos que cualquier entidad tendrá un único color, el cual es nuestro caso. Si no fuera así, cada tipo de entidad debería decidir cuántos colores recibe entre sus parámetros.

Lo primero de lo primero es validar que tenemos lo necesario. No me preocupa tanto el color, pero sí el contexto. Verificamos entonces, que el drawingContext exista. En JavaScript existe algo llamado falsy values, objetos y elementos que a pesar de no valer estrictamente false, aún así evalúan como false ante una expresión condicional. Estos son: false (obviamente), 0 (el número cero), “” (la cadena vacía), null (objeto nulo), undefined (objeto no definido) y NaN (números no numéricos — por contradictorio que suene). Para más detalles sobre valores truthy y falsy, les recomiendo leer Truthy and Falsy: When All is Not Equal in JavaScript.

Como en nuestra situación, cualquiera de esas es totalmente inválida para un contexto, podemos verificar con un simple negador. Por supuesto, que de ser más estricto podríamos verificar por el contexto siendo una instancia de las clases que los navegadores exponen como contextos, pero en mi opinión ya es mucha paranoia. Si este objeto no tiene los métodos que necesitamos, no tardaremos mucho en saberlo.

Como segundo acto, nos guardaremos referencias al contexto y al color, y declararemos nuestra función de dibujado: draw. Sin embargo, no podemos implementarla realmente — como dije, DrawableEntityBase debe comportarse como una clase abstracta. Lo que haremos es entonces arrojar una excepción dejando claro que una clase hija debe implementar este método. Eso prevendrá que podamos utilizarla (aunque no instanciarla individualmente, lo cual no es enteramente malo).

Por último, devolveremos nuestro método disponible para exponerlo como público a cualquier elemento que cree una instancia nuestra.

DrawableBlock

Algún texto esotérico que leí decía que crear es limitar. DrawableEntityBase es muy genérica y por eso no hace demasiado. Ahora la limitaremos y le daremos más funcionalidad, lentamente creando nuestro resultado.

Lo primero es crear nuestra nueva clase, y hacerla heredar de la clase base. Hay varias formas de hacer esto, y las más recomendadas incluyen librerías que ya se encargan de problemas de sobrecarga y múltiple herencia, pero yo quería hacer esto sin ninguna otra herramienta que mis dedos contra el teclado. De todas formas, las mejores recomendaciones vienen del señor John Resig, quien sabe mucho de JavaScript y nos cuenta de su forma de hacer herencia en su post sobre herencia JavaScript.

Para poder tener esta herencia, debemos, por supuesto, declarar la función, y agregar la clase base a su prototipo, lo que le dará al principio toda esa funcionalidad. Sin embargo, esto debe ocurrir antes de la implementación de la función. Si esto les resulta raro, tengan en cuenta que declaración e implementación son dos momentos distintos aunque se escriban en el mismo lugar. En el caso de JavaScript, el hecho de declarar la función la hace disponible tanto para el código posterior como el anterior, y eso es lo que nos permite utilizar su prototipo antes de darle cuerpo. Si bien el cuerpo será ejecutado después, me agrada la idea de mantener la información de herencia a la cabeza de la función.

El prototipo base debe tener una instancia de la clase base — ¿pero cómo creamos una instancia si no tenemos los parámetros necesarios? La forma más simple es hacer new DrawableEntityBase() sin pasar parámetros, lo que aún generaría la instancia. Esto, sin embargo, no nos sirve a nosotros porque tenemos validaciones que pueden arrojar errores. Para esto entonces podemos utilizar Object.create(), disponible desde JavaScript 1.8.5.

Por último, asignamos la función base al constructor de nuestro nuevo prototipo y comenzamos con el cuerpo de la función.

Lo primero es la declaración, con los argumentos que necesitaremos para construir y dibujar un bloque. Estos son:

• contexto para dibujar (la clase base lo necesita) — drawingContext
• color para dibujar (la clase base lo necesita) — color
• coordenada x de la esquina superior derecha — posX
• coordenada y de la esquina superior derecha — posY
• el alto del bloque a dibujar — height
• el ancho del bloque a dibujar — width

Lo segundo a hacer, pero primero en el cuerpo de la función, es llamar al constructor base, para que las variables internas necesarias sean inicializadas, y cualquier lógica de inicialización también sea ejecutada. Eso lo haremos utilizando el método call, que nos permite pasar como primer argumento el contexto de la función. Esto significa que la función se ejecutará como si se estuviera ejecutando en este mismo objeto. Para más información sobre call, pueden ver su documentación y algunos usos interesantes: MDN: Function.prototype.call.

Lo tercero a hacer es guardarnos los valores que necesitemos, y paso posterior, es darle una implementación a la función draw. Para esto sólo tenemos que utilizar el contexto y setear el color con el que se va a dibujar (fillStyle, que también tiene otras opciones), y pedirle dibujar un rectángulo utilizando fillRect, y pasando coordenadas y tamaños. Noten que la referencia a color que uso no está prefijada con self. como las demás. Esto es un error, y es importante si tenemos una clase compleja: la referencia a color sin prefijar se refiere al argumento pasado en la instanciación de ese objeto, que será único y no cambiará a menos que lo alteremos a mano. Sin embargo, si nuestra clase posee varios niveles de herencia, mixins o múltiples padres, sería posible que la referencia guardada en self.color cambiara, mientras que la que fue pasada por argumento no. Nostros perderíamos ese cambio por no utilizar la referencia correcta. Lo recomendable para mí es siempre utilizar las referencias almacenadas; no por alguna razón técnica, sino sólo por consistencia y organización.

ArkanoidPlayer

Siguiendo la misma técnica para la herencia de clases, ahora debemos declarar ArkanoidPlayer herendado de DrawableBlock. Podríamos requerir más argumentos en su constructor, específicos de ArkanoidPlayer, pero dado que no son realmente necesarios, vamos a calcularlos por defecto. Este es el caso de su posición en la pantalla.

Los parámetros que necesitaremos, entonces, son:

• contexto para dibujar (la clase base lo necesita) — drawingContext
• color para dibujar (la clase base lo necesita) — color
• alto del bloque (la clase base lo necesita) — blockHeight
• ancho del bloque (la clase base lo necesita) — blockWidth
• alto del escenario (para calcular la posición del jugador) — stageHeight
• ancho del escenario (para calcular la posición del jugador) — stageWidth

Nos guardamos las referencias a las variables nuevas y creamos dos más: la posición X y la posición Y, que se referirán a la esquina superior izquierda (desde la cual comenzaremos a dibujar el bloque). Es importante que estemos actualizando estas variables porque el redibujado debe utilizarlas para mover al jugador.

Como paso siguiente, llamamos al constructor de DrawableBlock pasando un default para la posición X y la posición Y , que serán correspondientes a:

• el punto X de la pantalla a dibujar el jugador para que el bloque esté centrado – (stageWidth – blockWidth)/2
  
• el punto Y de la pantalla a dibujar el jugador para que el bloque esté casi al final de la pantalla — stageHeight – blockHeight * 2
• el ancho del bloque a dibujar: blockWidth
• el alto del bloque a dibujar: blockHeight

También debemos proveer la posibilidad de centrar al jugador, cuando el juego comience o cuando debamos resetear la partida o avanzar de nivel. En este caso, vamos a actualizar las coordenadas. Declaramos la función centerPlayer y su cuerpo sólo actualizará la coordenada X, puesto que la coordenada Y del jugador nunca cambiará.

Para asegurarnos de tener los datos consistentes, llamamos a esa función y por último, devolvemos nuestro objeto con las funciones públicas disponibles.

La pelota

Teniendo toda esta base, plantear el dibujado de un círculo para representar la pelota con la que se interactúa no es demasiado difícil. Extendemos DrawableEntityBase para declarar DrawableCircle y redefinimos sus propiedades para basarse en el centro (y no una esquina) y el radio (y no ancho/alto) y reescribimos la implementación de draw() para que llame a la función correspondiente del contexto.

Para este caso, invocaremos a ellipse(), quién recibe los siguientes parámetros:

• el punto X del centro del círculo
• el punto Y del centro del círculo
• el radio en la dimensión X
• el radio en la dimensión Y (en nuestro caso, el mismo)
• la rotación — en nuestro caso cero, será un círculo perfecto y la rotación no cambiaría nada, sólo agregaría procesamiento extra
• el ángulo de comienzo de la elipse — en nuestro caso, cero
• el ángulo de fin de la elipse — en nuestro caso, cero, para una vuelta completa
• si debe dibujarse en sentido antihorario — en nuestro caso false, pero es indiferente

Hasta ahora, entonces, nuestra jerarquía de objetos se vería así:

No será la última vez que trabajemos con la pelota, porque además de la capacidad de dibujarse, hay otras características que deberemos tratar más adelante.

Con todo esto, ya tenemos los elementos principales para comenzar a trabajar en el orden y la interacción de elementos entre sí. Material que dejaré para otros posts.

Por lo general hablamos de una disciplina siendo un arte cuando tiene cierta belleza en sí (apreciada o inapreciada) y cuando requiere de mucha habilidad para hacerlo bien. Sin embargo, para que algo sea considerado arte realmente, hay otros requisitos. No soy un experto en el tema, pero quería intentar darle una mirada a esta pregunta y ver a dónde me lleva.

El desarrollo de software

Esta disciplina es, como mínimo, rara. Alguien alguna vez la describió como “construir castillos en el cielo”. La disciplina de generar estructuras y procesos desde la absoluta nada. Tanta flexibilidad, tanta libertad puede fácilmente caer en el caos, y esto es algo que ha sido muy fácilmente observado por los desarrolladores de varias décadas en el pasado. Como el desorden genera complejidad innecesaria, y esa complejidad se observa como flujos sin dirección clara, el término de Spaghetti Code fue acuñado tiempo atrás, incluso llevando consigo varios otros términos del mundo de la pasta.

Sin embargo, estructuras, métodos y paradigmas surgieron. Formas de hacer las cosas que nos aseguran que diferentes partes tengan significados diferentes, y partes similares estén juntas. Métodos que nos aseguran separar distintos conceptos en distintas entidades (como lógica de cálculo vs. almacenamiento de datos). Métodos que nos aseguran que cada cambio agregará o cambiará algo sin afectar a nada más. Métodos que nos permiten medir la velocidad de trabajo o el avance. Métodos que se pueden reusar una y otra vez para resolver problemas similares.

Y la complejidad de estos métodos creció tanto que comenzaron a hablarse de patrones de arquitecturas, una palabra que denota una actividad compleja y difícil: construir objetos complejos desde partes simples, que requiere a alguien con más habilidad que un trabajador normal. (Del griego: arkhi: jefe, tekton: construir.) Las arquitecturas a su vez se acoplan, se mezclan y se redefinen cada vez que el mercado hace disponible una nueva tecnología por hardware más barato y software más potente. Los sabios de la disciplina hablan de simplificar. YAGNI (You Ain’t Gonna Need It — no lo vas a necesitar) para evitar complejidad injustificada, KISS (Keep It Simple Stupid — mantenlo simple y estúpido), para concientemente abocar por la simplicidad.

Está claro que la disciplina es compleja, y que existen no sólo reglas de cómo hacer las cosas bien o “mejor de lo común”, sino que además existe una amplia gama de posibilidades en cuanto a complejidad. En mi desarrollo personal he encontrado que hay distintos tipos de persona que disfrutan de distintos niveles de complejidad para una misma solución. La complejidad no es inherentemente mala, sino que es un precio a pagar por mayor flexibilidad o robustez. Todos ellos tienen una idea distinta de lo que un software bello es, y esa belleza no se encuentra en el producto, sino en la estructura interior y el proceso.

El arte

El arte no carece de reglas u opiniones, y, a pesar de la opinión popular, no cualquier cosa es arte. También existen reglas básicas que definen qué es y qué no lo es. He aquí algunas cuantas, pero no son todas. Cabe aclarar que aún así, existen muchas disputas sobre esto, pero muy básicamente, algunas cosas pueden decirse.

1. El propósito de la obra debe ser la evocación de un sentimiento. Todo arte se hace con el objetivo de alimentar el sentimiento. (Del artista o de la audiencia.) Como todo ser humano posee en cierta medida la necesidad de experimentar sentimientos, la necesidad también puede convertirse en negocio. Nadie discutiría que el cine y la música son artes, incluso aunque sean un negocio millonario. Incluso aunque se hagan con objetivo de vender, puede cumplir el propósito de evocar sentimientos.

1. a. Como extensión de lo anterior, la obra no debe ser utilizada como herramienta. Es por esto que el arte se exhibe para ser experimentado y no se usa como medio para algo más. Esto define una línea muy fina entre el arte y el diseño (que también juega con el concepto de belleza y experiencias de uso). Un martillo no es arte. Un martillo bonito no es arte. Un martillo colgado en el centro en una habitación vacía para causar confusión podría ser arte. Un martillo destruyendo una obra clásica para señalar lo etéreo de todo lo material es arte.

2. La obra debe transmitir un mensaje. Muchas corrientes artísticas quieren desafiar este concepto, pero ese desafío ya es un mensaje en sí. Cada obra tiene algo que decir, algo que quiere expresar. Las distintas corrientes artísticas se enfocan en distintos mensajes, en distintas formas de hacer llegar ese mensaje o en distintas formas de apreciar el mismo concepto. El arte abstracto es, muy a mi pesar, arte que habla de la belleza sin necesidad de formas. El arte conceptual busca el mensaje profundo en el mundo ordinario. El expresionismo utiliza el color como herramienta principal para enviar un mensaje. El romanticismo utiliza nuestra posición en un universo vasto para transmitir el mensaje.

2. a. Como consecuencia, el mensaje debe poder ser transmitido. Cuando el mensaje no encuentra su camino y no provoca el sentimiento que debe provocar, falló en su propósito. Esto se pone interesante cuando el propósito de la obra en sí es producir confusión. Pero si el mensaje en general no se entiende, no se considera una forma de arte. Considérenlo de esta forma: ¿era la literatura un arte cuando sólo los monjes sabían leer y escribir? Probablemente no. ¿Era un arte la cinematografía cuando las primeras películas fueran inventadas por los hermanos Lumière? Sí, porque cualquiera que viera la obra la comprendería y obtendría su mensaje.

Desarrollo y arte

Teniendo esas ideas en mente, volvamos a analizar el desarrollo de software.

1. ¿Es su propósito evocar un sentimiento? Por lo general, no. (El software no cuenta: es un producto del desarrollo, no desarrollo en sí.) Sin embargo, estos últimos tiempos han mostrado más y más casos en donde se desarrolla por el placer de desarrollar. A la vez, muchas técnicas han permitido exaltar el valor interesante del desarrollo más allá de su producto, y de la forma en la que sus partes interactúan. Estos procesos y estos objetivos se alinean con el objetivo original del desarrollo — obtener un producto — pero no tiene el mismo objetivo.

Por otro lado, dado que ya entre muchas comunidades no se entregan sólo productos sino código, y muchas veces, no el código en sí, sino la creatividad detrás del código. (Y tengo un ejemplo favorito.) En ellas muchas veces se transmite lo bueno o lo malo de las estructuras, lo bello de la sincronización, lo bizarro de las decisiones mal tomadas. A veces, el propósito es el mensaje.

Consideremos esto como un punto semi-aceptable.

1. a. ¿Es utilizado como herramienta? Sí, lo es. En más del 90% de los casos, el desarrollo de software es la herramienta que nos dará el producto que estamos buscando. En esa minoría, existen casos en donde el propósito es el desarrollo en sí y la experiencia que este brinda. Creo que fácilmente podremos estar todos de acuerdo con esto. Las estructuras y los diseños buscan hacer este proceso más simple, y buscan brindar un sentido de significancia al proceso y a las entidades internas del software. La elegencia y la belleza de un buen diseño hablan por sí mismas, pero no tuvieron propósito de estar ahí.

2. ¿Transmite un mensaje? Sí, pero es un mensaje puramente funcional en lugar de emocional. Casos excepcionales existen. Las estructuras correctamente usadas generan el sentimiento de orden y tranquilidad, mientras que el spaghetti code y un código mal escrito genera incomodidad interna. Pero el mensaje no va más allá de su propia función o propósito. Creo que en este caso deberemos responder que no.

2. a. ¿Puede ser efectivamente transmitido su mensaje? No. De la misma forma que ocurría con la literatura cuando nadie podía leer, es el caso que sufre el desarrollo de software al ser una disciplina muy específica. Sólo aquellos que estén entrenados y educados de la manera suficiente podrán apreciar la belleza o la aspereza de las buenas soluciones.

Conclusión

Me sorprendo a mí mismo ahora. Comencé a escribir este post imaginando argumentar que el desarrollo de software es un arte y dar buenas razones al respecto, y me contradije a mí mismo llegando a la respuesta opuesta. Aparentemente, no podremos declarar que el desarrollo de software sea un arte.

Sin embargo, para todos aquellos que me leen en este momento, comparto con ustedes la decepción de la conclusión: sé de las bellezas ocultas que esconde un buen software. Sé de la creatividad e ingeniosidad, la inspiración que transmiten soluciones simples y elegantes ante problemas complejos. Sé de la habilidad, casi intuitiva, que es necesaria para encontrar esas soluciones y esas oportunidades. Incluso ese hijo del desarrollo de software, la seguridad, es una disciplina con tanta variedad e intuición que parecería obvio que podríamos declararla arte. Sé que existen obras maestras en el mundo del software, y que existen bolas de barro que alguien tipeó en una noche de borrachera.

Por último, y como consolación, esto no quiere decir que no podamos utilizar el software como medio para generar arte.

Me recomendaron que me grabara para compartir la experiencia con otra gente. Lo probé y tras ver los videos, no me pareció tan mala idea.

Por tanto, voy a estar compartiendo mi experiencia de jugar a Mass Effect 3, uno de los juegos que actualmente ando disfrutando.

Sólo llevo unas tres horas jugadas y unos pocas misiones del mismo. Pueden ver los videos en mi canal de Youtube, pero para el interesado, aquí los puede encontrar.

¿El objetivo de estos videos? Principalmente, divertirme yo. Algo de comedia (aunque no soy gracioso), algo de crítica (aunque no soy muy detallista en la trama del juego), algo de drama (aunque no me mezclo mucho con los personajes). En fin, un intento de un poco de todo. Si a alguien le causa una sonrisa o algún feedback positivo, los videos habrán superado sus expectativas.

Por supuesto, acepto sugerencias de cómo mejorar mi experiencia con el juego.

Update 21/3/13:

Update 12/5/13:

Notarán más calidad en los videos a continuación — aprendí a codificar correctamente los videos para los requerimientos HD de Youtube. 720p, en este caso, porque 1080 generaba videos muy largos que luego tardaban eternidades en subirse, y me parecen aceptables de todos modos.

Haciendo ya mucho tiempo que no trabajaba en JavaScript sin la utilización de ningún framework, me propuse crear algo simple que a la vez fuera divertido. Pensé en algunas opciones y la ganadora fue un juego de Arkanoid (que, ahora me entero, es una de las tantas copias del Breakout, y para mi el nombre original siempre fue Arkanoid, en fin).

El resultado final lo pueden ver aquí y el código fuente está en mi repositorio de GitHub, pero no es tanto el resultado sino el viaje lo que fue interesante, y quiero describir las cosas que aprendí en ese camino.

Vengan y acompáñenme en mi viaje.

Documentación:

Como todo principante, o incluso como todo experto que cada tanto necesita verificar el estado de los estándares, la documentación de referencia es importante. Para hacer este pequeño proyecto me basé en algo de mi experiencia previa, y en la documentación disponible en los siguientes sitios:

• Mozilla Developer Network, impagable, la calidad de la documentación es increíble.
• WebPlatform.org, acabo de enterarme de este sitio por la clase de juegos HTML5 en Udacity, pero está también muy completa
• W3Schools para refrescar cosas básicas (“¿cómo eran los parámetros a array.slice?” y similares)

El contenedor:

(Lo que escribiré desde ahora se puede ver en el commit 90e6…4f7abd9.)

Lo primero y principal, y lo más simple fue setear el HTML y los estilos necesarios. Todo estará hecho en HTML5 Canvas y siendo manejado a través de JavaScript, nuestra estructura en el DOM en sí no debería ser demasiado compleja. Sí necesitamos, sin embargo, un documento válido y limpio.

Esto está claro: sólo tenemos un DOM HTML5, en donde asignamos un título, una referencia a un archivo CSS para que nos de los estilos a la página. Luego, por supuesto, la referencia a nuestro script, en donde se encontrará toda la lógica de la aplicación. Vamos a suponer por ahora que este archivo JavaScript expone un objeto llamado arkanoid, el cuál tiene un método llamado .init() al que podemos llamar. Eso lo hacemos, por supuesto, en el momento en que la página carga.

Ahora, los estilos no deben ser complejos tampoco. Todo lo que necesitamos es que en el cuerpo de la página exista un canvas y que este se vea como ocupando todo el espacio disponible. Por supuesto que esto significa poner los márgenes y los paddings a cero, pero lo que yo no sabía es que para evitar tener scrollbars o espaciados innecesarios, debemos indicar específicamente que el objeto canvas va a comportase como bloque, y que todo en la página carezca de espaciados. Esto lo aprendí de una respuesta de StackOverflow.

Para esto podemos usar muy apropiadamente el selector de CSS *, que matcheará absolutamente todo elemento. Este selector se llama Universal Selector y está disponble para los navegadores que soporten características de CSS3. Por supuesto, estamos trabajando en Canvas con lo que es muy factible que los navegadores que soportan el segundo también soporten el primero.

Nuestro CSS se ve, entonces, así:

El código

Para proceder a la parte de JavaScript, ya teníamos una limitación particular: debemos crear un objeto arkanoid que tenga la función init(). De una forma simplista entonces instanciaremos el objeto arkanoid asignándole un valor al objeto window, o podríamos haberla declarado de forma independiente. Para mayor seguridad, podemos devolver los resultados de una función auto-ejecutable, de forma que todas las variables que creemos sean locales y no estén manchando el namespace global.

Como también estaremos codificando lógica interna, seguramente querremos tener varias funciones y variables privadas. Nuestra función autoejecutable tiene solo que devolver entonces aquello que queramos hacer público, en nuestro caso, la función init().

Vayamos analizando ese código línea a línea:

• La línea 1 define el objeto arkanoid que necesitábamos. Lo define como el resultado de una función que será llamada, y tiene la capacidad de recibir parámetros que serán las opciones del usuario. Esto es, en caso en que quisiéramos pasar información al momento de inicializarlo.
• Las líneas 4 a 6 definen variables locales, solamente disponibles para este objeto arkanoid, que serán utilizadas por las demás funciones interiores. Estas no estarán disponibles a los objetos externos al momento de devolver el resultado, y más aún, tampoco se encontrarán disponible a elementos que hagan referencias a this o a self. Si eso los confunde, a mí también me ocurrió, checkeen esta pregunta en StackOverflow: JavaScript local scoping: var vs. this.
• Las líneas 8 a 13 definen otra variable local, pero esta será un objeto literal, para agrupar las posibles opciones con valores por defecto que tomaremos en caso en que el usuario (quien llama a esta función) no las provea.
• Las líneas 17 a 21 definen la función initOptions, que se encargará de identificar el conjunto de opciones válidas a utilizar, basado tanto en lo provisto por el usuario, los defaults, y la lógica interna. En este caso, obtendremos el override de lo que proveyó el usuario sobre lo default, y verificaremos que si estamos trabajando a pantalla completa (fullWidth y fullHeight), actualizaremos las variables de ancho y alto para que sean consistentes (stageWidth y stageHeight).
• Las líneas 23 a 28 hacen la magia de obtener el conjunto de opciones desde los defaults y con lo que el usuario proveyó. La lógica es tan simple como copiar todo lo que el usuario nos dio sobre el objeto de las opciones por default. Cabe destacar que aquí estamos escribiendo sobre el objeto de destino, por lo que si quisiéramos volver al valor por defecto, ya lo habríamos perdido. Una forma simple de haber hecho esto es, en lugar de llamarlo así:
  options = mergeObjects(defaultOptions, userOptions);
  Deberíamos llamarlo así:
  options = mergeObjects({}, defaultOptions); // creates a copy
  options = mergeObjects(options, userOptions); // overrides defaults
• Las líneas 30 a 39 inicializan el objeto canvas que se utilizará. Muy básicamente se obtiene el objeto body, se crea un objeto canvas y se le anexa, con el tamaño apropiado según las opciones. Para uso posterior, se almacenan las referencias al canvas y al contexto de dibujo 2D.
• Las líneas 41 a 46 realizan ese trabajo en sucesión llamando a las funciones apropiadas, e inicializa el stage sobre el que la magia ocurrirá.
• Por último, las líneas 49 a 51 devuelven el objeto exponiendo sólo la última función, y dándole el nombre de init.

Por ahora nos detendremos aquí y continuaremos en la parte dos. Mientras lo preparo, estoy dispuesto a responder preguntas, y seguramente las preguntas y los comentarios ayudarán a generar las partes posteriores.

Como parte del proceso de dejar el theme listo para publicar, estuve trabajando en el WordPress Theme Testing. El proceso es largo y detallado, y la documentación también, pero yo estoy trackeando mi progreso en este issue en Github. Una de las partes es lograr que los menúes de navegación sean configurables, y es algo que se cumplió hoy para Alpha’s Manifesto.

Cómo funcionaba antes

La implementación anterior recorría las categorías disponibles en el blog y las mostraba una por una, generando un slug desde el nombre de la categoría que usaba para generar un URL de una imagen. La carpeta misma del theme tenía varios de los iconos con esos mismos nombres, y un archivo .htaccess se usaba para devolver el icono por default de la carpeta vacía si es que el nombre de la categoría no existía como archivo.

En esta aproximación, el usuario no tenía que configurar nada excepto las categorías del blog y ya tenía el menu disponible. Existían varios problemas con esto que ahora fueron solucionados:

• El menú no se podía deshabilitar: no había una forma desde el theme por la que uno pudiera quitar el menú si no lo quisiera. Las opciones eran modificar el theme manualmente, o no tener ninguna categoría en el blog. Eso o romperlo a través de JavaScript para que no se viera. Ninguna de las opciones es totalmente recomendable.
• No se podían elegir qué imágenes uno quería más que agregando imágenes en la carpeta del theme. Tampoco recomendable, pero tenía cierto encanto, ya que el theme se encargaba de dar imágenes por defecto si estas no existían. Lo malo es que uno requería utilizar la conexión FTP directa al servidor (si la tenía) y estaba forzado a usar imágenes de él.
• No se podía elegir el orden de las categorías, sino que el theme las elegía por uno.
• Sólo se podían ver categorías en este menú, es decir que no se podían incluir ningún otro tipo de links. Ni a links externos ni a páginas (page).
• El .htacess debía ser distinto en la configuración de desarrollo y la de producción. Si bien esto no es un problema para el usuario común del theme, es un problema si uno lo quiere tener instalado en una versión local. Para alguien que lo use profesionalmente, para desarrollar con él, y para mi, para desarrollar sobre él. El problema de que RewriteBase tuviera que ser distinto según el servidor en donde lo tenía me generaba sospechas de que estaba haciendo algo mal.
• No se podía elegir qué categorías mostrar u ocultar, porque el theme automáticamente escaneaba todas para mostrarlas.

Con los cambios introducidos, esto se solucionó.

Cómo funciona hoy

Hoy se usa la característica de Menus expuesta por WordPress, en donde uno puede configurar menús personalizados y asignarlos a secciones que el theme soporte.

En la configuración actual, el theme dispone de una localización llamada Menu al pie, para el cual uno puede definir el menú a utilizar, de entre el listado de menúes particulares que uno haya generado en la sección de administración. Como extra, cada item debe actualizarse para que tenga incluida la imagen que se usará en la representación del menú. Esto es, simple y llanamente, la URL de esa imagen en particular.

El orden de los ítems se puede actualizar simplemente arrastrando los items hasta que tengan el orden deseado.

Cabe aclarar que por la forma del menú actual, no se permite una representación jerárquica de la navegación. Esto quiere decir que los ítems hijos, o los ítems de un nivel inferior no serán mostrados. Por el momento, esto es a drede, ya que no habría una forma s imple de mostrar esa relación. Entusiastas de diseño y UX, los invito a proveer sugerencias e ideas de cómo podría indicarse esto conservando el estilo poco intrusivo del menú.

Cómo se implementó

Si sos un desarrollador de WordPress o estás pensando en hacer un theme, esto puede ser muy valioso para vos, especialmente si tienes necesidades particulares de controlar el HTML generado para los items. (Y especialmente dado que parece no haber mucha documentación de cómo lograr esto.)

Según explica el Template File Checklist de WordPress Theme Development, la navegación debe implementarse a través de la función wp_nav_menu(). La utilización de dicha función es bastante simple si estamos en las siguientes situaciones:

• Generar el menú con listas sin ordenar es suficiente para nosotros (ul > li)
• El soporte a la anidación se hará también con listas sin ordenar (ul > li > ul > li)
• Queremos cambiar las clases o los IDs que recibe la lista sin ordenar (ul)
• Queremos agregar atributos propios a la lista (ul)
• Queremos que la lista se encuentre contenida en algún otro elemento del DOM

Todo lo anterior se puede lograr con distintos valores de los parámetros container, menu_class, menu_id, e items_wrap. Notesé que no existe forma de manipular el output de cada item de la lista, al menos no entre los parámetros. Para estos casos es en donde WordPress recomienda utilizar un walker, que es una herencia de la clase Walker_Nav_Menu.

Modificando la generación del menú

Walker_Nav_Menu es una clase que implementa la forma en la que se genera el HTML de la lista y de cada item interior. Podemos siempre extender la clase e incluirla en el scope de nuestro theme, e indicar que queremos usar esta clase en lugar de la clase default de WordPress.

Por ejemplo, este es el footer del theme de Alpha’s Manifesto. Vean cómo se indica la forma en la que se quiere utilizar un walker propio:

Y por supuesto, la implementación del mismo. Mucho del mismo no es más que una copia de Walker_Nav_Menu, localizado en el archivo /wp-includes/nav-menu-template.php. Sólo tienen que cambiar lo que quieren, y los métodos que no cambien pueden dejarse sin implementar.

Permitir al usuario agregar la información necesaria

Si miran con atención, habrán visto que en el snippet de código anterior estoy usando $item->image_url para la generación de la imagen del menú. Sin embargo, esta información no existe en la definición de los items, y mucho menos en la interfaz del usuario. Para esto es necesario registrar la información necesaria para que WordPress nos permita agregar esos datos. Esto fue difícil de lograr porque casi no existe documentación al respecto (o al menos yo no logré encontrarla).

El código en general lo pueden encontrar en el archivo custom_menu_setup.php del theme, pero pasaré a explicarlo por partes.

Como cualquier atributo extra que se agregue no se leerá o guardará para el item por defecto, podemos usar filtros y acciones que nos permitirán hacer esa operación cuando los items se lean o se guarden a la base de datos. De esta forma, extendemos WordPress para trabajar con esa información extra.

Tras poder guardar y leer esa información, falta una parte crucial: mostrar un lugar en la interfaz en donde el usuario pueda editarlo. Esto fue muy difícil de lograr, y me basé en algunas aproximaciones distintas:

En una respuesta de WordPress.SE, el usuario djrmom hace lo siguiente:

• Agrega los filtros y acciones necesarias para guardar / leer la propiedad nueva a los items (como hicimos más arriba)
• Registra un custom Walker para la edición de los menús
• En la implementación de este Walker, copia la generación del form original para agregar al final su propio campo

El usuario Cek (Frank) tomó un paso más y creó un plugin para WordPress que permite agregar campos custom, que utiliza casi la misma técnica para extender la funcionalidad de WordPress, con una diferencia: él no reescribe el código del Walker de WordPress, sino que utiliza phpQuery para que la clase base genere su HTML y él anexar al final del formulario su propios datos al formulario.

Si bien su aproximación me resultó muy interesante y simple, preferí no seguirla por dos razones:

1. No me agrada del todo la idea de un theme (el que estoy desarrollando) cargando phpQuery en memoria y usándolo sólo una fracción del tiempo.
2. La complejidad del Walker no desapareció, sólo ahora lo ejecuta otra clase y la nuestra le anexa algunas cosas

Por eso, preferí la aproximación general y reescribir el contenido del Walker de WordPress. En el códifo de Cek, se está extendiendo una clase llamada Walker_Nav_Menu_Edit, pero esta clase no se encuentra definida completamente en todos los ámbitos en donde el theme se ejecuta. Él incluye una condición para tratar con eso, pero yo sólo encontré problemas que rompían la administración de WordPress. Por eso, en este caso, también extendí Walker_Nav_Menu (Walker_Nav_Menu_Edit es una implementación de Walker_Nav_Menu y no agrega métodos propios) y lo registramos de otra forma, utilizando la función add_action con wp_edit_nav_menu_walker como primer parámetro.

El código general de esta clase lo pueden ver en custom_menu_setup.php del theme, pero la parte importante es la siguiente:

Aquí pueden ver lo que se hizo:

• Se copió código para generar un campo más, usando las mismas clases de WordPress para dar estilos
• Se generan cadenas únicas para la descripción de los campos y IDs
• El nombre del campo (name) es la propiedad que definimos a leer (ver variable $_POST en los ejemplos anteriores) y el índice de ese array es el ID del item (ver funciones de save/restore más arriba)

Con esto, ya nuestro campo está disponible para ser editado por el usuario.

Espero que esto les haya sido de ayuda.

Como buen fanático de la saga de Half Life, el primer día que Black Mesa estuvo disponible lo bajé y probé. No mucho tiempo después, lo había terminado. A continuación, mi opinión de esta visita nostálgica de la primera parte de esta épica saga.

Black Mesa es la re-edición de Half Life 1 por parte de un gupo de fans. Según lo que leí, este grupo de fans estaba haciendo un buen trabajo desde el comienzo y más tarde Valve mismo apoyaba el trabajo que ellos estaban hacendo. Black Mesa es totalmente gratis gracias a su esfuerzo y se encuentra disponible para cualquiera con una PC, en su sitio Black Mesa Source.

La historia en Black Mesa es, por tanto, la misma de Half Life 1, específicamente hasta que se crea el portal a Xen. Luego de eso la historia se detiene y muchos nos quedamos con las ganas de saltar al otro mundo (literalmente). El equipo dice que lo tendrán listo eventualmente pero no hay fechas ni promesas.

Lo más bonito de este juego, fuera de la nostalgia de revivir la historia, es la nueva calidad gráfica que permite el nuevo motor. Esto y los años de entrenamiento que los otros juegos de la saga nos han dado nos permiten revisitar esta parte con más atención a la sucesión de eventos, las pruebas lógicas y las batallas desafiantes (que, de hecho, me parecieron un poco más desafiantes que en el juego original).

Por alguna razón no me fue nada difícil en esta versión encontrar glitches. No sé cuánto de esto se deba al motor gráfico o cuanto al remake. Parecería incluso que la inteligencia de los NPC es la misma que la del juego viejo, haciendo las estrategias muy fáciles, pero la física es ciertamente de los nuevos juegos. Si quieren ver algunos screenshots de estos glitches, pueden ver los tres que encontré.

No hay mucho que pueda comentar sobre la historia o sobre la mecánica del juego, ya que toda pertenece a Half Life, en sus años de antaño. Si bien sigue siendo un muy buen juego, creo que gran parte de sus desafíos quedaron opacados por el tiempo, y Black Mesa no vino a cambiar eso.

En definitiva, es una linda forma de revivir el juego mientras todos esperamos la salida del famoso Half Life 3.

Le doy 3 zorrinitos de 5.