Comentarios en: El hombre es un animal de costumbres

Por: Rafa

Rafa — Wed, 11 Jul 2007 17:31:00 +0000

Os comento mi experiencia. Llevo 20 años programando, desde el C, BASIC, COBOL, DELPHI, VISUAL BASIC etc. Pero al final, despues de estar cambiando de lenguaje porque dicen que uno es mejor que otro, te das cuenta de que no.Tenemos que hacernos una pregunta ¿ Porque ha durado tanto tiempo el COBOL ? ¿ Porque no habia otro lenguaje ? no, no nos engañemos, siempre han salido lenguajes nuevos diciendo que van a desbancar al COBOL, pero al final siempre se quedan a mitad de camino. El COBOL fue concebido para GESTION pura y dura, y en eso nadie le gana. Sus ficheros indexados son lo mas robusto que he visto en mi vida (hasta ahora nunca le he visto el limite), y eso que he trabajado con varias bases de datos, pero cuando un cliente ha estado trabajando con un programa en cobol, y está acostumbrado a una rapidez y una solidez, cuando le cambias el lenguaje (que es lo de menos) y le pones una base de datos, ahí es cuando empiezan los problemas, a decirte que ¿ porqué esto va ahora mas lento que antes ?.Con todo esto quiero decir que si vas hacer una aplicacion de gestion, el cobol sigue siendo la mejor opcion si quieres estabilidad y rapidez, si quieres hacer otras cosas quizas no. Ademas es el unico lenguaje que sigue un estandard para programar, hay unas sentencias fijas para todos los compiladores, y otras de propietario de cada compilador para que haga algo en concreto. El cobol ha seguido actualizandose desde sus origenes, no se parece en nada a los coboles de antaño, hoy por hoy el cobol puede hacer lo que quieras, y si mañana tu proveedor de cobol dice que no sigue actualizando tu compilador, pues vale, te cambias de compilador y a seguir programando, cosa que no ocurre con los demas lenguajes, simplemente te quedas en la estacada, y a aprender otro lenguaje si quieres seguir trabajando.
Con todo esto no quiero decir que sea el mejor lenguaje, ni un defensor a ultranza de el, pero si que tengo que decir que a mi me sigue dando muchas satisfacciones con el cliente final, y hasta ahora no ha venido ninguna empresa de programacion a quitarme el sitio, que creo que eso es lo que queremos todos los programadores.

Un saludo a todos.

Rafa

Por: tendero_digital

tendero_digital — Fri, 27 Oct 2006 12:13:27 +0000

Xlopez:
Efectivamente, nosotros con el sistema antiguo teníamos una estructura de cliente pesado que comenzó con Visual Basic y evolucionó hacia .net. Además apoyado con bases de datos SQL…
En el sistema nuevo esta basado en java, pero me llama la atención que tenemos consultas donde para aumentar la velocidad el usuario se aburre en los desplegables (envían de 50 en 50 items…) con lo cual para que el Host no se agobie, agobiamos al usuario y al cliente.
Tal vez la solución sea tener bien diferenciadas las tareas del ordenador central y el cobol por un sitio y las del clinte final por otro.

Por: xlopez

xlopez — Fri, 27 Oct 2006 10:37:12 +0000

Hola Tendero, yo tampoco creía que esto creciera tanto.
Como tu dices el intefaz de usuario de los programas cobol es muy espartano, por eso en la mayoría de sitios en los que se usa cobol (o en los sitios en los que he trabajado yo) se usa una arquitectura mixta.
Para la faena de verdad (las transacciones, el acceso a la base de datos, etc.) se usa cobol, mientras que para la presentación visual se usa o bien java (servlets + jsps) o bien clientes pesados (con .net).

Por: tendero_digital

tendero_digital — Fri, 27 Oct 2006 09:30:55 +0000

Xlopez y Coincido: las razones de que se implante Cobol las tengo claras, lo que yo intento trasladar es que nadie se ha planteado hacer ningún otro tipo de planteamiento, sobre todo si tenemos en cuenta que la migración es total; me explico no aprovechamos nada del código antiguo, ningún programa, todo se hace de nuevo. En estas circunstancias la ventaja de heredar el código se pierde y puede que otro planteamiento estuviese en igualdad de condiciones para considerarse.
Kike: tu plantemiento es más parecido al mío. Uno de los problemas que le veo a los Mainframes y al Cobol es justamente su diseño antiguo. Está muy bien para hacer transacciones cortas y simples, del tipo de hacer un ingreso, cobrar una compra en tarjeta de crédito… pero hoy en día en las Oficinas bancarias se hacen operaciones muy complejas: solicitudes de préstamos, seguros… que requieren muchos datos y un interfaz rico, y ahí el Cobol y el modelo de Mainframe se muestra pesado. De todas maneras como me estoy enrollando mucho, voy a ver si aclaro las ideas y preparo otra entrada sobre el tema.
Por cierto, gracias por los comentarios, normalmente estas entradas más “raras” suelen tener pocos comentarios.

Por: Gozerra

Gozerra — Thu, 26 Oct 2006 13:10:57 +0000

No puedo entrar a valorar tan especificamente los procesos que se usan para programar. Lo que si quizas estamos acostumbrados es al tradicional “si esto funciona, que siga”, aqui nadie arriesga, hay poca innovacion, da miedo el cambio, arriesgar capital,etc. Despues no queremos comparar con otros paises, incluso de la zona europea pero no hay nivel,creo.

Por: Kike

Kike — Thu, 26 Oct 2006 09:44:45 +0000

El problema de los mainframes es la centralización, que es el mismo problema que tiene Cobol. Si tu empresa no crece o solo crece jerarquicamente de manera local no vas a necesitar más, los usuarios serán más pero en el mismo edificio con lo que solo necesitas tu red local ampliada.
Pero en la banca y la administración al final se han tenido que hacer birguerías para descentralizar ciertos procesos y aún así muchos cálculos siguen centralizado. He visto cientos de terminales OS/2 con tarjetas de emulación de terminal para adaptarse a entornos antiguos e ir conmutando entre escritorio y terminal, yo mismo trabajé así una temporada con AS400.
En la administración (por lo menos en la que yo trabajo, aunque no soy funcionario) los cálculos de nómina por ejemplo son centralizados, pero los datos se introducen distribuidamente por eso ha habido que hacer una migración de entorno para facilitar al usuario la introducción de datos y gozar de los beneficios de nodos distribuidos y clusters de servidores de aplicaciones; antes era lo mismo solo que había un pedazo ordenador que cuando se calcula la nómina nadie podía entrar a trabajar, eso por mucho que digan es un atraso.
Lo de mantener cobol es simplemente un problema de economía, si no aporta beneficios no merece la inversión de cambiarlo, no me creo que tenga esa arquitectura más seguridad (no digo ya estabilidad) que los sistemas que hay hoy día, por muy robusto que fuera el SO, el problema es que antes manejando terminales eran 1000 y ahora son 200.000 y para que eso haya pasado, ciertamente ha habido que cambiar algunas arquitecturas (en los sistemas y en los cerebros de algunos marmolitos).

Por: coincido

coincido — Thu, 26 Oct 2006 08:28:42 +0000

Coincido con xlopez en todo lo que ha dicho. ¿Para qué vamos a montar un servidor web+servidor aplicaciones+2 años de becarios programando servicios web+1 año hasta estabilizar el programa si simplemente queremos una cosa que haga la contabilidad?

Saludos.

Por: xlopez

xlopez — Thu, 26 Oct 2006 08:02:41 +0000

El mótivo de de que sigan con cobol es que los programas van a ser prácticamente los mismos.
Podrán coger a un grupo de programadores cobol (gente sin experiencia con un cursillo de diez días) para que migren los programas, salvando las minímas diferencias de sintaxis.
No creo que se haga un rediseño de la aplicación.
Se pasarán a IBM o porque la máquina de Bull se queda pequeña o porque Bull dejará de dar servicios.
Yo estuve en una administración autonómica en la que se intento cambiar el programa de contabilidad de Cobol a Oracle, se contrató a la propia Oracle, estuvieron cinco años programando, se hizo todo nuevo, y al final se tiró todo a la basura (salío en prensa el despilfarro antes y después), y al final siguen con Cobol.
Lo bueno de los programas Cobol en grandes sitios (banca, administración pública, seguros) es que si se siguen estándares de programación.
Los gotos están prohibidos en todos los sitios en los que he trabajado (un banco, dos compañias de seguros, una administración y una universidad).
Y la programación cobol estará hecha a base de programas pequeños que se van llamando unos a otros.
Has comentado que Google no trabaja así, pero lo que hace google es basicamente buscar cadenas de texto, para eso el cobol no sirve, ni el java, pero para las aplicaciones de banca, impuestos, y demás el cobol funciona muy bien. Los hosts de IBm (y supongo que los de Bull también) tienenun código máquina que es casi Cobol, un move se corresponde con una instrucción máquina, lo mismo que un perform.
La programación cobol está muy estandarizada, en muchos sitios trabajan con ’software factorys’, en las que se se tienen 8 o 9 tipos de programas interactivos y 8 ó 9 de programas batch. Con esa topología se hace todo, y los programas son pequeños, manejables, muy fáciles de probar y de leer, ya que el cobol es autocomentado.