Esta es una lista de programadores que cambiaron la historia de la tecnología, quizá de la humanidad, o por lo menos su área de influencia poderosamente. Baste decir que por programador hablo de aquella persona que además de dominar algoritmos y estructuras de datos para crear una solución computacional, fueron capaces de dominar las herramientas para llevar esa solución a la práctica, lo que resultó, directa o indirectamente, en un hito técnico y social.

No encontrarás en esta lista ganadores de concursos de la ACM, ni grandes nombres como Turing, Dijkstra o Minsky. Esta lista tampoco es un Top 10, ni exhaustiva porque faltan muchos y muy venerables como Cerf, Kahn, Gilmore, Cray o leyendas modernas como Matsumoto, Heinemeier y _why. En fin, quiero ofrecerles esta lista como un recordatorio de que los programadores han transformado nuestras vidas profundamente la últimas décadas. Y que lo seguirán haciendo.

Programar es, según la RAE, elaborar programas para la resolución de problemas mediante ordenadores. Donde programas son una serie de instrucciones debidamente elaboradas para dicho ordenador. Visto de otra manera, el programador escribe un mensaje, el código fuente, que el ordenador recibe, entiende y ejecuta luego de una serie de traducciones. Así se establece un tipo muy especial de interacción hombre-máquina, que comienza en la mente del programador y termina en los registros del CPU.

La programación es ciencia y arte. Por un lado, como programadores, tenemos que hacernos de una buena colección de algoritmos y estructuras de datos para resolver problemas con cierta eficiencia. Aquí está la ciencia. Por el otro lado, debemos adquirir el oficio de programar con alguna herramienta, que va desde el lenguaje de programación hasta el entorno de desarrollo, sin mencionar técnicas de ingeniería de software para gestionar proyectos complejos y donde las preferencias-obsesiones personales entran en juego, incluso podemos hablar de estilos de programación. Aquí está el arte. Un programador experimentado sabe equilibrar esas dos fuerzas.

El algoritmo de Dios es un término que surgió en la búsqueda de aquel algoritmo que indicara los pasos mínimos que resuelven un cubo de Rubik cualquiera. El término se usa profusamente, no sólo para el cubo de Rubik.

Mucho antes de conocer dicho término, cuando me encontraba con diversos tipos de problemas, ya me asaltaba recurrentemente una pregunta irrelevante (para el caso que me ocupaba), pero que espero te haga pensar un poco en la importancia de algunas cuestiones que quizás no conoces:

“¿Qué solución daría Dios si fuera él quien resolviera el problema?”

Lo más sorprendente quizás, es que “las soluciones de Dios” no sólo no están vedadas al intelecto humano, sino que son numerosas y prolíficas. Veamosló.

Durante el periodo formativo una de las prácticas que más me llamó la atención es la realización de exámenes de programación en papel. Si hay una característica que hace de la programación algo muy dinámico es la posibilidad de no tener que implementar el algoritmo de arriba a abajo.

Sin embargo, el planteamiento que hay que realizar cuando se pretende implementar un algoritmo en un papel es diferente porque la escritura debe ser secuencial. La persona evaluada debe conocer perfectamente todas las líneas de código, variables o funciones que se emplearán antes de empezar a escribir el código, ya que una vez escritas las líneas no es posible insertar líneas en medio. Este planteamiento es diferente al modo de trabajo real ya que las variables y líneas se van añadiendo conforme se necesitan sin que haya un orden de escritura concreto.

Inconvenientes del papel

Existe un pequeño truco que es dejar bastante espacio entre líneas por si acaso hubiese que escribir algo en medio, pero siempre se tendrá el riesgo de necesitar escribir más líneas que el hueco que hemos dejado.

Otro de los motivos de reivindicar la realización de los exámenes de programación en ordenador en lugar del papel, es que para programar no necesariamente el programador debe acordarse de declarar todas las variables, verificar cierres de bloques, asegurarse que los nombres estén bien, etc. El IDE ya realiza esas tareas automáticamente y te recuerda si tienes errores en el código porque has obviado alguna de esta información.

Finalmente, me pongo en el lugar del profesor cuando este tiene que revisar más de cien exámenes. En líneas generales supongo que comprobarán que la estructura de los bloques for, while o if se adecua al problema propuesto. Por ejemplo, si nos piden recorrer una matriz de 10×10, si el profesor no ve dos for anidados ya tiene pintas de estar mal, sin entrar a comprobar el detalle … ¡Mentira!

para (n=0;n < 100;n++){
      matriz[n div 10][n mod 10]=0;
}

El hacer algoritmos en papel, en mis tiempos de estudiante, me ha llevado algún problema que otro teniendo que llevar el profesor al ordenador para demostrarle que dim a(1 to 100) as integer era también un vector de enteros cuando este tan solo conocía dim a() as integer. Ojo. Esto no es un problema del profesor. Simplemente hay tantas formas de escribir algo, que no se puede tener un conocimiento completo de una materia cuando el profesor intenta estar a la última. Precisamente ese año estaba experimentando con nosotros la renovación de su asignatura a Visual Basic 3.

Realizar los exámenes de programación en ordenador

Una propuesta interesante e innovadora sería permitir realizar los exámenes de programación aprovechando las ventajas que te da el propio ordenador. Por una parte, el alumno que esté acostumbrado a programar se sentirá más a gusto al estar en contacto con el entorno. Este entorno le verificará la sintaxis, le permitirá añadir cuantas líneas desee entre líneas, declarar y borrar las variables que desee, etc.

Pero la parte más interesante es que el propio alumno podría compilar el programa, e incluso, si el profesor se lo curra, tener unos test automáticos que te puedan decir la nota que vas a sacar incluso antes de acabar el examen. Esto haría que el alumno supiese si va a aprobar o suspender y dejar de lado el factor sorpresa por despistes. Además, ahorraría enormemente tiempo al profesor evitando tener que repasar cientos de exámenes. Tan solo, cuando el alumno vaya a salir, el profesor anotaría la nota que dan los test automáticos y listo.

Inconvenientes de los exámenes en ordenador

Sin embargo, los exámenes en ordenador también tienen alguna pega. Uno de los motivos de utilizar papel es precisamente porque las aulas de informática no permiten abarcar tantos alumnos a la vez. Esto provocaría tener que realizar turnos y exámenes diferentes para que todos los alumnos pudiesen examinarse.

También hay que vigilar que no se permita la comunicación entre ordenadores, ya que en tal caso, nos podríamos topar con exámenes copiados enviados por la Intranet o por Internet. Habría que desconectar los ordenadores al iniciar el examen y volverlos a conectar al finalizar.

Por último, un último inconveniente es la revisión de la estructura. Que una aplicación funcione no significa que sea correcta según la metodología de la programación. Imprimir 10 Hola mundos se puede hacer en 3 líneas o en 10. Seguro que la segunda forma, recibirá un suspenso aunque el programa cumpla su objetivo.

Por supuesto, utilizar ordenador o papel debe quedar a decisión del docente que es en gran medida quién debe saber que es lo mejor para su asignatura y de que medios dispone.

La industria del videojuego está llena de ejemplos de este tipo y algunos los conocemos todos. Dos compañías, de intereses bastante diferenciados, deciden unir fuerzas para asumir un objetivo comercial común y repartirse dividendos. Cada una aporta una serie de cosas de las que la otra carece y se consigue montar una especie de relación y de equilibrio de fuerzas que acaba con la repartición de dividendos… si la cosa sale bien. Si no sale, una de las dos acaba abandonando el barco y las dos, por separado, intentan reutilizar la tecnología desarrollada para otros productos.

Una de las míticas asociaciones tuvo lugar entre Nintendo y Sony justo cuando Nintendo preparaba una especie de lector de CD para la Súper Nintendo. Al final la cosa no acabó de cuajar y se rompió la sociedad dejando a Sony con una multimillonaria inversión y con tecnología desarrollada que acabaría dando nacimiento a la PlayStation. Mal no les fue y aunque la historia tiene muchísimos matices (algunos sostienen que la tecnología que utilizó era en realidad de Nintendo y no de la propia Sony) no evitó que años más tarde la compañía de la gran N se lanzase a por otro proyecto compartido. Esta vez con Nokia y mientras preparaba la consola portátil sucesora de la popular línea GameBoy.

Nintendo trabaja muchas veces en paralelo. Sus grupos de ingenieros desarrollan mil y una propuestas que la cúpula directiva se encarga de aceptar, rechazar o modificar considerando el público al que quieren dirigirse. De los muchos proyectos que mantienen a la vez sólo uno conseguirá llegar a la línea de meta y los demás se perderán por el camino aportando, eso sí, un valioso aprendizaje.

A principios del año 2000 Nintendo empezaba a ver que su consola portátil más popular, y la que mejor resultados económicos aportaba a la compañía teniendo en cuenta el descalabro de la consola de sobremesa, daba señales de agotamiento. Habían lanzado nuevos modelos en color, más pequeños, con diversas carcasas… pero el relevo generacional de GameBoy debía prepararse con urgencia.

Una de las líneas de trabajo que empezó la compañía tenía que ver con la utilización de pantallas táctiles, micrófonos, doble pantalla… en definitiva, era un modelo que apostaba por ampliar la experiencia jugable y llegar más allá de lo que una consola, al uso, podía hacer.

Otra línea de trabajo exploraba el, por entonces, creciente mercado de los teléfonos móviles con pequeños videojuegos. Todo el mundo quería tener teléfonos móviles que, a su vez, empezaban a incorporar pantallas más grandes, con colores, más memoria y procesadores más rápidos. Muchos creían que el futuro de las consolas portátiles pasaba por fusionarse con el móvil y Nintendo decidió probar a ver qué tal.

Nokia parecía el mejor partner posible y la compañía empezaba a acariciar la misma idea. De hecho habían empezado ya a probar cosas mediante prototipos de N-Gage así que una asociación con Nintendo no podía significar otra cosa que éxito.

En PocketGamer, descubridores de todo el pastel que se fraguó aquellos años, lo tienen claro. Algo falló en el desarrollo o simplemente algún visionario de la junta directiva de Nintendo vio que aquel no era el camino a seguir y tenía razón.

Después de meses de trabajo se presentaron los modelos de consola / teléfono y Nintendo rápidamente rechazó la propuesta decidiendo apostar por el otro prototipo que hoy conocemos todos.

No se puede decir que la compañía de Mario sea una compañía que se arriesga en exceso, todos sus pasos están medidos al milímetro y siempre se ha mostrado bastante conservadora. A nivel tecnológico no afrontan nunca inversiones excesivas si con menor gasto pueden llegar a algo parecido y priman, sobre todo, la originalidad y la capacidad de hacer más con menos. Y como suele pasar muchas veces, tenían razón.

Nokia sí apostó por ese camino creyendo que el futuro pasaba por conectar las dos tendencias ylanzó un híbrido entre consola y móvil llamado N-Gage. Un relativo fracaso, pese a que a día de hoy sigue disfrutando de un reducido grupo de fieles seguidores, que intentó enmendar en sucesivas revisiones. Un mal teléfono y una mala consola, a medio camino entre lo que intentaba ser y lo que realmente era. Errores de diseño industrial, una forma muy poco agradecida, una posición al llamar que rozaba lo ridículo, pantalla vertical en lugar de horizontal…

La última versión conocida del dispositivo, la N-Gage QD, que salió sólo unos meses después de la original con la intención de arreglar el desaguisado, disfrutó de más éxito internacional y atrajo a una serie de franquicias conocidas como ‘Tomb Raider’ o ‘Splinter Cell’ además de disfrutar de una pequeña joya del desarrollo español, el juego de lucha ‘One’, de Digital Legends.

Actualmente la marca N-Gage se ha convertido en un software para diversos móviles de gama alta de la compañía y que permite acceder a una especie de plataforma para descargar videojuegos.

Nintendo, por su parte se la jugó con Nintendo Ds y evidentemente ganó. Algo barruntaron, debieron ver que no era el momento adecuado para lanzarse a muerte a un modelo de negocio compartido con Nokia y decidieron pasar de la fusión entre consola portátil y teléfono móvil. El tiempo les ha dado la razón y es que quizá el proyecto estaba bien, pero no para aquella época.

Hoy, años después y gracias a la aparición de teléfonos verdaderamente potentes como el iPhone, la serie N de Nokia o los muchos smartphones que vienen con Android sí parece que estemos viviendo en un punto de convergencia. Quizá, hoy más que nunca, el espíritu de aquella aventura compartida entre Nintendo y Nokia resuene con más fuerza.

Juntar movilidad, accesibilidad, nuevas tecnologías, redes sociales, videojuegos, GPS, brújula, internet, servicios de descarga, multimedia… en un sólo aparato. ¿Acaso no es nuestro día a día en pleno 2010?

P.D. No hemos hablado del fenómeno del “sidetalking” que tanto daño hizo en aquel momento. La N-Gage original obligaba a colocar el dispositivo de lado para hablar por teléfono, una posición totalmente anti natural y forzada que dio origen a una moda muy popular por aquellos tiempos. Hacerse fotos con objetos de lado en la oreja. Empezando con la propia N-Gage y acabando con cafeteras, planchas, batidoras, teclados o macetas con plantas. Un auténtico delirio que acabó en unos meses, no me extraña.