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

[Aldrin Martoq]

On Jul 15, 2010, at 4:59 PM, Franco Catrin L. wrote:
> El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió:
>> 
>> 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.

Sigo insistiendo que te estás enfocando en "protegernos" del mundo real... ¡las capas son para dar soluciones, no problemas!

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

Olvídate de los peros, que son excusas y para eso estamos nosotros. Si en cambio nos enfocamos en algún objetivo como: "proveer el procesamiento mas rápido de un arreglo" ahí los peros que me das desaparecen (indistintivamente del modo de acceso, eso es un problema particular de una implementación). Te olvidas del acceso de memoria, te olvidas incluso que hay CPU pues tenemos a alguien que hace muy bien este tipo de pegas que es la GPU.

Es decir, una posible respuesta sería utilizar la GPU la cual tiene buses mucho mas anchos, tienen hasta cientos de Cores que pueden procesar en paralelo, etc. De hecho, hay bibliotecas que hacen este tipo de soluciones hoy en día: el tarro donde escribo lo hace vía OpenCL y gracias a LLVM puede enviar trabajos tanto a la GPU como a la CPU.

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/14
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/15

Si el objetivo es otro ("proveer procesamiento de un arreglo, pero en tiempo real que no sobrepase X tiempo"), las soluciones son otras... y así.

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

Bueno, yo le pago al mecánico para que me deje andando el auto...

> Es la clásica confusión entre el que define los
> requerimientos y el que los tiene que satisfacer.

¡Epa! Una luz de encuentro. La pregunta era entonces: ¿debiera postgresql dar mas información en el error de memoria?


>> 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 no es para proteger (ni ocultar) los problemas del mundo real... si algo no está diseñado para manejar con lluvia (o su rendimiento degrada) no lo es y punto (y yo no salgo en moto cuando llueve). A esto me refiero con usar la herramienta adecuada.


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

Vamos, que la capa no resuelve los problemas del universo... 



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


Tengo sistemas andando que si algo falla indican qué estaban haciendo y deshacen correctamente lo que estaban haciendo [es algo poco común en informática, gente que lo ha visto se sorprende de lo bien que funciona esto]. Basta esto para que solucionemos "los problemas" que no resuelve la capa, eso es básicamente lo que pido.

No veo que cuadre con el ejemplo del mecánico, pues no le estoy pidiendo a la base de datos que me arregle el embrollo (algo así como código que detecte que el índice está corrupto y que lo regenere veo tu analogía)... Además que en la vida real los servicios técnicos tienen una etapa de inspección, sobre todo si mi requerimiento es "arrégleme el auto" en vez de "arrégleme la correa".


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