Portada
mis comunidades
otras secciones
#6:
#5 Y COBOL también, la mayoría de las transacciones financieras que se llevan a cabo hoy en día pasan por COBOL.
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.
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.
#8:
#7 Ohhh Fortran, Fortran, uhmmm... https://www.youtube.com/watch?v=gxNXPFIJsI4
Comentarios
#7 Ohhh Fortran, Fortran, uhmmm...
#8
El que hizo de Ballmer lo clavó tanto que el pobre se quedó encasillado: es el que le pone voz a Bender en Futurama
Mi primera rutina en tarjeta perforada fue en Cobol, pensé que ya no existía.
Os dejo que tengo que ponerme la vacuna.
#30 La nube no tiene por que ser de otro, puede ser tu propia nube.
Se le llama private cloud, y en mi trabajo es donde se ejecutamos la mayoría de aplicaciones.
#32 Aun cuando la nube sea privada, me sigue pareciendo un riesgo excesivo para un software que no va a requerir despliegues continuos ni movidas raras de Agile. En vez de tener algo corriendo sobre hierro lo tienes virtualizado, eso son capas extra con mas software que puede fallar y que requiere configurar y mantener. Y cualquiera que se haya dado de hostias con docker o kubernetes me dará la razón aquí... si puedes recompilarlo y echarlo a andar sobre un GNU/Linux moderno o equivalente, lo de las nubecitas sobra.
#33 Nadie te obliga a usar docker o kubernetes. Puedes recompilarlo y echarlo a andar sobre un GNU/Linux moderno como dices tú, y que luego ese GNU/Linux moderno sea una máquina virtual, que puedes migrar fácilmente de un host a otro.
#34 Y pasas a tener dos sistemas que gestionar: el virtual y el real que hay debajo... doble de recursos para gestión.
#35 La flexibilidad extra que obtienes bien lo merece. Sería como decir que (en una servidor físico) no quieres usar LVM porque con particiones sda1, sda2, sda3, etc ya tienes suficiente.
Me acaba de dar un infartito ahora mismo... "Deploy COBOL applications to cloud", con dos cojones. Gilipollas, pero con dos cojones...
#3 LISP y C son de la época y siguen usandose, por poner algunos ejemplos
#5 Y COBOL también, la mayoría de las transacciones financieras que se llevan a cabo hoy en día pasan por COBOL.
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.
#6 He de decir que yo sé programar en Fortran 77, y todavía se sigue utilizando muchísimo...
#7
Si no tienes vinilos de Buddy Holly y los Everly Brothers estás a salvo.
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.
#9 Aprendí Fortran en su momento porque fue lo que me enseñaron para cálculo numérico. Hice bastantes cosillas, entre ellas aplicación de métodos MonteCarlo y una dinámica de gases. Casi todo el software que se utiliza en computación científica está en Fortran 77, así que todavía me encuentro que a veces tengo que saber tocar algunas cosillas y me sirve lo que me enseñaron, aunque no sé porqué se sigue utilizando.
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.
#11 Se usa porque sigue siendo de lejos el lenguaje más eficiente para tareas de análisis numérico, pero hay que pagar el precio de su falta de expresividad. Incluso en otros lenguajes también muy eficientes en esos campos, como C/C++ o Julia, se utilizan librerías de Fortran para todo lo que tenga que ver tareas intensivas con infinitesimales y aproximaciones.
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.
#18 Uso numpy en todas las implementaciones que hago con Python pero aun así cuando necesito cosas muy concretas necesito tirar de bajo nivel. Lo malo de numpy es que parece que estés escribiendo en otro lenguaje que no es Python. Y por cierto, parte de numpy está escrita en Fortran
. Yo siempre uso este workflow cuando tengo que escribir alguna herramienta:
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.
#19 En realidad está escrito en C y provee interfaces para blas y lapack y un módulo para invocar directamente código de Fortran (f2py), pero sí, allá donde haya algo de álgebra lineal a poco que escarbes encuentras Fortran El que sí que tiene código en Fortran es Scipy.
¿Conoces Hy? Es Python con sintaxis de Lisp. Aún no lo he probado pero tiene buena pinta.
#3 no trabajo con COBOL aunque si en el sector.
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.
#13 A ver, ¿tu a cuantos bancos o aseguradoras conoces a los que les parezca bien llevarse los datos de sus clientes, cuentas, transferencias... a AWS? ¿El que sigan usando COBOL no te da una pista de lo monolitico que es su sistema, y de lo poco que se fian de migrarlo?
#14 AWS tiene la ISO 27.001 (seguridad) y trabaja ya con varios bancos españoles (y del mundo, y con gobiernos). Obviamente no tienen migrado todo a AWS, más bien es al revés, tienen lo más nuevo. Pero lo usan.
#22 Si, trabajan con varios bancos. Pero para las aplicaciones de movil, no para la puta base de datos y la logica de cliente que es el corazon de la operacion, y que mandaria al banco a la ruina en media centesima de segundo si se borrase por lo que sea. No vas a ver a ningun director de banco hacer la imprudencia de meter un sistema cobol que llevará decadas en marcha en un servidor de terceros, ni jarto de cocaina.
#14 Yo unos cuantos. Muchos bancos están migrando aplicaciones legacy a la nube, usando varias estrategias: reescribir el código en otro lenguaje y para otra arquitectura, contratar los servicios de otros para sustituir esas aplicaciones, migrar el código tal cual...
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.
#14 Yo estuve en una aseguradora, subcontratado y la razon por la que se nos contrataba era porque no se podian llevar los datos de la UE fuera de la UE. En el momento que la UE permita dejar los datos fuera, el paro en informática se dispara y los salarios van en caida libre. Que con lo que tu cobras (de españolito), contratan a 10 indios (en nuestro caso contrataban a 5 o 6 españolitos, por lo que cobraba un nacional de ellos).
Por si acaso, les importa una polla la "calidad del servicio", les importa que los costes se reducen a una decima.
#3 Probablemente practicamente todas las operaciones que haces con tu banco pasan por programas escritos en cobol.
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%.
#24 ¿De verdad soy el unico al que le parece malisima idea externalizar la seguridad informatica del nucleo de tu negocio cuando una caida del sistema puede costar la bancarrota a un banco? ¿En serio? ¿A todos os parece buena idea meter la logica de negocio del banco en
la nubeun servidor controlado por agentes externos? ¿Dormiriais tranquilos sabiendo que todo el plan de seguridad informatica depende de un outsider?#28 Todo probablemente me cueste bastante
habida cuenta de mi bajo nivel. Estudié sociología asi que te puedes imaginar que parto de la nada, tengo pendiente pillarme algún libro para dummies que me haga un buen destilado de estructuras de datos, algoritmos y tal, pero todo parece hecho para estudiantes de informática.
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.
#21 Nunca he picado nada "complejo", asi que ni idea, ni siquiera en python. Con complejo me refiero a muchas LOC, compartido con varias personas, lo máximo que he llegado ha sido a unas pocas miles de LOC entre dos personas. Y con Python, que se me hace relativamente fácil de entender si no se hacen cosas raras y los nombres de las variables resultan autoexplicativos.
¿Alguien ha preguntado el coste de la licencia?
#1 Ya ni lo ponen, será para no espantar a los clientes.
Aprovecho este hilo para preguntaros, si quiero pasar del scripting con python/bash etc a programar en serio, además de darle más duro a python me quiero meter en algún otro. Me llama la atención todo el Hype que hay con rust ¿Creéis que es una buena inversión de futuro? Lo digo porque tengo el tiempo justo y estoy entre meterme con Go o Rust.
#12 Aprende COBOL.
#12 yo le veo más futuro a Rust que a Go a largo plazo.
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.
#16 Parece prometedor. Lo único que tal es que por lo que leo se me hará muy cuesta arriba viniendo de Python, mientras que Go parece muy fácil.
#17 yo he programado principalmente en Python y JS, aunque con algo de experiencia con Java y C también.
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).
#12 mi método para aprender lenguajes es traducir algo que ya tengo. En tu caso busca algo sencillito que tengas en Python y lo reescribes en Go y Rust.
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.
#20 Sí, es algo que ya tenía pensado, lo que pasa que yo uso python para scripts y para análisis de datos, no creo que sea algo fácil de portar a lenguajes compilados sin las librerías adecuadas. Puedo hacerlo con Julia por motivos obvios, pero con Rust ni idea de cómo andará el tema, imagino que con Go estará algo mejor por ser de Google.
#25 se me ocurre leer un fichero tabulado, o CSV, calcular algo y escribir el fichero de salida, en Python, Go y Rust. Medir tiempos de ejecución y compararlo con tu apreciación subjetiva de "cuánto me ha costado aprender esto, cómo de difícil es de escribir, cómo es la toolchain para compilar/ejecutar/depurar"