Hoy publicamos la segunda parte de la traducción de material sobre matemáticas, sobre COBOL y por qué este lenguaje aún está vivo.
→
La primera parteRelación de recurrencia de Müller y COBOL
Veamos cómo maneja COBOL la relación de recurrencia de Müller. Aquí hay un programa COBOL que implementa la relación de recurrencia que estamos estudiando.
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
Si es la primera vez que ve un programa escrito en COBOL, aclaremos algunas cosas de inmediato. En primer lugar, se trata de la llamada COBOL de "forma libre", que se introdujo en 2002 para acercar COBOL a la estructura de los lenguajes modernos. Tradicionalmente, el código COBOL tiene un ancho fijo cuando ciertas entidades se colocan en ciertas columnas. La idea de considerar el código en forma de una estructura en la que se resaltan filas y columnas puede parecer extraña, pero dicha estructura de código tenía la intención de simular el formato de la tarjeta perforada. En los días de COBOL, los programas se crearon de esa manera. Una tarjeta perforada tiene 80 columnas; ciertas columnas son para ciertos datos. El mismo enfoque es tradicional para COBOL.
Lo más importante en este código, algo que quizás atraiga la mayor atención, es cómo se declaran las variables aquí:
01 X2 PIC 9(3)V9(15) VALUE 4.
El código
01 al comienzo de la línea se llama número de nivel. Él le dice a COBOL que estamos declarando una nueva variable. COBOL le permite vincular o agrupar variables (un ejemplo clásico es una dirección, que puede incluir los nombres de la calle, ciudad y país como variables separadas), como resultado, en este caso, el número de nivel se vuelve importante.
X2 es el nombre de la variable: todo es bastante simple. Al final hay una construcción que establece el valor inicial de la variable, que se ve como "
VALUE 4. ". El punto al final no es un error tipográfico. Esta es una forma de terminar líneas en COBOL.
Ahora solo necesitamos considerar lo que está en el medio de la línea: la construcción del
PIC 9(3)V9(15) .
PIC es un poco un operador para describir un tipo de datos de caracteres. Puede almacenar valores alfanuméricos. Incluso puede almacenar números decimales. COBOL es un lenguaje con mecanografía estática estricta y con una característica inusual, que es que la mayoría de los tipos COBOL son mucho más flexibles que los tipos en otros idiomas. Además, al declarar variables, debe especificar en cuántos caracteres pueden consistir. En nuestro caso, este es el número entre paréntesis. La construcción de
PIC 9(3) significa que una variable puede almacenar tres caracteres, que son números (indicados por el número
9 ).
Como resultado, la construcción
9(3)V9(15) debe leerse como sigue: "3 dígitos, seguidos de un punto decimal (v), seguido de otros 15 dígitos".
Aquí están los resultados de este programa:
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
Esto sucedió usando números que tienen 15 decimales. Si cambiamos las propiedades de las variables
X1 ,
X2 e
Y a
PIC9(3)V9(25) , entonces podemos seguir:
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
Diferentes mainframes ofrecen diferentes límites superiores para los tipos de datos COBOL. En IBM (al menos, en mi caso) tiene 18 dígitos. MicroFocus tiene 38 dígitos.
¿Cuánto cuesta la precisión?
Todo lo que acabamos de hablar tiene como objetivo mostrar que COBOL realiza cálculos no mejor que otros lenguajes de programación más comunes. Debido a restricciones en el tamaño de los números de punto fijo, COBOL puede ser inferior a los idiomas que le dan al desarrollador más control sobre lo que está sucediendo.
Pero hay una característica. El hecho es que Python (y Java) no tiene soporte incorporado para números de punto fijo. Y en COBOL este soporte es.
Para realizar cálculos de punto fijo en Python, tuve que importar el módulo
Decimal . Si alguna vez ha trabajado con un proyecto que tiene un montón de comandos de importación, debe tener en cuenta que cada comando tiene un cierto "precio". En lenguajes como Java (es decir, este lenguaje generalmente es considerado por aquellos que van a deshacerse de COBOL) el "precio" de una biblioteca adecuada puede ser significativamente
mayor . Esto, de hecho, es más bien una cuestión de si el "costo" de importar bibliotecas juega algún papel en su proyecto. Para muchos programadores, pensar en el impacto en el rendimiento que tienen los comandos de importación es el pináculo de la optimización prematura.
Pero los programadores de COBOL generalmente trabajan en sistemas que necesitan procesar millones y posiblemente miles de millones de operaciones por segundo, haciéndolo de manera precisa y confiable. Y, desafortunadamente, es muy difícil dar un argumento convincente a favor de COBOL o en su contra para tal escenario, ya que este es, de hecho, un área de innumerables variaciones. ¿El soporte de punto fijo integrado en COBOL es un factor determinante al elegir un idioma para resolver tales problemas? ¿O tal vez los problemas correspondientes se pueden resolver eligiendo la combinación correcta de procesador, memoria, sistema operativo? O, tal vez, para resolver problemas de cálculos rápidos, precisos y confiables, ¿necesita recurrir a "bailar con una pandereta"? Tal vez, ¿limitaremos el razonamiento? Los reduciremos a encontrar una respuesta a una pregunta como "¿Qué es mejor: COBOL o Java si usa el mismo hardware?". Pero aun así, será difícil para nosotros evaluar cómo las deficiencias de cada uno de los idiomas afectarán el rendimiento en el momento en que el sistema comience a realizar los miles de millones de operaciones mencionadas por segundo. Como resultado, solo podemos decir que el mismo COBOL y Java son lenguajes muy diferentes.
Esto es lo que escriben sobre esto
aquí , explorando el rendimiento del código Java traducido del código COBOL.
COBOL es un lenguaje compilado que utiliza una pila que admite punteros y combinaciones. La conversión de tipos no crea una carga en el sistema durante la ejecución del programa. No hay conversiones de programación o tipo durante la ejecución del programa. El código Java, por otro lado, se ejecuta en una máquina virtual. Utiliza un montón y no admite combinaciones. La conversión de tipos ejerce presión sobre el sistema durante la ejecución del programa. Java usa despacho dinámico e inferencia de tipos en tiempo de ejecución. Aunque es posible minimizar la cantidad de uso de estas características, esto generalmente lleva al hecho de que el código es más o menos "diferente" del código Java ordinario. Al estudiar los resultados de traducir el código Java de COBOL, generalmente se quejan de que el código es ilegible y no es compatible. Esto niega la mayoría de los objetivos de pasar de COBOL a Java.
Antes de decidir dejar de lado estas consideraciones con la frase "Sí, pero es Java, y Java tampoco es un regalo", recuerde esto: la mayoría de los lenguajes de programación modernos no tienen absolutamente ningún soporte incorporado para los cálculos de punto fijo. (Creo que sería más correcto decir que ninguno de los idiomas modernos admite esto, pero no puedo verificarlo de manera confiable). Por supuesto, puede elegir otro idioma que tenga su propio conjunto de ventajas y desventajas, pero si se necesita precisión en los cálculos con un punto fijo, y si cree que una pequeña pérdida de rendimiento al importar una biblioteca que implementa dichos cálculos puede perjudicarlo, esto significa que tiene la única opción: COBOL.
Es por eso que la llamada "modernización" es tan compleja: depende de muchos factores. Algunas organizaciones recibirán resultados tangibles de las inversiones para cambiar la plataforma de software, mientras que otras descubrirán que han perdido algo importante a cambio de "mejoras" que, de hecho, no mejoran mucho. Si una organización es una gran institución financiera que procesa millones de transacciones por segundo y necesita una precisión decimal de los cálculos, entonces, de hecho, será más barato capacitar a especialistas para trabajar con COBOL que pagar recursos y productividad para migrar a un idioma más popular. Después de todo, la popularidad es temporal.
Resumen
Como resultado, al hablar sobre por qué tantas organizaciones todavía usan COBOL, debe comprender que la tarea de procesar los programas es diferente de la tarea de crear programas. Los programadores que crearon la solución tuvieron la ventaja de su implementación por fases. Las aplicaciones generalmente se esfuerzan por acercarse lo más posible a los límites de las capacidades que admiten sus tecnologías. El dilema con respecto a la migración desde COBOL no es una cuestión de cambiar de un idioma a otro. Esta es la tarea de pasar de un paradigma a otro. Los límites de Java o Python en Linux no son los mismos que los límites de COBOL en el mainframe. En algunos casos, las aplicaciones COBOL son capaces de lo que los lenguajes modernos no pueden. Para tales casos, el uso de COBOL en un mainframe moderno resultará ser, de hecho, una solución más barata, productiva y precisa.
Estimados lectores! ¿Crees que COBOL es realmente un lenguaje que en algunas situaciones resulta ser realmente mejor que los idiomas más modernos?
