Las cosas que odio de PHP

Antes que nada, esta entrada es una reseña de algunos los detalles de PHP que me molestan en el día a día. La gravedad o molestia generada de cada punto expuesto queda a obvia apreciación personal de cada programador.

No es objetivo de esta entrada reducir el debate a PHP vs [OTRO LENGUAJE], sino hablar puntualmente de PHP y sus defectos, independientemente de los que puedan presentar otros lenguajes / plataformas (que gustosamente podemos discutir).

No a la globalización

Al ser un lenguaje converso , PHP arrastra ciertas prácticas y costumbres tribales. Tomemos por ejemplo las funciones globales, la documentación oficial al día de la fecha* acusa la existencia de aproximadamente 5912 funciones accesibles globalmente (sí, cinco mil novecientas doce funciones), censo que podemos dividir demograficamente (por letra inicial) de la siguiente manera:

*No necesariamente accesibles sin la instalación de los módulos correspondientes.

a	124
b	53
c	342
d	300
e	78
f	208
g	243
h	519
i	872
j	20
k	19
l	73
m	502
n	306
o	296
p	529
q	9
r	141
s	872
t	44
u	46
v	53
w	47
x	133
y	40
z	43

Sin duda alguna, tenemos una superpoblación de funciones globales.

Es la coherencia, imbécil!*

En cualquier aspecto de la vida la coherencia es algo cuya importancia no se puede negar. Consideremos como el cenit del sentido común, que situaciones similares resulten en acciones similares. Cuando esto no se cumple nos vemos obligados a recordar las reglas, sino también las excepciones lo cual termina impactando tanto en la performance como en la paciencia del desarrollador.

*Origen de la frase: “It’s the economy, stupid”.

Nombres de funciones (semantica y convención)

Como regla general, todo lenguaje o comunidad define una convención de sintaxis para el código. En Java, por ejemplo, se utiliza la notación camelCase para la nomenclatura de métodos y variables, Ruby por otro lado, utiliza camelCase para la nomenclatura de clases y módulos y snake_case para los métodos y variables.

PHP en cambio, utiliza todas, los siguientes usos de funciones NATIVAS del lenguaje son casos válidos:

// snake_case
html_entity_decode('');

// Desaparencen los underscores
htmlentities('');

// E inclusive podemos escribirlo asi
htmlEntities('');

Por otro lado, algunos nombres de funciones son bastante pobres semanticamente hablando, imaginen que un programador de un lenguaje X se encuentra con las siguientes funciones, debiendo entender que hace cada una de ellas por el nombre:

// Duplica el string?
strstr(...);

// decode o encode?
htmlentities(...);

// Mein fuhrer!
strrchr(...);

Inconsistencia de nomenclatura de funciones y variables (case sensitive)

De la mano de lo anterior, encontramos que los nombres de las variables son case sensitive, no así las funciones. Lo mismo aplica a métodos y propiedades de objetos, donde toma un papel de mayor protagonismo:

class Foo {
	public function bar() {
		return 1;
	}
	public $baz = 1;
}

$f = new Foo;

// Properties
$f->baz; // 1
$f->Baz; // Notice: Undefined property: Foo::$Baz 

// Methods
$f->bar(); // 1
$f->Bar(); // 1
$f->bAr(); // 1

Inconsistencia en argumentos de funciones de strings y arrays

Teniendo funciones y métodos que hacen cosas similares, es de esperar que el input que reciban sea coherente entre ellos. Un caso concreto que se da en PHP es con las funciones de búsqueda de arrays y strings En los métodos de búsqueda en strings, se recibe el haystack primero y luego el needle, y viceversa en los métodos de búsqueda de los arrays:

strpos( string $haystack, mixed $needle )
stristr( string $haystack, mixed $needle )

in_array( mixed $needle, array $haystack )
array_search( mixed $needle, array $haystack )

Inconsistencia en la visibilidad de funciones globales y variables globales

Después de un tiempo de desarrollar con otros lenguajes (especialmente JavaScript, siendo que comparten ciertas reglas de scoping), me genera curiosidad la lógica de la visibilidad de variables y funciones. ¿Por qué las funciones globales son accesibles en cualquier scope y no así las variables?*

*No vale responder con el use globals.

Y como si esto fuera poco, tenemos las superglobals, que básicamente son variables pero se comportan como las funciones globales, siendo accesibles en cualquier scope.

Las pequeñas cosas de cada día

Este listado agrupa las cosas que si bien no considero críticas, me hacen pensar sobre la benevolencia de los cráneos detrás de PHP ¿Realmente nos quieren? ¿O disfrutan viendónos sufrir? En lo personal me inclino por lo segundo.

Object dereferencing

Si bien esta característica existe para expresiones del tipo:

// Accedemos a un metodo del objeto devuelto
get_an_object()->my_method();

Acceder a los métodos de la expresión resultante de una instanciación no es posible:

class Foo {
	public function bar() {}
}
// Cualquiera de las dos sintaxis genera un
// Parse error
new Foo()->bar();
(new Foo())->bar();

Siendo necesario hacer lo siguiente:

// Paso 1: instanciar
$instance = new Foo();

// Paso 2: acceder
$instance->bar();

// Paso 3: liberar el objeto al garbage collector (se puede usar el unset)
$instance = null;

Array dereferencing

Esto es, acceder a un índice de un array devuelto por una función:

// Parse error
get_an_array()[0]

Al igual que el ejemplo anterior, necesitamos asignarlo a una variable para luego accederlo.

Por suerte, esto será posible con la release de PHP 5.4.

Operador ternario

Increíblemente y a diferencia de cuanto lenguaje conozca, el operador ternario no puede ser anidado:

$instance = true ? 'one' :
     false ? 'another'
        : 'default';

echo $instance; // 'another'

Gracias a su anormal asociatividad, es necesario desambigüar con paréntesis las expresiones anidadas, lo cual convierte al operador ternario en una bomba de tiempo:

$instance = true ? 'one' :
     (false ? 'another'
        : 'default');

echo $instance; // 'one'

En lo personal me parece excesivamente limitante, obligando a usar estructuras más verboses (if else anidados o switch). Un caso de uso posible (en este caso es JS):

// Syntax sugar > verbose
var animal =
    isCat() ? new Cat :
    isDog() ? new Dog :
    isBird() ? new Bird :
    isCodeMonkey() ? new CodeMonkey :
    new Alien;

Operador OR ( || )

Siendo un lenguaje tan flexible con los operadores lógicos y los tipos de datos, es absurdo que el resultado de la siguiente expresión sea 1:

null || 'default' // 1;

Cual es el problema? Que impide lograr construcciones más concisas, como puede ser el valor por defecto de una variable, siempre que no resulte un falsy value, asignar el valor por defecto:

// Forma deseada
$myVar = get_value() || 'default'; // 1

// Realidad
$myVar = get_value();

// Evaluamos si es un falsy value (en algunos caso deberiamos usar el isset tambien)
if(!$myVar) {
	$myVar = 'default';
}

O inclusive realizar asignaciones por descarte, mediante el anidamiento del operador ||:

// Forma deseada
$myVar = get_value() || get_selected() || get_from_session() || 'default';

La comunidad

Sin duda alguna, el punto más pólemico. Como programador, tengo la impresión de que la peor de las consecuencias de la amigable curva de aprendizaje* que tiene PHP es la proliferación de desarrolladores y proyectos de paupérrimo nivel. Inclusive podemos agregar como caracteristica la defensa irracional del lenguaje, resultando imposible para los “desarrolladores” en cuestión sostener un debate serio sobre el tema.
Gente que no entiende la programación como un proceso complejo dificilmente progrese como profesional… y PHP está lleno de ellos.

*Y atención que la curva de aprendizaje no es tan amigable como se suele decir.

En estos casos, hay que entender, que al faltarle al lenguaje herramientas y por sobre todas las cosas, convenciones que lleven al programador por correcto camino, terminan delegando dicha responsabilidad en la disciplina del mismo. Situación que lleva a que el gran programador sobrelleve las falencias del lenguaje llegando a un gran resultado y a que el resto termine desarrollando desastres que serán sufridos por posteriores generaciones de desarrolladores, testers y usuarios.

Para dejarlo más claro, esto no implica que TODOS ni la mayoría los desarrolladores sean un desastre ni que TODOS ni la mayoría los proyectos lo sean, pero la tasa de situaciones problemáticas es más evidente que en otros lenguajes.

Leer más:


Shortlink: http://goo.gl/tsa0X




23 views shared on this article. Join in...

  1. ASP Rulz! dice:

    Obviamente es una mierda lo que dices, tan obvio como claro.

    Solo quieres parecer un sin vergüenza con experiencia, la cual no tienes.

    Quejarse es tan fácil como aventar la piedra y esconder la mano, si tanto apesta PHP no hables de el.

    Usa Ruby o Python, hasta JAVA es mejor que tu.

    Que pena me das.

  2. A mi me parece que es más facil no criticar. Me gustaría que fundamentes un poco lo de la experiencia o sobre porque es malo criticar.

    Esconder la mano sería hacer una crítica de forma anonima, o sin fundamentos. Unicamente expuse cosas concretas que me molestan del lenguaje. Sos libre de discutir cualqueira de los puntos de la entrada.

    Saludos y espero tu respuesta.

    PD: Ad hominem.

  3. Pato. dice:

    Dejé de leer cuando te quejaste de los nombres de las funciones, media pila. El thread de 3dg tiene fundamentos muchos más coherentes que los que exponés.

    Salute Valen.

    • Si eso no es un problema para vos bienvenido sea. Lo cual no me extraña de alguien que nombra una variable como ‘$pepe’ 😀

      • Pato. dice:

        Y no, si nombrás variables $wakaka dentro de un Framework Empresarial. (O seteás protecciones +18 con un simple style=”display:none”).

        • Mmm, no aplica. Lo mio era una chicana, no un argumento.

          Si pensas que uno o mas puntos no son validos, espero tus argumentos.

          • Pato. dice:

            Descalificar un lenguaje por el nombre de sus funciones no me parece algo coherente, teniendo tantas otras falencias GROSAS; me suena a “ay no, php malo, no me gusta, no me gusta, noooo”. En el link de 3dg. hay argumentos mucho más convincentes que los que vos exponés aca.
            Es como que diga que Pascal es una mierda porque en vez de usar llaves usás ‘begin’ y ‘end’ en los condicionales.

            Lejos estoy de ser un “gurú” del PHP como vos aparentás serlo, simplemente expongo mi -humilde- parecer.

            Ta Lue.

          • Yo no me queje de la sintaxis (como ser el begin y el end en Pascal), si asi lo hiciese hubieses leido sobre la incomodidad del operador -> entre otras cosas, pero de nuevo, la sintaxis no es el punto de la entrada. Luego, tu argumento es falaz.

            No pensas que la falta de consistencia en los nombres de las funciones es un problema? tanto lo de los underscores como los nombres abreviados? Y los demás puntos? O no estar de acuerdo con uno invalida el resto? Imaginate si los nombres de las functions fuesen f00001, f00002, … fn,

            Y finalmente, en que parte de la entrada dije que PHP es una mierda? De hecho la misma ilustra mi punto de vista (cosa que se hace más evidente cuando lees el titulo).

            PD: Si querés aportar con las falencias GROSAS, las podemos agregar, en lo personal las que están escritas son las que molestan.

            PD2: Si fuese gurú en (o supiese más de) PHP me quejaría de más cosas, como pasa con JavaScript.

  4. ASP Rulz! dice:

    Empezando por comparar cierto lenguaje con otro ya está viciado, eso no permite ver con claridad. Punto.

  5. Carlos dice:

    Concuerdo en que PHP en manos equivocadas puede llegar a ser como ver una vieja ochentona en cueros… Y como va Javascript…? ¬¬

    Todo es relativo diria Einstein. 😀

    • JavaScript puede llegar a ser terrible. Y peor aún, ya que (entre otras cosas) hay mas programadores casuales que en PHP, ya que no es raro ver programadores Java, COBOL o cualquier otro lenguaje trabajando con JS sin tener demasiada idea (lo cual tiene consecuencias bastante lógicas).

      Peeeeero, una cosa no quita la otra, y la realidad es que si la gente de PHP no tuviese la obligación(?) de arrastrar malas decisiones del pasado podrían cambiar el hecho de que el lenguaje apeste en muchos aspectos.

  6. Dn P. P. Nador dice:

    $myVar = ( get_value() || ‘default’ ); // esto regresa un booleano (true o false) no 1 ni 0
    —————————————————————————————
    $instance = true ? ‘one’ : false ? ‘another’ : ‘default’;

    Si devuelve ‘another’ es debido a que primero evalua <> dejando la segunda evaluación como <>, y ‘one’ (por castin) es evaluado a true. por eso son necesarios los paréntesis. 🙂

  7. Dn P. P. Nador dice:

    $instance = true ? ‘one’ : false ? ‘another’ : ‘default’;

    Si devuelve ‘another’ es debido a que primero evalua { true ? ‘one’ : false } dejando la segunda evaluación como { ‘one’ ? ‘another’ : ‘default’ }, y ‘one’ (por castin) es evaluado a true. por eso son necesarios los paréntesis. 🙂

    • jorge dice:

      Hola, déjeme acompañarlo agregando además, que estos “programadores” que se quejan de la inconsistencia (¿?) de php, son los mismos que buscan un framework para hacer cualquier cosa en otros lenguajes que si tratan de consistente. Y lo que es peor, la mayoría del tiempo usan pseudolenguajes en lugar del lenguaje en si
      ¿Casos?
      Ruby, etc…
      ¿y que es un programador que solo usa frameworks para trabajar? Pues no es un programador, solo un usuario. Y puedo decir que he despedido a muchos así

      • erm3nda dice:

        Si aprendes de primeras a programar con un framework tiene las ventajas de que tu código cumple ciertas reglas y buenas prácticas “automáticamente” , además de MVC en la mayoría de casos. Pero no será tu código, no serás tú el que conoce las buenas prácticas y cuando algo se salga del framework te vas a cagar de lo lindo.

        Lo más correcto es primero chuparse todos los tutoriales “a pata” para saber lo que se está haciendo, y luego, casi obligado, aprender a usar un framework para ir como el rayo en las cosas más triviales. Después de todo en un framework siempre te puedes saltar cosas y hacerlas a pata, quiera el framework o no. (Cuando digo framework, digo framework+IDE o sencillamente un buen framework si te gusta el notepad 😉 )

  8. Cascara dice:

    Esta bien criticar y para criticar hay que comparar. He leído muchas respuestas estúpidas aquí. Y desde mi punto de vista sus opiniones me dicen que son gente que no salen de su zona de confort. Yo puedo programar en el lenguaje que me pongan enfrente, me vale un cacahuate la sintaxis. Muchos dicen que el lado de la luz es el suyo, yo digo que el lado de la luz es lo que lo que te deja una gratificación emocional y material. Atte. un arquitecto de soluciones, no un simple programador.

  9. jorge dice:

    Existen 10 tipos de lenguajes de programación:
    El tipo del que todo el mundo se queja
    Y los del tipo que nadie usa

  10. Zerhy dice:

    Muy de acuerdo con el post, muchos inexpertos aquí consideran la inconsistencia como algo que no tiene importancia, pero puedo asegurar que quienes crean tal cosa no conocen otra cosa distinta a PHP. Otros entornos como Ruby On Rails, Java, .NET entre otros manejan algo llamado “reglas de estilo”, por la misma razón posteada aquí.

    Ejemplo:

    En Java los paquetes no pueden contener mayúsculas, las clases deben empezar por mayúsculas, y las propiedades o métodos deben empezar por minúsculas?

    Cuál es la utilidad? decenas, pero mencionare la mas evidente

    micosa1.micosa2.Micosa3.miCosa4

    Cuál es la utilidad de esto? claramente sabemos que miCosa4 no es una clase, ni un paquete ni nada por el estilo, puede ser un metodo o propiedad que ha sido invocado, Micosa3 deja expresado que es una clase, micosa2 y micosa1 evidentemente son paquetes. Para que ayuda esto?

    otracosa1.otracosa2.otracosa

    Que es otracosa3? es una clase? un metodo? una propiedad? no se sabe. Volviendo al tema de PHP, lo que convierte el código PHP en un código tan desorganizado y tan poco homogéneo no es esto, es que una clase puede ser tanto:

    “otracosa”, como tambien, “otraCosa”, como también “OtraCosa”, como también “Otra_Cosa”, como tambien “Otracosa” o cualquier otro estilo que al programador PHP se le ocurra en el momento.

    A la hora de trabajar con codigo de este tipo (el 90% del codigo en PHP es asi) dar mantenimiento a Apps, sitios webs o cualquier otra cosa se convierte en una tremenda pesadilla. Lamentablemente como se ha mencionado en el post, estos temas (solo mencione 1) por lo general no son abordados por los desarrolladores de PHP, les molesta hacer un simple analisis que los hiera, pareciera que se han casado con el lenguaje y estan negados a aprender algo más.

  11. Zerhy dice:

    Valentin Starck, este post no es para que lo postees, se que esta entrada es vieja, pero de igual forma ahi esta, se que hay unos cuantos errores (en cuanto a formateo html) en mi post, si crees prudente podrias corregirlos, se que sabes cuales son. Saludos 🙂

  12. tanito dice:

    Loco me salvastes las papas con el put@ operador ternario! No podía encontrar el error. 😉

  13. luis dice:

    la web esta echa en php

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Comment

You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>