Capas de abstracción (fue Re: Postgresql que se muere)

[Franco Catrin L.]

El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió:
> On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote:
> > El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió:
> >> On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote:
> >>> Mi mirada al documento es respecto a cómo las abstracciones pueden jugar
> >>> en contra cuando no sabes qué está pasando realmente por debajo, algo
> >>> que queda claro al leer los comentarios en este thread.
> >>> Un buen ejemplo que da el autor es cuando recorres una estructura de
> >>> datos y perfectamente el programador puede recorrerla de una forma que
> >>> el rendimiento se degrade.
> >>> Las "abstracciones que gotean" no son un error, son un hecho.  
> >> No, eso se llama usar la herramienta adecuada. Si estas usando un software para lo que no está hecho, obvio que te vas a topar con cosas para las cuales no estaba preparado.
> > No entiendo la relación?  Leíste el artículo completo?
> >> Si volvemos al tema original, el error de postgresql es algo que no espero de una base de datos (bueno, en realidad puede fallar pero el mensaje te deja de manos cruzadas). Y eso independiente de cómo este hecho por debajo.
> 
> Las capas de abstracción no son para "protegernos" de los errores, son para *solucionar un problema*. Esto implica que son buenas para cierto ámbito (no para todas) pues están diseñadas para hacer tal o cual cosa. Y deben hacerlo bien.
> 
> En tu ejemplo del artículo, supongamos que es una biblioteca que le paso una lista y tiene una operación que hace algo con ella (por ejemplo, ordenarla). Siguiendo el ejemplo, tenemos un caso en que tiene la operación tiene muy mal rendimiento (por cómo está construida la biblioteca "justo la mala suerte").

> La postura del artículo es que la biblioteca nos protege o facilita de lo complicado que es el "mundo real" (el problema de ordenar una lista), por eso a veces te toca bailar con la fea. Pero si cuando construimos la biblioteca, lo que se pidió era resolver el problema de "ordenar una lista de manera rápida", entonces el problema es otro: se ignoró dicho requisito (puede ser ambas partes: quien usa la biblioteca como quien la construye, o ambos). 


El ejemplo va por otro lado.

Como programadores asumimos que la memoria es lineal y cada "celda"
tiene el mismo costo de acceso.  Esa es la abstracción.

La realidad es que la memoria puede estar fragmentada y además tienes
sistemas de caché intermedios, por lo que no existe un costo de acceso
igual para todos los casos.

Cómo una biblioteca te puede proteger de eso si como programador
necesitas por ejemplo un array bidimensional que vas a procesar por
filas y por columnas indistintamente?

> Es como si llevas el auto a un mecánico y te comienza a chamullar con miles de dramas (no, que ahora tuve este problema, no que ahora se quemó no se que cosa)... puras excusas, pues le pagas al mecánico para resolver tal problema. Si el mecánico no puede preveer este tipo de dramas, está dando un pésimo servicio; hay veces en que esto sucede, pero lo que debe pasar es que el te advierte antes. Algo similar sería que la biblioteca del ejemplo nunca fue declarada performante. De ahí el "herramienta adecuada", ¿ves? Por el otro lado, si la biblioteca sí fue declarada como performante, esto es un bug... nada de andar chamullando con "leaky abstractions" o lo complicado que es la vida.

En ese caso, si le pagas al mecánico por resolver un problema puntual,
lo puede hacer perfectamente, otra cosa muy distinta es querer que te
deje el auto andando.  Es la clásica confusión entre el que define los
requerimientos y el que los tiene que satisfacer.

> Hay millones de ejemplos en la vida real: ir al mecánico, que un doctor te opere de la vesícula, cuando haces un trámite en el banco... Que algo del mundo real falle no es excusa para dar un mal servicio, es lo mismo con una capa de software.

Qué me dices del ejemplo en donde los sistemas de seguridad de un auto
no ocultan la diferencia entre manejar con o sin lluvia?

La capa de software o los servicios siempre tienen un límite en donde no
pueden resolver los problemas por si mismos.  Es ahí donde salta la
excepción.

Que estén o no declarados esos límites es otro problema muy distinto, y
al final la "elegancia" con que se resuelven algunos casos puede ser
inútil en la práctica, aumentando el costo para el 99% de los casos sólo
por el 1% de los casos (o menos).

En mi opinión la perfección tiene un costo que tiende a infinito.

> > Por qué no? Es una situación de excepción, al igual que cuando el
> > cliente te avisa que no se puede conectar a la base de datos.
> > Si te fijas, el error dice que no pudo obtener la memoria que necesitaba
> > para realizar la operación, algo que siempre puede suceder.  En este
> > caso es claro que no se justifica y el motor se confundió al estimar el
> > tamaño, pero en el normal de los casos sí debería retornar una excepción
> > cuando no puede hacer lo qué le estás pidiendo.
> > ERROR:  invalid memory alloc request size 1818585462
> > Puesto de otra forma, qué hubieras esperado que te informara el servidor
> > si no hay suficiente memoria para realizar la operación?  Datos
> > inventados?
> 
> 
> Es todo lo contrario: nosotros estamos inventando (como tu bien dices) qué fue lo que paso. En cambio, postgresql (o nuestra "capa de abstracción") está en la fuente del error... tiene toda la información a mano que puede perfectamente desplegar; el ejemplo claro es que si es el campo de un índice cuyo tamaño se fue a las pailas, podría dar el nombre del desdichado. ¡Si para eso le pago al mecánico!

Para postgresql esa petición de memoria tiene sentido, bajo la lógica en
que está programada la versión de esta víctima en particular.  Según
posgresql sí se requiere tal cantidad de memoria para resolver el
problema y no tiene cómo darse cuenta (en esa versión) de que el cálculo
es incorrecto.

Siguiendo tu ejemplo del mecánico, es como si le llevaras un auto con la
correa de distribución mala y con un cortocircuito en el sistema de
encendido, y le pidieras que te arregle el auto.  Con la información que
dispone lo más probable es que sólo vea el problema en la correa, hasta
cuando la arregle y se de cuenta de que había un problem adicional.

(No sé si el ejemplo está bueno, soy nulo en mecánica pero espero que se
entienda la idea).

Hasta a House le aparecen casos con causas combinadas :D

> Y de hecho, una vez que comienzas a ver mas seguido estaría mas claro el siguiente problema: por qué se corrompen los índices y/o cómo evitarlo...

Ese es el problema de fondo.

-- 
Franco Catrin L. http://www.tuxpan.com/fcatrin
TUXPAN Software S.A.