El síndrome MacGyver

Hoy toca reciclar un viejo artículo de un aún más antiguo sitio que ya no mantengo… Corregido y extendido el contenido, mejorada (y acidificada…) la redacción y cambiados algunos enlaces.


El ser humano es un animal extraño. Tan rápido como se queja de un exceso de opciones en un programa al instante siguiente estalla en improperios porque la opción que necesita (generalmente, algo que solo ese usuario particular podría alguna vez querer utilizar) no está presente en el primer nivel del menú contextual.

Y es que el Usuario siempre lo quiere Todo, pero al mismo tiempo exige el poder manejar ese Todo con una sola mano (o incluso un solo dedo): un programa que no abrume con opciones, pero que tenga bien visibles las que se necesitan en ese momento; un programa que sea fácil de usar aún sin leer el manual, pero que pueda realizar tareas complejas en forma eficiente; un programa que no requiera planificación por parte del usuario, pero que nos de resultados «profesionales» sin esfuerzo… y que además nos sirva café y de ser posible nos haga masajes en los pies.

A esta triste tendencia de exigir algo que siendo simple y elegante nos proporcione absolutamente todo lo que necesitamos y más aún, sin importar lo alocado que esto sea, lo más rápidamente posible y sin necesidad de perder tiempo aprendiendo cómo funciona, le podríamos dar el nombre de «síndrome MacGyver» o de «la navaja del ejercito suizo»: se me ocurre algo disparatado, saco la navaja y sin trabajar demasiado en un momento está listo y funcionando.

Ejemplo de este síndrome sería el querer que un procesador de textos pueda editar documentos PDF, o que sea capaz de realizar dibujos complejos (que después de todo, escribir escribe cualquiera), o que haga todo tipo de cálculos a partir de la fórmula que recién escribimos con el editor de ecuaciones (que además tendría que ser intuitivo, nada de códigos extraños para memorizar o de complicados menús), o…

Si bien es un concepto en apariencia interesante, este síndrome tiene la potencialidad de arrastrarnos hacia absurdos como el de la siguiente imagen (un producto real que alguna vez apareció en comercio):

El objeto es hasta agradable a la vista, pero en el afán de querer tener «todo en un único lugar» ¿cómo se hace para cortar la carne sin sostenerla?, ¿cómo hacemos para comer las legumbres sin ensuciarnos con la sopa que tomamos en la entrada?, ¿cómo logramos sostener el engendro sin cortarnos con el cuchillo?

El tratar de martillar en un mismo lugar cosas buenas pero completamente diferentes no necesariamente nos dará algo que es bueno para todo: muy probablemente nos de algo que es malo para todo.

Si bien existen extensiones para LibO/AOO que permiten cosas como insertar ecuaciones LaTeX o notación musical a través de LilyPond, creo que cada tarea debe realizarse con la aplicación apropiada en lugar de mezclar todo en un único lugar. Si bien han existido intentos de extensiones que «leen» las fórmulas escritas con Math en un documento Writer para luego realizar operaciones de todo tipo, incluso de álgebra simbólica, me parece mucho más sensato utilizar MAXIMA u Octave directamente y luego copiar y pegar los resultados.

Al máximo, si tenemos que utilizar estos objetos extraños solo esporádicamente nadie se va a enfermar por tener que construir una imagen (preferentemente, SVG o PDF) en el programa específico para luego insertarla en nuestro documento.

Y es que trabajar con tanto agregado nos daría rápidamente documentos llenos de objetos que harían más lento el programa, menos estable, el formato sería más difícil de administrar… en fin, que la «solución» agregaría más problemas que los que teníamos en un principio.

Un ejemplo de integración fallida: aunque muchos no lo sepan, en el todopoderoso LaTeX es posible crear gráficos escribiendo código directamente dentro del documento… pero a menos que solo nos interese una línea horizontal, el código necesario es tan complejo y largo que el documento resultante se volvería rápidamente ilegible e inmanejable. Y después de todo, ¿para qué entrar en semejantes complicaciones si insertar una imagen es algo tan simple?

Algún músico versado en cuestiones informáticas podría protestar y decir que LyX ofrece un módulo para incluir elementos de LilyPond el cual funciona realmente muy bien, demostrando que este tipo de integración parece funcionar. Bueno, puede ser, pero solo en este caso y por buenas razones: LilyPond y LaTeX tienen mucho en común por lo que no es extraño que funcionen bien juntos.

Y claro, que LyX permita utilizar LilyPond no significa que el primero sea capaz de dar herramientas que ayuden a trabajar con el segundo: dentro del recuadro que nos ofrece LyX, estamos a solas con LilyPond y sus crípticos comandos.

Por otra parte, este tipo de integración con un documento Writer nunca funcionará bien: como ya he comentado en cierto libro, todo objeto «extraño» que se inserta en un documento odt cae dentro de un marco y los marcos nada saben de quiebres de página. Es decir, para agregar estos objetos tendremos que separar el contenido a insertar manualmente y en forma cuidadosa, teniendo en cuenta en qué parte de la página caerán… y por si fuera poco, Writer no es lo más cómodo de utilizar cuando se tiene un gran número de marcos saltando de una página a otra cada vez que agregamos una línea de texto antes de ellos.

Usar la herramienta justa para el trabajo siempre nos ahorrará dolores de cabeza. Si Math no es suficiente (y es fácil que no lo sea), pues es momento de pensar en abandonar Writer y utilizar el magnífico LyX como interfaz de LaTeX/XeTeX. Si necesitamos crear una partitura musical es mejor considerar una herramienta específica como puede ser LilyPond (para valientes) o el fantástico Musescore. Si queremos un diagrama complejo en nuestro documento qué mejor que insertar una perfecta imagen SVG generada en Inkscape.

Ahora bien, es necesario admitir que esta eficiente separación de tareas también puede traer sus inconvenientes en ciertos casos particulares. Por ejemplo, siguiendo con la música, ¿qué hacer si necesitamos un libro donde se intercalan páginas de texto (detalladas biografía de autores) con páginas de partituras (las composiciones de esos autores)? ¿Se justificaría allí el llenar a Writer de extensiones para que haga todo más o menos bien en lugar de tratar de coordinar varias herramientas que hagan las cosas perfectamente pero por separado?

No.

Writer puede exportar magníficos archivos PDF. Musescore puede exportar magníficos archivos PDF.

El último paso sería encontrar una herramienta que nos permita unir esos archivos PDF convenientemente. Pero esa herramienta existe: pdftk es una librería que ofrece herramientas de línea de comando para trabajar con documentos PDF, cortándolos, uniéndolos… lo que se necesite, mientras que pdftk-qgui es una simple interfaz gráfica para esa librería.

Y como dijimos más arriba, usar LilyPond dentro de LaTeX es posible… para los que saben utilizar LilyPond, se entiende.

En resumen: planear bien el trabajo, realizar cada una de sus partes con la herramienta apropiada y luego reunir todo al final quizás no parezca tan emocionante como la aventuras del polifacético MacGyver, pero suele dar los mejores resultados.

Anuncios

,

  1. #1 por xiseme el 22 septiembre, 2014 - 0:34

    Cuanta razón en que somos extrañamente complicados :escribir con hojas de cálculo, calcular en procesadores de texto …
    ¡En vez de perseverar en aquello de aplicaciones que “hacen una cosa y la hacen bien” + interoperabilidad entre ellas!

    Mira si somos complicados que yo discrepo del título que le has puesto (XD) prefería el de «La herramienta justa-adecuada»

    Para mí -subrayo lo de para mí, que bien que veía la serie- MacGyver se caracterizaba por el ingenio al aprovechar recursos escasos (al estilo de calcular -aprox.- la altura de un árbol con una cuerda y una cartulina sin necesitar un smartphone con app para ello)

    Los partidarios de «todo en uno» que al final lo convierten en «totum revolutum» son la antítesis y una supra-aplicación no puede ser como MacGyver porque carece de ingenio -aún- y este tendría que ser aportado por su utilizador, que si lo tiene ya no necesitará tal herramienta.
    Seguramente además será como la navaja-suiza: atornilla poco, corta poco, sierra mal, … lo único que hace perfectamente bien es abrir las botellas de cerveza, que se abren fácilmente sin herramientas XDDDD

    • #2 por elpinguinotolkiano el 22 septiembre, 2014 - 18:18

      😄 Pues aceptada la crítica. Yo lo pensé por el lado de «una aplicación» (la navaja) que «lo resuelve todo rápidamente y sin esfuerzo». Pero es verdad, la característica principal de MacGyver era ser ingenioso, y tanto lo era que muchas veces se las ingeniaba para violar las leyes de la naturaleza (como cuando detiene una pérdida de ácido usando barras de chocolate) 😉

      Saludos

  2. #3 por karlggest el 29 septiembre, 2014 - 16:14

    Hola. Habéis olvidado el chicle de McGyver, muy mal xdd MacGyver podría haber sido la mascota de Unix en tiempos, pero no sé si nadie lo pensó o si era cuestión de derechos y demás xdd El héroe, con frecuencia, usaba herramientas sencillas que combinaba de forma “inteligente” para hacer algo muy diferente a su propósito original y potente. Y muchas veces aprovechando efectos secundarios o colaterales de algunas de esas herramientas. ¿Os suena?

    Aunque en Unix, la herramienta que se usa más habitualmente con un propósito más diferente de su objetivo es touch 😉

    Bien, hai un curioso concepto, “suite”, que tiene que ver precisamente con la interoperabilidad de diversas aplicaciones en torno a un proyecto común. Así, si necesitas una tabla de datos, la importas de una base de datos, luego manipulas esos datos en una hoja de cálculo y muestras los resultados en tu procesador de texto (o de documentos, o de páginas, etc.). Eso era opuesto a tener programas aislados para hacer la misma tarea o incluso para hacerlo con una sola aplicación.

    La relación de las aplicaciones de una suite puede establecerse de distintas formas y tienen diferentes inconvenientes. La más simple es la capacidad de vincular o copiar contenido de otra aplicación. Es la más simple, por supuesto. Otra forma mejor es la capacidad de crear un contenedor en el que metes un fichero de otra aplicación, directamente. En GNOME antes eso lo hacía BONOBO y en KDE puede hacerse pero no tengo la menor idea de cómo. En esto hablo del soporte del escritorio para hacerlo, no del soporte de aplicaciones para compartir información, como podéis adivinar 😄 Por ejemplo, LibreOffice lo hace con Ole 2…

    Supongo que además de la competencia, un gran factor para el incremento de complejidad de muchas aplicaciones es la disponibilidad cada vez mayor de grupos de widgets cada vez más potentes… así que ¿por qué no añadir tal o cual característica? claro que podría aducirse que el tiempo de añadir características superfluas debería dedicarse a añadir cosas importantes, pero bueno, todos somos humanos xdd

    Salud!!

    • #4 por elpinguinotolkiano el 29 septiembre, 2014 - 23:07

      Había olvidado el chicle de MacGyver 😄

      Sobre los contenedores, en KDE se llaman kpart. De hecho, tanto kate como kwrite son solo dos frentes gráficos diferentes para el mismo «kpart» de procesamiento de texto. Lo mismo pasa al abrir una terminal en Dolphin y otras cosas por el estilo. El ejemplo más extremo es el pobre konqueror (que anda en búsqueda de quien lo mantenga). Pero el concepto de varios contenedores en una aplicación no es lo mismo que una aplicación que lo haga todo, ya que con contenedores seguimos teniendo varias aplicaciones independientes que hacen «solo una (o pocas) cosas y la hacen bien».

      Saludos

A %d blogueros les gusta esto: