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

[Aldrin Martoq]

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). 

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.


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.




> 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!

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...


Aldrin Martoq
http://aldrin.martoq.cl/