Read this article in English here
Hace unos días tuve la ocasión de compartir con algunos compañeros una conversación sobre controles de versiones, concretamente sobre git, su complejidad y la recomendación o no de su uso. Un argumento de peso en contra decía que git era una herramienta compleja, que tenía una curva de aprendizaje mayor que otras, que era muy sencillo equivocarte y que esa equivocación podría implicar una pérdida de datos.
Esto me hizo pensar, y si bien es cierto que git es una herramienta muy poderosa (con la que he tengo una relación de amor-odio desde hace varios años), el hecho de que una herramienta o lenguaje te permita ciertas libertades, no implica que estén pensadas para ser usadas siempre. Veamos un ejemplo en esta pregunta de Stack Overflow:
http://stackoverflow.com/questions/1488753/how-to-merge-two-branches-without-a-common-ancestor
A -- B -- ... -- K -- L -- M1
\
M3 -- N' -- .. -- Z'
/
I1 -- I2 -- M2 -- N -- .. -- Z
En este caso son 2 ramas sin padre común, lo cual es un caso un tanto atípico según mi (corta) experiencia. Es malo git por permitir esta operación? No, debemos usarlo como patrón de ramas habitual? Tampoco. De hecho la mayoría de patrones de gestión de ramas se basan en tener una rama /main lo más sólida posible, y tener las características, usuarios o tareas en ramas separadas.
Otro comando con el que contamos es rebase que nos permite reescribir la historia de una rama, e integrar los cambios de otra, lo cual puede parecer una auténtica atrocidad para aquellos que consideren que un changeset es una foto inamovible.
Git no es el único, ya que tenemos otras herramientas y lenguajes de programación, que por diseño nos han permitido hacer ciertas cosas que se han ido de las manos:
PHP
El lenguaje que permite que sitios como Facebook, Yahoo, o Youtube no ha estado exento de polémica en los 18 años que lleva prestando servicio (desde nada más y nada menos que 1995). Buscando peculiaridades del lenguaje, descubrí que, entre otras cosas, PHP nos permite definir variables globales desde dentro de una función como muestra el siguiente bloque de código:
function foo () {
global $var;
// rest of code
}
Esto rompe con todas las reglas de encapsulación, y de alcance de las variables de una función que se estudian habitualmente, y desde luego, está duramente criticado su uso, Es PHP un mal lenguaje por implementar esta funcionalidad? No, es posible que encontremos un caso de uso específico para esta funcionalidad, y de ahí que el lenguaje nos de el soporte para la misma.
C
El padre, abuelo y antepasado común de muchos de los lenguajes de programación de hoy en día, y cuyo libro de cabecera contiene poco menos de 300 páginas (El famoso K & R), lleva recibiendo críticas desde 1972. Una de las funcionalidades más criticadas es, sin duda, la función goto:
int big_function()
{
int ret_val = [success];
if([error])
{
ret_val = [error];
goto end;
}
if([error])
{
ret_val = [error];
goto end;
}
end:
return ret_val;
}
Goto nos permite realizar un salto incondicional a una porción del fichero. Los detractores a goto opinan que rompe el flujo de ejecución de un programa y que puede ser una fuente de errores, además de que dificulta la legibilidad. Por otra parte, es útil en escenarios secundarios, como la eliminación de la recursividad.
Conclusiones
De igual manera que no debemos usar la misma herramienta para todo (antipatrón del martillo) debemos ser conscientes de las peculiaridades de los lenguajes, y en que lo que se nos aporta, se aporta con una razón en concreto, no necesariamente para aplicarlo a todos los escenarios.
Recordemos al Tío Ben cuando estemos desarrollando o usando una herramienta:
Un gran poder conlleva una gran responsabilidad
Y tú, qué peculiaridades de estos (u otros) lenguajes te parece que han sufrido abuso por parte de los desarrolladores?
rlbisbe @ dev 