Recién agregué a mi página de Frases citables una que, como otras varias allí, proviene de una compilación de las Leyes de Murphy. Dice lo siguiente:
No dibujes lo que puedas copiar.
No copies lo que puedas calcar.
No calques lo que puedas cortar y pegar
Tras colocarla allí, consideré pertinente hacer una breve aclaración (esta que nos ocupa) para que dicha cita no sea tomada como una invitación a la mera copia sin recato (eso ya lo hace muy bien el sistema educativo mexicano), ni como una invitación a entregarse a la total falta de creatividad (insisto). Nada de eso.
Esta frase la tomo como una invitación, a mí mismo y a otros que puedan sentirse identificados, a valorar de manera más cuidadosa el costo-beneficio de ciertas actividades que debemos emprender como parte de alguna tarea de mayor alcance y que podemos sentirnos tentados a realizar por las piedritas, es decir, por el camino largo y tortuoso.
Como un ejemplo particular, consideremos que nos ocupa la elaboración de un programa de cómputo que busca resolver cierto problema, por ejemplo, obtener un modelo de regresión múltiple, digamos, utilizando R. La elección del software ya implica de inicio una decisión importante, porque existen varios programas comerciales que realizan dicha tarea sin necesidad de que tecleemos un solo comando; pero supongamos que por algún motivo resulta importante crear las rutinas para el ajuste del modelo y no solamente ser capaz de ajustarlo dados los datos.
Se requiere (simplificando mucho la descripción del problema) de generar rutinas que permitan:
- Elaborar gráficas de los datos originales y derivados
- Calcular el valor de los estimadores de mínimos cuadrados
- Obtener estimaciones por intervalo y contrastes de hipótesis para los parámetros y para la verificación de los supuestos del modelo
Entonces surgen las cuestiones a decidir:
- ¿Es necesario programar todas las operaciones requeridas, incluyendo la inversión de matrices, o se puede hacer uso de las rutinas que provee el paquete?
- Por el contrario, ¿se debe hacer uso de dichas rutinas para dedicar tiempo y esfuerzo a otras actividades que también es necesario realizar?
- Yendo más lejos, si quisiéramos decidirnos por escribir hasta la última línea de código, ¿también vamos a prescindir de las rutinas de graficación de R?
- Si con anterioridad se ha resuelto un problema similar, ¿sería aconsejable echar mano de las rutinas elaboradas previamente, realizando las modificaciones pertinentes, directamente copiando partes que atienden situaciones específicas o de plano haciendo uso de ellas en forma de caja negra?
- ¿Cómo se cosigue, mediar entre el deseo de controlar todo el proceso y la necesidad práctica de tener una solución adecuada dentro de un tiempo razonable?
Es ahí en donde me parece que la mencionada frase tiene una utilidad importante, precisamente aquella de recordarnos que un pragmatismo moderado nos puede conducir a un mejor aprovechamiento de tiempo y recursos en la consecución de un objetivo.
La programación modular y después la programación orientada a objetos surgieron, justamente, como una respuesta a las dificultades generadas por la elaboración poco estructurada de código en las tareas de actualización y mantenimiento de proyectos extensos, y una práctica muy recomendada es la de la reutilización de código.
Por tanto, es esto a lo que me refiero con la cita mencionada, y espero recordarla para aplicarla siempre sienta inquietud por implementar una rutina en R que sea más eficiente para calcular la descomposición en valores singulares de una matriz 
(principalmente porque no hace falta).
. Después pondremos más.
