La empresa estadounidense I.B.M. ha lanzado IBM COBOL para entorno Linux x86. El compilador es compatible con los productos y bases de datos de IBM y permite migrar el fuente de compiladores COBOL de otros productores además de tener capacidad para soportar bases de datos en la nube.
|
etiquetas: cobol , ibm , linux
Os dejo que tengo que ponerme la vacuna.
Pero LISP y C no son buenos ejemplos. LISP en realidad es una familia de lenguajes y las implementaciones que se usan actualmente (Common LISP, Scheme, Clojure...) son muy posteriores y C es de principios de los 70, que en esa época implica un salto enorme.
El que sí podría compararse es FORTRAN, que es coetáneo de COBOL y sigue empleándose mucho en librerías de cálculo.
Edit: Y también en LISP... Y no tengo más de 30 años... Debería empezar a preocuparme.
Yo más allá de una práctica que ni recuerdo lo único que he hecho con Fortran ha sido compilar BLAS y LAPACK (imagino que como el 90% de los que teclean actualmente gfortran en una consola ) Pero hay que reconocer que el legado de Fortran es inmenso, sobre todo para los que somos más de lenguajes wirthianos que ritchianos. Y además en su nicho de mercado su rendimiento es excepcional. No hay mucha gente que sepa programar en Fortran, y con el auge de la IA y el ML va a tener una demanda al alza. No creo que te vaya a faltar curro
Y LISP yo creo que debería ser materia obligada. Hay muchos prejuicios sobre cómo debe ser un lenguaje de programación y programar en LISP abre la mente y muestra cómo se pueden hacer las mismas cosas de una manera muy diferente. Y no digo ser un experto en LISP (que desde luego no es mi caso), pero poder descomponer un problema aunque sea en pseudo-LISP (en sexprs) es una herramienta análitica muy poderosa.
De Lisp aprendí el dialecto de elisp para poder hacer mis librerias en Emacs. Me costó muchísimo aprender ya que hay muy poca información en internet y casi todo el rato tenía que tirar de manual. Pero bueno, ahora puedo decir que puedo programar librerías funcionales en lisp.
Los lenguajes con los que más dominio tengo son Python y Go, ambos muy fáciles de aprender, con Fluent Python y The Go Programming Language pude aprender sin mucho problema. Normalmente escribo casi todo en Python y cuando tengo que hacer algo que requiera muchísima potencia de cálculo tiro de Go, mucho más fácil de escribir que Fortran y más entendible, algo más lento eso sí, pero más fácil de trabajar con él gracias a las gorutines.
Dada la gran base de código existente en ese lenguaje me gustaría saber por qué opinas que es de gilipollas querer desplegarlo en la nube.
Con los sistemas operativos intentando meterlo para algunos componentes, la fundación, Web Assembly, sin GC, el modelo de gestión de la memoria para evitar vulnerabilidades....
Lo veo como el sucesor natural de C/C++, pero a saber.
Python es una maravilla de la síntesis y su ecosistema es increíble y no para de crecer. Con Go sí que no puedo, es cierto que su implementación de CSP con las goroutines está bastante lograda pero el resto... me pregunto qué clase de droga corría por Mountain View el día que decidieron que Go ya estaba listo
Para potencia de cálculo, sin salir de Python, también está numpy, que es una virguería. Y un lenguaje compilado muy parecido a Python y con la eficiencia de C (pero memory safe) es nim. Es increíble lo bien que funciona y lo sencilla que es la metaprogramación, nunca he entendido por qué no se usa mucho más (aunque me consta que el que lo usa una vez ya no lo deja), supongo que el no tener una empresa detrás que lo promocione tiene bastante que ver con eso.
BASH? (+coreutils) -> awk? -> Python? -> Numpy? -> Go? -> herramientas específicas (R, C, CUDA, librerias, etc...)
Me gustó muchísimo aprender Lisp por lo mucho que ha influenciado a Python, hay muchísimas cosas que las hereda directamente de lisp y me ayudó a entender de donde venían. Sí que es cierto que es otra manera de pensar.
Bajo mi punto de vista Go es mucho más ameno, y el tema de goroutines lo tienen bien pensado, sin embargo leí que la concurrencia en Rust es más farragosa.
Tras hacer un curso de O'Reilly sobre los conceptos más novedosos de Rust (ownership y borrowing de referencias, generic lifecycles...), me pareció un poco complicado pero no algo demasiado loco o imposible de entender si se tiene la mente abierta y se hace un poco de esfuerzo extra.
Lo que no sé es como de frustrante será la experiencia real con el compilador cuando se trabaja con proyectos más complejos o si la gestión de la memoria es algo que sale de forma natural con un poco de experiencia (imagino que si).
Entiendo que lo que quiere hacer IBM aquí es ofrecer una alternativa de migración "transparente" de mainframe a la nube, sin tener que tocar una sola línea de código, y así aprovecharse de las ventajas de la nube y dejar de gastar dinero en mantener un mainframe que probablemente no está siendo aprovechado al 100%.
Yo creo que aquí IBM lo que está haciendo es ofrecer una alternativa para esta última estrategia, especialmente dirigida para aplicaciones escritas en Cobol para z/OS. Vamos, para que sigan operando tal cual, pero en lugar de tener el código ejecutándose en un z/OS, lo tendrán ejecutándose en un linux en la nube. Las ventajas de hacer todo esto no hace falta explicarlas.
Respecto a la localización de los datos, los grandes proveedores de la nube (AWS y Azure) cada vez tienen más datacenters y probablemente ya tengan uno en cada país, o al menos en el número suficiente de países para cumplir con las leyes de protección de datos. Y en cualquier caso, una cosa es dónde ejecutes tu código y otra distinta donde tengas tus bases de datos. Para aquellos que quieren mantener los datos on-prem, pueden seguir haciéndolo, independientemente de dónde se ejecute el código. Vamos, que puedes tener el código en la nube y conectarlo con una base de datos que tengas en un servidor propio.
Ya leí sobre bases de datos y me gustó bastante el tema, aunque fuese un poco superficial. Eso no quita que vaya a picar código igual aunque me falten conocimientos, porque si espero a sentirme "adecuado" no voy a hacer nada.
la nubeun servidor controlado por agentes externos? ¿Dormiriais tranquilos sabiendo que todo el plan de seguridad informatica depende de un outsider?¿Conoces Hy? Es Python con sintaxis de Lisp. Aún no lo he probado pero tiene buena pinta.
Se le llama private cloud, y en mi trabajo es donde se ejecutamos la mayoría de aplicaciones.
Por si acaso, les importa una polla la "calidad del servicio", les importa que los costes se reducen a una decima.