Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

Códigos e Invocadores

–El Gran Poder de Reutilizar tus Propias Rutinas–

Hace poco veía una obra muy extraña que mezclaba argumentos del estilo del Código Da Vinci, acción de juego de cartas geek y un diseño de personajes que recordaba mucho a los de los primeros juegos de wrpg de 32 bits cuando de pronto me pasó por la mente la solución a un viejo problema de desarrollo que de seguro le ha pasado a todo programador alguna vez sin importar en que lenguaje programe: Desarrollos eternos que no llegan a ninguna parte.

disco de invocaciones

Un programador de computadoras bien organizado no es muy diferente a un invocador de fuerzas sobrenaturales como los que aparecen en los juegos tanto de rol como de video. La fuerza a invocar en este caso no son demonios, seres elementales o los cuerpos reanimados de los enemigos vencidos. En el caso del programador tales entidades a invocar son las subrutinas. Cada que se ve en la necesidad de llevar a cabo una acción un programador llama a una de sus confiables subrutinas para hacer que se cumpla su voluntad. Además de eso, un programador cuenta con habilidades y tácticas propias que si bien no son código ejecutable pueden redefinir el resultado de un encuentro, o en este caso la buena ejecución de un programa.

Como ya lo he comentado en esta web, la parte mas fea de esto de programar es que uno no puede escapar de la cultura corporativa del “bet your company” que para quien no sabe es cuando un proyecto puede tomar meses o hasta años de trabajo intenso antes de que llegue a un nivel en que sea redituable. A lo largo de la historia de la computación, diversos grupos han intentado cambiar este modelo de negocios para que los proyectos de programación produzcan ganancias de manera constante como sucede en la mayoría de los ambientes industriales. Como en mi caso personal esto de la programación es una actividad demasiado barata (en el sentido financiero) no me he visto en ese problema. Lo que me pasa casi de manera irremediable es que algunos proyectos me toman tanto tiempo y se vuelven tan confusos en el aspecto de investigación (término que tengo que explicar en otra entrada) que casi siempre acabo olvidando lo que estoy haciendo y me pongo a hacer otra cosa. Pero si logro implementar este sistema de manera eficiente puede que los proyectos sean mucho pero mucho mas fluidos.

No se porqué pero mientras escribía el párrafo anterior como que me dieron ganas de jugar el viejo Clash at Demonhead de NES. Bueno, el problema a eliminar es ese del bet your company o por lo menos mejorar la forma de trabajo para hacerlo mas dinámico y emocionante. Hasta ahora he notado que crear un software consta de tres actividades principales que a primera vista no parecen tener nada que ver entre si: Leer mucho, teclear miles de lineas y buscar errores. Podría agregar la parte de tratar de resolver problemas pero eso viene incluido en la parte de reparar bugs y leer. Si uno simplemente se lanza a escribir código invariablemente va a llegar a un punto donde el programa no va a funcionar y no tendrá idea de que hacer para remediarlo. Luego va a entrar en un círculo vicioso en el que busque errores y documentos para resolverlo hasta que se aburra o el proyecto sea cancelado. Ahora veamos el simil del programador con el del aventurero invocador.

Explorador, Cazador y Domador de Entidades Virtuales

Un invocador, buscador de tesoros, recolector de almas o en este caso un programador siempre comienza su aventura con unos pocos conocimientos básicos y en casos afortunados información sobre la existencia y localización aproximada de aquello que busca. Estos invocadores exploran mundos extraños y desconocidos enfrentándose a todo tipo de peligros empezando por el peor de todos que es la amenaza constante de perderse o quedarse sin provisiones. Cuando estos buscadores de tesoros al fin llegan al lugar donde aguarda su premio es cuando realmente comienza la acción. Pues todos sabemos (algunos por mala experiencia personal) que todos los tesoros no solo son difíciles de conseguir sino que invariablemente tienen dueño o están fuertemente custodiados. Aquí es donde se dan las batallas en las que hay que usar toda la fuerza e ingenio para vencer al enemigo y hacerse con el tesoro. Aunque también puede darse el caso de que el premio y el enemigo a vencer sean el mismo. Pues recordemos que somos invocadores y no simplemente héroes que destruyen monstruos que otros pueblerinos débiles no son capaces de enfrentar ellos mismos. Esto es lo mas común. Pues es necesario hacerle frente al monstruo/demonio/elemental/algoritmo para demostrarle quien manda. Una vez terminada la batalla, el invocador agrega una nueva presa a su colección que no solo se ve bien en su sala de trofeos sino a la que puede invocar cuando se encuentre en problemas en alguna aventura posterior. Desde luego, no basta con ir juntando entidades como si se tratase de cartas coleccionables. Es necesario aprender a dominarlas para que cumplan nuestras órdenes y ocasionalmente tener pequeños enfrentamientos con estas cuando intentan escapar o rebelarse en nuestra contra. Con el tiempo el invocador no solo aprende nuevas habilidades que lo hacen mas fuerte, sino que su colección de entidades va conformando un ejército cada vez mas poderoso con el que puede librar batallas contra enemigos mas dificiles.

Las tres actividades del programador tienen correspondencia directa con las aventuras de los invocadores. Comienzan con una idea de lo que quieren hacer y una idea de donde comenzar su búsqueda. Comienzan a leer libros rarísimos que de inicio no entienden y buscan en internet información sobre lo que quieren hacer durante semanas con el peligro constante de perder el rumbo o que les alcance el deadline. Cuando el programador al fin localiza la información que busca es cuando en verdad comienzan los problemas, pues tiene que hacer grandes esfuerzos mentales para comprender lo que está leyendo y a veces regresar por donde vino para encontrar mas información. A veces incluso tiene que recurrir a tácticas tan controversiales como la ingeriería inversa o el espionaje para lograr su cometido que es convertir esa información en un bloque de instrucciones que puede integrar a sus propios programas y lo mas importante, invocar estas subrutinas cuando quiera. Con el tiempo el progamador va formando un compendio de subrutinas que puede llamar desde los nuevos programas y mientras mas de estas tenga y mejor las entienda mas capacidad tendrá de crear software mas avanzado y confiable (no me gusta ese término de ‘robusto’) en tiempos y costos rentables. Aunque las mas de las veces tenga que buscar errores en estas mismas subrutinas cuando estas no hagan lo que el programador supone que deben de hacer.

Dejemos las metáforas a un lado por un momento. La idea es que los programadores no pueden empezar desde cero cada vez que van a hacer un programa a menos que se trate de sus primeras experiencias con una determinada tecnología ni tampoco pueden dar por terminado un programa sin llevarse nada mas que la experiencia para aplicar en otros desarrollos. Un programador inteligente sabe separar la investigación de la codificación. O debería decir separar la exploración de la batalla. Conforme el programador avanza va creando rutinas y cuando llega el momento de programar lo único que debe de hacer es averiguar cuales de estas rutinas necesita y simplemente copiarlas y pegarlas en el nuevo código. Si las rutinas están bien hechas no harán falta muchos cambios para hacer que funcionen. El proceso de invocar una de estas subrutinas e integrarla al nuevo código es un proceso que no debería de tomar mas que unos pocos minutos y el armado de un programa a partir de estas rutinas no debería de tomas mas de una semana. De nuevo si las rutinas están bien hechas o mejor aun si contamos con rutinas de depuración en nuestro libro de invocaciones un solo programador puede acabar solo un proyecto grande en menos de un mes con todo y la depuración y pruebas de fiabilidad incluidas. Esto desde luego si el programador no tiene la necesidad de crear nuevas rutinas durante el desarrollo.

¿Y tú ya comenzaste a escribir tu libro de invocaciones?

El error de muchos programadores es subestimar el valor de la reutilización de su propio código y creer que para programar proyectos grandes solo necesitan de sus conocimientos y experiencia. Si bien van a necesitar de esta, si no tienen una buena cantidad de código reusable que puedan usar de manera inmediata su avance será muy lento o nulo. El desarrollo de software es exponencial y la capacidad de hacer código sofisticado depende directamente del código que en un momento dado un programador puede disponer. Por otro lado, yo recomendaría que mantuvieran bien separado el uso de rutinas reutilizables de la creacion de nuevas rutinas. Crear nuevas rutinas es la parte verdaderamente dificil pues involucra leer muchos libros y resolver problemas de lógica muy avanzada. Ambas cosas toman demasiado tiempo y son demasiado arriesgadas como para ser consideradas como trabajo normal. Mi consejo es que dejen la creación de subrutinas para tiempos mas calmados y a la hora de proyectos ‘serios’ solo limítense a usar lo que ya tienen. Ahora que si se ven en la necesidad de crear nuevas rutinas para sacar adelante un trabajo urgente, entonces tengan por seguro que habrá problemas.

Ya para terminar solo me queda definir un sistema para tener a la mano todas esas rutinas, así como todas las unidades de información necesarias para crear un programa complejo. Había pensado en crear un sistema similar a una wiki que permitiera guardar y recuperar piezas de código de la manera mas rápida y limpia posible y de ser posible compartir este mismo sistema con los lectores de esta web interesados en la programación en ensamblador. Hacer una sencilla aplicación basada en web no es demasiado complicado e integrarla a este mismo blog u hospedarla en un servidor independiente traería muchos mas beneficios que lo que costaría implementarla. Por supuesto no esperen que el sistema completo esté a disposición en el corto o mediano plazo. Ya en un futuro cuando el sistema albergara unas cuantas cientas de subrutinas será cuando realmente sea de utilidad para otros programadores. Ese humilde sistemita será mi libro de invocaciones personal, y a cualquier programador sin importar su nivel de experiencia le recomiendo que haga el suyo propio. Esas cosas son tremendamente útiles. Ahora mejor me pongo a programar porque el momento en que voy a necesitar invocar a tales entidades ya llegó y si no hago algo no voy a salir de esta sin daños. En momentos como este, uno se da cuenta de que por muchas subrutinas que pueda invocar siempre parece que nunca tiene las que necesita.

Anuncios

junio 6, 2011 - Posted by | Uncategorized | , ,

7 comentarios »

  1. Bueno, después de leer este post me quedo pensando. Se supone que la esperanza de vida en México es de alrededor de los 70. Además he sabido (por conocimiento de la gente común) que la edad más productiva del hombre es de 30-50 anios. Hace poco estuve viendo algunos de los vídeos de librerías que Google ofrece como código abierto. Incluso un montón de funciones para hacer física por computadora para videojuegos. La pregunta es… debo utilizar esas funciones e ir directo a la programación del juego, arte e historia? O debo hacer mis propias funciones que eventualmente serán casi tan buenas como las de Google? (Google tiene in arsenal de testers) . Estoy en este dilema. Y la otra pregunta es… me alcanzara la vida para implementar código de funciones para manejar sonido, reconocer patrones de voz, reconocer caras, comandos con las manos, física 3d, animación, y Lo nuevo… videojuegos con tecnología 3d… he ahí la cuestión. O debo llamar esas funciones de código abierto tan bien documentadas?… quizá ensamblador será un lenguaje que se utilice para hacer compiladores para los procesadores que van saliendo. Muy bien pagado claro,

    Comentario por puerco | junio 7, 2011 | Responder

  2. Pero se requerirán muy pocos, y preferentemente, genius-iq. O quizá, sí avanza la ia Lo suficiente no se necesiten más programadores para el anio 2045 como máximo. espero vivir eso.

    Comentario por puerco | junio 7, 2011 | Responder

    • Pues si consideras que las funciones ya hechas son suficiente puedes usarlas. Usa tus propias funciones solo cuando las disponibles no hagan lo que tu quieres. Ahora que no creas que porque algo ya esta ahi va a ser facil de usar. He sabido de casos en los que aun con tecnologia licenciada los que pagan por ella son incapaces de usarla. Al fin que por muy nivel maquina que uno programe siempre tiene que conocer y llamar las funciones mas basicas del firmware y sistema operativo mas basicas por motivos de compatibilidad.

      Comentario por asm86 | junio 8, 2011 | Responder

  3. Hola.. no se si tiene que ver con lo que estan discutiendo pero.. Mario, que piensas del asm “ARM”, que piensas de este procesador y sus instruciones? =)

    Comentario por Pavon | junio 10, 2011 | Responder

    • El ARM es una excelente arquitectura de CPU RISC. Hace mucho programe un sistema coreano llamado GP32 muy parecido al viejo Game Boy Advance. Tenia un ARM 9 de Samsung. Hoy versiones mas avanzadas se usan en smartphones y dispositivos moviles como tablets, deberia de hablar sobre esta tecnologia al menos de manera superficial.

      Comentario por asm86 | junio 12, 2011 | Responder

      • ahora hasta el windows 8 va a soportar este procesador.. y la mayoria de los dispositivos moviles los usan.. como por ejemplo el nuevo PlayStation Vita.. imaginen los juegos para play echos en assembly.. interesante serian.. =)

        Comentario por Pavon | junio 13, 2011

      • Mas interesante seria ver gente que programara esos sistemas usando el ensamblador del ARM. Aunque eso normalmente ocurre cuando los sistemas van de salida y la competencia es ya muy fuerte. De inicio no esperes otra cosa que ports de otros sistemas mas antiguos y una enorme cantidad de eso que ahora llaman juegos casuales

        Comentario por asm86 | junio 13, 2011


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: