Anarquismo triunfante (12 de 36)

Un segundo enfoque, ilustrado característicamente por el lenguaje COBOL (que significa COmmon Business Oriented Language, --Lenguaje Común Orientado a Negocios), era hacer que el programa en sí se pareciera a una serie de instrucciones en lengua natural, escritas con un estilo oscuro pero en teoría legible para humanos. Una línea de código de COBOL podría decir, por ejemplo, "MULTIPLY PRICE TIMES QUANTITY GIVING EXPANSION” (multiplica precio veces cantidad dando expansión). En un principio, cuando los expertos del Pentágono y de la industria comenzaron el diseño conjunto de COBOL en los primeros años de la década de 1960, este enfoque parecía el más prometedor. Los programas de COBOL aparentemente se documentaban a sí mismos, permitiendo tanto el desarrollo de equipos de trabajo capaces de colaborar en la creación de programas grandes, como el entrenamiento de programadores que, aunque eran trabajadores especializados, no necesitaban comprender la máquina tan íntimamente como los programas de ensamblador. Pero se eligió erróneamente el nivel de generalidad con el cual estos programas se documentaban a sí mismos. Una expresión más comprimida y en formato de fórmula de los detalles operativos, como por ejemplo, “expansion = precio x cantidad”, resultaba más conveniente incluso para las aplicaciones financieras y de negocios, en donde tanto los lectores como los escritores de programas estaban acostumbrados a expresiones matemáticas, mientras que los procesos de describir tanto las estructuras de datos así como un más amplio contexto operacional del programa, no se volvían innecesarios, no obstante la verbosidad del lenguaje en que los detalles de la ejecución estaban especificados.

Por consiguiente, para el final de esa misma década los diseñadores de lenguajes comenzaron a experimentar con formas de expresión en que la mezcla de los detalles operacionales y de la información no-funcional necesaria para la modificación o reparación, era más sutil. Algunos diseñadores eligieron el camino de los lenguajes altamente simbólicos y comprimidos, en los cuales el programador manipulaba los datos de manera abstracta, de modo que "A x B" podría significar la multiplicación de dos enteros, dos números complejos, dos enormes arreglos, o cualquier otro tipo de dato capaz de algún proceso llamado "multiplicación", para ser llevada a término por la computadora con base en el contexto de las variables "A" y "B" al momento de la ejecución [12]. Puesto que este enfoque resultó en programas extremadamente concisos, se pensó, que el problema de hacer código comprensible para aquellos que luego buscarían modificarlo o repararlo se había simplificado. Al esconder los detalles técnicos de la operación de la computadora y enfatizar los algoritmos, se podían inventar lenguajes que fueran mejor que el inglés u otras lenguas naturales para la expresión de procesos paso a paso. Los comentarios serían no sólo innecesarios sino distractores, tal como las metáforas usadas para comunicar conceptos matemáticos en inglés logran más confundir que esclarecer.

12. Este, debo decirlo, fue el camino que siguió la mayor parte de mi investigación y desarrollo, en gran parte relacionado con un lenguaje llamado APL ("A Programming Language" --Un Lenguaje de Programación) y sus sucesores. No fue, sin embargo, el enfoque finalmente dominante, por razones que serán expuestas a continuación.

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
[11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
[31] [32] [33] [34] [35] [36]