Activa las notificaciones para estar al tanto de lo más nuevo en tecnología.

Cuando Dijkstra se equivocó

Dice Joey Novak en The Reinvigorated Programmer: Nadie duda que Edsger W. Dijkstra era un genio y una leyenda de la programación. De hecho, es...

Dice Joey Novak en The Reinvigorated Programmer:

dijkstraNadie duda que Edsger W. Dijkstra era un genio y una leyenda de la programación. De hecho, es increíble que su idea sobre el valor de la programación estructurada haya sido tomada como una estupidez en algún momento. Es más, todos recordamos el artículo que quizás hizo famoso a Djikstra, en donde mencionaba lo dañino del GOTO en la programación (Edsger Dijkstra (March 1968). “Go To Statement Considered Harmful“. Communications of the ACM 11 (3): 147–148)

Desde luego que este artículo es la punta del iceberg sobre las aportaciones de Dijkstra. En Wikipedia hay un conjunto de verdaderas joyas al respecto, por ejemplo:

  • El programador competente está perfectamente al tanto del limitado tamaño de su propio esqueleto. Por lo cual, se aproxima a su tarea lleno de humildad y evita trucos geniales como la plaga“.
  • La programación orientada a objetos es una idea excepcionalmente mala, que sólo udo originarse en California“.
  • Es prácticamente imposible enseñar buena programación a estudiantes que han tenido una exposición previa al BASIC: como programadores potenciales, están mentalmente mutilados más allá de cualquier posibilidad de regeneración“.

Seamos honestos, esta última frase está tomada del artículo de Dijkstra, el cual contiene otra observación curiosa: “el uso de COBOL arruina la mente. Su enseñanza debería, por lo tanto, ser considerada una ofensa criminal“, lo cual también se dice a cada rato de BASIC. Todo el texto de Dijkstra no tiene más de 670 palabras y lleva un par de minutos leerlo. Es claro que del contexto del autor, las exageraciones han logrado un efecto hasta cómico, pero es claro que aunque exageraba, algo sentía Dijkstra: que el enseñar BASIC tenía un balance negativo para convertirse en programador.

Pero esto parece conflictuar con lo que observamos actualmente y aunque la teoría sea muy bonita, sería interesante contrastarla contra la realidad de ahora y la de antes. Yo conozco muchos programadores que empezaron a fines de los setentas y principios de los ochentas con Microsoft BASIC por lo cual me pregunto, ¿por qué se nos considera mutilados mentalmente? Dice Dijkstra que si no hubiésemos tenido contacto con BASIC las cosas serían mejor. Supongo que eso es posible pero no es algo que pueda resolverse haciendo algún experimento. Pienso que hay excelentes programadores ex-BASIC que son excelentes debido precisamente a la exposición de ese lenguaje.

Y que conste, no estoy diciendo que BASIC era mejor que otros. No lo era, de hecho era espantoso. La única construcción de un ciclo iteratico era el FOR I=1 TO 10; la única construcción condicional era la simple línea IF..THEN; todas las variables eran globales y sus nombres estaban restringidos a las dos primeras letras. Si queríamos hacer un ciclo WHILE, teníamos que construirlo usando IF..THEN GOTO. Las subrutinas se soportaban a través de la instrucción GOSUB, pero el RETURN no nos regresaba ningún argumento.

Y chicos, ustedes que han usado Visual Basic .NET o algo que no es realmente BASIC, por favor, dénse cuenta que no estamos hablando de rutinas de esta naturaleza:

Public Function PercentageOf(ByVal value1 As Integer, ByVal value2 As Integer) As Integer
Dim result As Integer
result = (value1 / value2) * 100
Return result
End Function

Sino de:

0 sys866:goto10
1 c$=c$+" ":k=0:d$=n$
2 k=k+1:a$=left$(c$,k):ifright$(a$,1)<>" "then2
3 b$=mid$(c$,k):ifleft$(b$,1)=" "thenk=k+1:goto3
4 ifb$=""thenn$="***":goto6
5 b$=left$(b$,len(b$)-1)

Como sea, mi argumento es que lo horrible de BASIC era su virtud. Nos forzó a pensar alrededor de las esquinas. Nos hizo pensar sobre qué estructuras de control realmente teníamos y el cómo estaban implementadas. Pero más aún, nos hizo pensar finalmente. La programación en un lenguaje que no tiene variables locales significa que se necesita un modelo mental claro sobre lo que cada variable está haciendo en cada punto de la ejecución de un programa. No quiero decir con esto que esto era una manera buena de programar. De hecho, no era una buena manera de programar. Era una manera horrible de programar y estoy realmente complacido de que ya no tengo que hacerlo más. Pero era un fantástico ejercicio. Desarrollaba los músculos mentales sobre lo que necesitarías a lo largo de tu carrera.

Pienso por ejemplo en los jugadores de tenis que entrenan levantando pesas. Cuando un jugador de elite levanta pesas, aplica mucho más fuerza de lo que necesita en un match de tenis. El punto no es que el jugador sea capaz de levantar , no sé, 16 tonelada, o cual sea el peso que pueda levantar: el punto es que cuando tiene que aplicar mucha menos fuerza en el transcurso de un partido, lo puede hacer sin esforzarse. Así, ha cubierto ese lado de su entrenamiento y su concentración puede ir en otro camino como el de elegir el tipo de tiro que quiere dar y la anticipación.

O piénsese por ejemplo en un pianista clásico. Quien toque los Etudes de Chopin tendrá que ir sobre una serie de contorsiones técnicas que no encontrará en la mayoría de las piezas musicales; pero por el hecho de dominar los Etudes, estará mejor preparado para su desempeño cuando toque cualquier otra pieza. (Admito que esta analogía no es la mejor porque Chopin era un genio superhumano y sus Etudes son gloriosas piezas musicales por mérito propio, amén de ser estudios técnicos).

Como sea: ya sea cargando pesas o siendo un pianista dominando los Etudes, de la misma manera, nuestras mentes deben lidiar con programas que sólo usan variables globales y GOTOs. Con ello estaremos mejor equipados para lidiar con los programas que necesitamos escribir en al vida real.

Así, pienso que programar en BASIC obliga a poner a la mente en una dirección específica que no se logra con otros ejercicios, y esto va en una dirección particular en los ambientes de desarrollo de la programación moderna. Lo que quiero decir es que mientras nos ejercitamos, digamos escribiendo un quicksort correcto, estamos desarrollando la habilidad de opensar en cientros de cosas a la vez. Y me siento ahora como que tengo todo el tiempo del mundo gracias a las innumerables bibliotecas y lenguajes que han llegado para hacer aplicaciones poderosas. El otro día me encontré trabajando en Perl, el cual estaba incrustado en código HTML, donde el rol de Perl era el de generar dinámicamente un fragmento de JavaScript para poner en cierto orden una serie de elementos en una forma HTML que tomaría varios valores, los cuales eran tomados directamente desde Perl de una base de datos. No pienso que todo esto es poco usual, pero para hacerlo correctamente, uno necesita pensar sobre varos niveles al mismo tiempo: codificación HTML, cidificación de cadenas de caracteres en Perl, Javascript, etc. No creo que la programación estructurada pueda ayudar en este problema, francamente enredado.

Pero Mike, ¿qué nos dices de los malos hábitos que aprendiste de un lenguaje como BASIC?” Sí, ahí hay un problema. Todos esos malos hábitos deben desaprenderse y el truco es, por supuesto, tirar todas esas técnicas de código espaghetti sin dejar de retener la memoria muscular que construimos cuando lo usamos. Sospecho que la mayoría de nosotros no encontramos muy difícil hacer esto: programar con ciclos WHILE se convierte en algo natural.

Así que únanse a mí, a aquellos que como yo crecimos con horribles dialectos del BASIC; maldigamos los malos hábitos que nos dejaron (que espero, hayamos dejado ya atrás hace mucho tiempo), pero agradezcamos que gracias a ellos ampliamos nuestra capacidad mental.

Finalmente les dejo la reflexión de John McCarthy, el creador de Lisp:

doing-it-wrong

Comentarios