e-ferro Venturas/Desventuras de "informatico"

Según más van pasando los años y con la experiencia, más claro me queda que normalmente las dificultades de cualquier sistema (normalmente de de objetos) están en lo que podríamos llamar "Los límites" , bien del sistema o bien por lo menos de la parte de objetos.

Me explico, los objetos permiten "jugar" a ser Dios creando un "universo" en el que existen objetos que simplemente cumpliendo ciertas reglas (normalmente mínimas) pueden vivir en el y hacer que todo el universo en conjunto evolucione simplemente por la interacción entre los objetos. Esto tiene grandes ventajas, puesto que puedes cambiar las "reglas de juego" del universo y de sus habitantes, pudiendo facilmente ampliarlo, reducirlo, modificarlo, etc... 

Hasta ahora todo son ventajas. Evidentemente esto no es del todo cierto, puesto que este "universo" vive en un entorno limitado con sus reglas (S.O), sus lenguajes (programación), sus bases de datos, su arranque, las caidas de tensión, etc. Estos puntos podemos identificarlos como los límites externos de nuestro sistema y típicamente son:

• El Sistema Operativo
• El hardware (diferencia memoria / disco duro, volatilidad del universo, comunicaciones, etc)
• Los lenguajes que normalmente no permiten expresar más que un conjunto limitado de cosas (especialmente los estáticos)
• Incluso los propios desarrolladores / usuarios y sobre todo su deformación / condicionamiento por lenguajes estáticos, conocimientos de bajo nivel (bytes, memoria, ...). Ficheros, Registros... Bases de Datos. Incluso condicionamiento para trabajar con metaforas como la del escritorio, los formularios, etc. Que hacen que pensemos en Archivos, Bases de Datos, Ficheros, Registros...
  
• ...

Esto hace que se tienda a dedicar demasiado tiempo a solucionar problemas relacionados con estos límites, cuando en muchos de los casos estos problemas no existen realmente sino que nos los creamos nosotros mismos al tomar ciertas decisiones técnicas. Por ejemplo:

• Mapear obejtos a BD Relacionales, para almacenar datos que en la mayor parte de los casos son menos de un decimo de la memoria de cualquier ordenador.
• Representar cualquier información en una tabla, puesto que estamos condicionados a pensar en que la información siempre tiene está estructura... o en un árbol en algunos casos. Normalmente este tipo de diseño de interfaz de usuario es porque no somos capaces de diseñar un interfaz adecuado a la tarea a realizar.
• Optimización temprana del sistema puesto que estamos condicionados por una experiencia y una educación que hablaba demasiado de "bytes" y poco del comportamiento y evolución de la información.

Creo que la solución general a este problema, es simplemente pasar de evaluar esos problemas y no plantearselos excepto que sea totalmente imprescindible y en ese caso retrasar la decisión todo lo posible. Esto se resume en:

• Usar lenguajes que sean ampliables (por tener metaprogramación, introspección, ser open source, etc...)
• Abstraerse en lo posible del S.O. usando sistemas interpretados, multiplataforma, etc
  
• Evitar meter objetos en BD Relacionales, lo que permite:
• No dedicar recursos en intentar meter cosas en forma de circulos en agujeros que son cuadrados
• No pelearse con sistemas de mapeo que ni permiten pensar en objetos, ni pensar en relacional, sino que obligan a tener que pensar en las dos cosas y además en todo el mapeo, es decir el triple de trabajo.
  
• Evita terminar pensando en registros (por comodidad)
• Mejora el rendimiento de una forma asombrosa, puesto que no tienes que convertir una y otra vez de un formato a otro, ni implementar complicadas politicas de cache y de bloqueo
• Intentar que el sistema sea "Vivo" en el sentido de que se difumine en todo lo posible la fase de desarrollo / ejecución.

Al final resulta que normalmente y simplemente por inercia pasamos la mayor parte de nuestro tiempo y esfuerzo resolviendo problemas que nada tienen que ver con el problema "lógico" a resolver, es decir nuestro tiempo se pasa con el interfaz de usuario, mapeo de objetos a relacional, resolviendo problemas que nos genera el propio lenguaje de desarrollo que usamos, etc...

Con respecto a esto es interesante estudiar los conceptos:

• Object-Relational_impedance_mismatch
• Object_prevalence
• Metaprogramming
• Language_Oriented_Programming
• Domain_Specific_Language

En cualquier caso y una vez sabiendo estos problemas típicos y conociendo los conceptos listados en el punto anterior, hay siempre que tener mucho cuidado con la tendencia natural que tenemos los infomáticos (simplemente por el hecho de serlos) hacia la MentalMasturbation Así que por muy divertido que sea  hacer un programa C++ que en compilación crea la mayor parte del programa, que interpreta un lenguaje inventado por nosotros debemos evitarlo sea como sea.

Etiquetas: Rayadas