Sector IT : una escabechina sin fin.

pacomer

Será en Octubre
Desde
15 Ene 2007
Mensajes
28.045
Reputación
85.437
Lo que es una prueba de que el sistema está roto. Le echan la culpa al remero de que el SW no funcione , casque todo el rato y sea una fruta hez. En vez de buscar la razón en que el paradigma y los lenguajes que usan tienen boquetes enormes, que impiden predecir lo explosivo del truño que han programado, no, vamos a apretar más las clavijas en la selección de picatecleros. Asi los managers y directivos se quitan el marrón de encima.

.... ejque no zaben pogramar en javaa, pittonnn vamos a ezigirles lo mismo que en Google... y ya tienes el circo montado. Si se usasen las herramientas adecuadas no haría falta alguna obligar al picateclero a invertir una lista enlazada o hacer un LFU cache o su querida madre, cosas que además no tienen nada que ver con lo que hace la empresa. Simplemente un título profesional de alguien que sabe aplicar los estandares matemáticos y funcionales que permite probar la corrección de un SW antes de echarlo a rodar.


Pero no, venga vamos a inventarnos absurdos sistemas de selección, que no arreglan nada, pues el SW sigue siendo igual de truñoso teniendo a tipos que sepan invertir listas enlazas o no.
 

pacomer

Será en Octubre
Desde
15 Ene 2007
Mensajes
28.045
Reputación
85.437
Es más fácil de lo que parece si empiezas por separar los llamados efectos puros deterministas de los impuros y los últimos bien "sellados" en monadas y profunctores. Y las monadas y profunctores tienen la ventaja de poder probarse matemáticamente porque en realidad lo que hacen es componer funciones de acuerdo a puras leyes de álgebra y grupos. Entonces pueden encerrar "computaciones inseguras" dentro de computaciones seguras y la composición te permite aislar el agujerazo de los sistemas de tipos que tienen los lenguajes OOP, para empezar. Es bastante más simple de lo que parece.

Pero claro, para esto hay que dejar de perseguir la última moda de los vendeburras y vendehumos y ponerse a estudiar cosas serias. Problema: que estas cosas ya no se enseñan ni en la universidad, donde el lenguaje vehícular de enseñanza es el puñetero Java.
 

rohirrim

Madmaxista
Desde
23 Ene 2013
Mensajes
1.118
Reputación
1.616
Lugar
Tierra Media
No es la pregunta correcta. La pregunta correcta es: ¿qué Cloud genera más lock-in para los que entran en ella, que ya no pueden salir sin incurrir en altísimos costes por marcharse? La respuesta es Azure: es la trampa perfecta.

Lo que entra en Azure/Microsoft365, ya no sale de ahí.

Yo recomiendo el Cloud de Microsoft a todo el mundo. Que se joroben.
bueno, el lock in en el fondo lo hacen todas las grandes, se juegan mucho en ello...

igual que Oracle compró MySQL en su momento para desnaturalizarlo, etc

Uno se no se hace rico (Bill Gates, Larry Ellison, etc) respetando el fair play y promviendo el freeware y el open source, sino siendo un me gusta la fruta cabrón...el mercado es cruel
 

pacomer

Será en Octubre
Desde
15 Ene 2007
Mensajes
28.045
Reputación
85.437
bueno, el lock in en el fondo lo hacen todas las grandes, se juegan mucho en ello...

igual que Oracle compró MySQL en su momento para desnaturalizarlo, etc

Uno se no se hace rico (Bill Gates, Larry Ellison, etc) respetando el fair play y promviendo el freeware y el open source, sino siendo un me gusta la fruta cabrón...el mercado es cruel
En realidad en el mercado de la informática el que tiene las de ganar es siempre el vendeburras, el vendehumos que atrapa por los narices al incauto que ha caido en la trampa marketinera del que le ha venido la solución crecepelos para su empresa.

Y ahí están SAP; ORACLE, MOCOsoft todos sacando los cuartos con OpenSource robado y adulterado y vendido como solución "emprezarial". En el mercado IT triunfa el que es más hijomio, no el que el tipo honesto y profesional que te va a decir la verdad de todo el asunto. Si no, que narices, la basura esa del OOP jamás habría existido. EL OOP existe porque es un sacacuartos de mucho cuidado. No interesa vender SW que funcione,todo lo contrario. hez y basura a capazo para tener bien agarrados a los "usuarios". Y en esas estamos.
 
Última edición:

Nico

Será en Octubre
Desde
6 Sep 2006
Mensajes
43.089
Reputación
141.154
Para los que quieran trastear con la IA "del otro lado de la cortina" :rolleyes:

 

pacomer

Será en Octubre
Desde
15 Ene 2007
Mensajes
28.045
Reputación
85.437
Para los que quieran trastear con la IA "del otro lado de la cortina" :rolleyes:

Teneis interfaces con el acceso al API en rest ya montado en gitHub
 

Aristóteles

Madmaxista
Desde
15 Abr 2013
Mensajes
1.034
Reputación
1.283
Lugar
Macondo
Se te quedas en la base y no pasas de 4 chorradas, claro, pero las abstracciones matemáticas no las pilla el Copilot o el ChatGPT si no se las das bien mascadas.. A ver como carajo, si no, te sale con una solución doble de monada Eff y profunctor abstracto con composición de funciones de high-order ante un problema de transcompilación de una expresión escrita en el lenguaje A a otra en el B. Cosa bastante frecuente en el mundillo web, donde las transcompilaciones están a la orden del día.

Nada que ver con las rutinas que hacen los javeros y pythonero, trivial de comprensión para que el GPT entienda los requerimientos de hasta un pacoPaliller de carnicera: " psss ejque necesito un cliente que me haga la siguiente request a una BBDD en azure con C#". y La maquinita te sale con una solución CRUD en unos segundos que deja en el paro a todos los picatecleros Cchaperos de la carnicerita.
Pues lo obvio,lo que ya se ha repetido hasta la saciedad desde Dijsktra, Knuth, etc que la programación es un campo aplicado de las matemáticas, y que por tanto la corrección de un programa debe ser probada matemáticamente. Porque si no, no se hace programación, sino tomarle el pelo a la gente programando sencilladas que valen para lo que valen, para ganar dinero engañando al prójimo.

Así que lo primero saber de álgebra, teoría de grupos y categorias y esas cosillas para entender lo que es demostrar que el programa que hagas va a ser correcto antes de darle al run o que no casque de manera imprevista 1 mes después. Qué tipo de programación permite esto, pues la que tenga detrás una prueba matemática (funcional, declarativa y parte de la procedural con el formalismo de los triples Hoare) . La OOP desde luego no, carece de toda prueba matemática que evite pegarse tiros en la cabeza todo el rato. Mira tú por donde, es precisamente la fruta hez que causa furor en las corporaciones y empresas , la fruta hez esa de la OOP.

Desde luego donde hay sistemas críticos, a nadie se le pasa por la cabeza hacer OOP. EL llamado mercado informático, es por eso en su inmensa mayoría un chiringuito vendeburras que no hay por donde cogerlo.
Debes ser programador de Haskell por tu retórica.
Pero te equivocas mucho con Java. Entiendo que durante las primeras language wars, Java era un lenguaje bastante punto medio en todo, con poca evolución, extremadamente lento, inconsistente, etc. Y que los Ansi Ceros, Haskellianos, Pythonianos etc.. le colgaron esa etiqueta y queda muy de moda decir algunos tópicos porque da rabia que sea el elegido como estándar para la programación web. Pero es un lenguaje que cuando iba a morir se puso las pilas, y ahora mismo tiene una de las mejores supervisiones y grupos de revisión del mundo, con actualizaciones constantes y mejorías muy notables. La JDK es alabada por muchísimos entendidos, más allá de que programen en Java o no, y los últimos frameworks son top-notch y con un mantenimiento y evolución mezcla de comunidad y privado exquisito. Es verdad que el core del lenguaje mantiene alguna limitación, pero se reinventa día a día (la última son los virtual threads, que se van a cargar la programación reactiva seguramente, por permitir las operaciones non-blocking al estilo event loop de js).

Java tiene mónadas, high-order functions, te puedes montar un profunctor o importar algunos de librerías desde la JDK8 del 2014 (y sealed types desde la JDK15, aunque con lombok ya lo usaba todo el mundo desde hace eones). Es más, son el pan de cada día desde hace al menos 7 años. En Java el paradigma funcional es la norma desde hace mucho tiempo, y todos los developers que se precien trabajan intentando mantener la mutabilidad al mínimo o 0 directamente, incluso Spring se basa en intentar hacer todo stateless, hasta el punto que se considera un code smell. Las funciones deben ser puras y nunca debes meter side-effects. Java tiene una comunidad muy muy grande de Clean Coders y Software Craftmanships. Sí, el sistema de tipado no es perfecto ni es irrompible a extremos TOC como el de Haskell (que en un diagrama con 8 o 10 ejes de las dimensiones típicas de programación, Haskell sería el representante extremo de entre los infinitos que existen), y no está limitado al paradigma funcional al 100%, aunque tienes otros lenguages sobre la jdk de java dedicados a ello (clojure, scala), pero en una escala del 1 al 10, si metes todos los lenguages de programación del mundo, Java es un 9 en funcional, un 9 en OOP y un 9 en tipado.

No entiendo que te pasa con OOP, es un paradigma completamente ortogonal al funcional. OOP no implica mutabilidad en ningún momento, se puede perfectamente combinar ambos paradigmas. OOP es útil para modelar de un modo más semejante a la mente humana (encapsulación, polimorfismo, composición de objetos), por eso ha triunfado. Para mí mezclar los dos es lo ideal. Tratar cada línea de un programa como si fuera una expresión matemática con mil nombres y conceptos abstractos está muy bien, y Haskell tiene que ser curioso y te debes sentir en cada línea como si estuvieras haciendo un examen de 3ero de exactas, pero por lo general los códigos que se necesitan deben responder a necesidades de negocio, y por eso se modelan como tal. Y sí, la filosofīa de base no es fundamentada en el talibanismo desde el bajo nivel de prohibir cualquier tipo de cagada de tipaje que se coma el compilador, o de mutabilidad vulnerable a concurrencia, pero tampoco es un lenguaje totalmente permisivo y tiene mil herramientas para programar en tu filosofía. Porque lo que no le quita nadie a Java es que esté en el top 3 de lenguajes con más librerías disponibles.

Para que quieres transcompilar funciones high-order etc.. Lo que la mayoría de iniciativas empresariales requieren son servicios online a usuario final, SAAS, producto interno. Quieren desarrollo rápido, leíble y escalable, y Java es un lenguaje cojonudo si pillas a gente con experiencia para eso, como lo es Javascript etc (que aún son más lejanos a la filosofía de Haskell por lo general). Me gustaría ver que pasa si coges una charcutera, pagas 20k a 20 tíos recién salidos del horno, y les pides hacer un código en Haskell o Erlang. Pasaría lo mismo que criticas con Java. No es el lenguaje, es el programador. Go está diseñado con el paradigma funcional en mente y es una escabechina igual porque es reclamado en entornos con una cultura donde a menudo se contrata a gente que no son experimentados.

En proyectos Java serios, con tests bien hechos, se puede salir a producción sin un solo bug reportado en meses.
Y asumo que estás a favor de los tests, al menos los e2e/integración, porque eso va más allá de que el código falle, hoy en día son necesarios para. asegurar que se cumple un contrato determinísticamente, y que puedes refactorizar cualquier cosa sin temor a que cambie (precisamente un proyecto grande, complejo y con muchos requisitos funcionales, se requiere de varias personas, y en ese momento es donde no puedes de una sola que tenga todo el contexto de requisitos y arquitectura del código en la cabeza). Lo puedes hacer cuan determinísitico desees, pero obviamente cada lenguaje tiene su nicho, y a nadie se le ocurriría programar la necesidad más ultraperformant a nivel de milisegundo o el firmware más low-level en Java (y hasta Minecraft, videojuegos), por ejemplo; y si te prima que el lenguaje sea ultraultraparanoico hasta el punto que te haga programar de una manera antinatural o poco intuitiva para asegurar al 99.99% que no permita un error del factor humano = programador porque vidas humanas dependen de ello, pues entiendo que no se escoja, pero no es el caso de la mayoría de iniciativas. Y aún así, la puedes soltar igual, porque siempre puede suceder un "pensaba que me habías dicho que tenía que hacer esto"

De todos modos, comparar lenguajes no me parece fácil, creo que se necesita mucha experiencia y uso avanzado de uno para poder dar una opinión autoritativa, solo por la cantidad de apis, frameworks y experiencias en producción en proyectos grandes, y es muy difícil que alguien trabaje a ese nivel con dos lenguajes no-complementarios como para compararlos. Yo he programado también en Ensamblador, Visual Basic, Ansi C, C++, Perl, PHP, JS, pero en distintas épocas, y ahora mismo no tengo ni idea del estado de las cosas de ninguno de estos, ya no trabajo en el sector, aunque sigo jugando con el Java a título personal de vez en cuando
 
Última edición:

pacomer

Será en Octubre
Desde
15 Ene 2007
Mensajes
28.045
Reputación
85.437
Debes ser programador de Haskell por tu retórica.
Pero te equivocas mucho con Java. Entiendo que durante las primeras language wars, Java era un lenguaje bastante punto medio en todo, con poca evolución, extremadamente lento, inconsistente, etc. Y que los Ansi Ceros, Haskellianos, Pythonianos etc.. le colgaron esa etiqueta y queda muy de moda decir algunos tópicos porque da rabia que sea el elegido como estándar para la programación web. Pero es un lenguaje que cuando iba a morir se puso las pilas, y ahora mismo tiene una de las mejores supervisiones y grupos de revisión del mundo, con actualizaciones constantes y mejorías muy notables. La JDK es alabada por muchísimos entendidos, más allá de que programen en Java o no, y los últimos frameworks son top-notch y con un mantenimiento y evolución mezcla de comunidad y privado exquisito. Es verdad que el core del lenguaje mantiene alguna limitación, pero se reinventa día a día (la última son los virtual threads, que se van a cargar la programación reactiva seguramente, por permitir las operaciones non-blocking al estilo event loop de js).

Java tiene mónadas, high-order functions, te puedes montar un profunctor o importar algunos de librerías desde la JDK8 del 2014 (y sealed types desde la JDK15, aunque con lombok ya lo usaba todo el mundo desde hace eones). Es más, son el pan de cada día desde hace al menos 7 años. En Java el paradigma funcional es la norma desde hace mucho tiempo, y todos los developers que se precien trabajan intentando mantener la mutabilidad al mínimo o 0 directamente, incluso Spring se basa en intentar hacer todo stateless, hasta el punto que se considera un code smell. Las funciones deben ser puras y nunca debes meter side-effects. Java tiene una comunidad muy muy grande de Clean Coders y Software Craftmanships. Sí, el sistema de tipado no es perfecto ni es irrompible a extremos TOC como el de Haskell (que en un diagrama con 8 o 10 ejes de las dimensiones típicas de programación, Haskell sería el representante extremo de entre los infinitos que existen), y no está limitado al paradigma funcional al 100%, aunque tienes otros lenguages sobre la jdk de java dedicados a ello (clojure, scala), pero en una escala del 1 al 10, si metes todos los lenguages de programación del mundo, Java es un 9 en funcional, un 9 en OOP y un 9 en tipado.

No entiendo que te pasa con OOP, es un paradigma completamente ortogonal al funcional. OOP no implica mutabilidad en ningún momento, se puede perfectamente combinar ambos paradigmas. OOP es útil para modelar de un modo más semejante a la mente humana (encapsulación, polimorfismo, composición de objetos), por eso ha triunfado. Para mí mezclar los dos es lo ideal. Tratar cada línea de un programa como si fuera una expresión matemática con mil nombres y conceptos abstractos está muy bien, y Haskell tiene que ser curioso y te debes sentir en cada línea como si estuvieras haciendo un examen de 3ero de exactas, pero por lo general los códigos que se necesitan deben responder a necesidades de negocio, y por eso se modelan como tal. Y sí, la filosofīa de base no es fundamentada en el talibanismo desde el bajo nivel de prohibir cualquier tipo de cagada de tipaje que se coma el compilador, o de mutabilidad vulnerable a concurrencia, pero tampoco es un lenguaje totalmente permisivo y tiene mil herramientas para programar en tu filosofía. Porque lo que no le quita nadie a Java es que esté en el top 3 de lenguajes con más librerías disponibles.

Para que quieres transcompilar funciones high-order etc.. Lo que la mayoría de iniciativas empresariales requieren son servicios online a usuario final, SAAS, producto interno. Quieren desarrollo rápido, leíble y escalable, y Java es un lenguaje cojonudo si pillas a gente con experiencia para eso, como lo es Javascript etc (que aún son más lejanos a la filosofía de Haskell por lo general). Me gustaría ver que pasa si coges una charcutera, pagas 20k a 20 tíos recién salidos del horno, y les pides hacer un código en Haskell o Erlang. Pasaría lo mismo que criticas con Java. No es el lenguaje, es el programador. Go está diseñado con el paradigma funcional en mente y es una escabechina igual porque es reclamado en entornos con una cultura donde a menudo se contrata a gente que no son experimentados.

En proyectos Java serios, con tests bien hechos, se puede salir a producción sin un solo bug reportado en meses.
Y asumo que estás a favor de los tests, al menos los e2e/integración, porque eso va más allá de que el código falle, hoy en día son necesarios para. asegurar que se cumple un contrato determinísticamente, y que puedes refactorizar cualquier cosa sin temor a que cambie (precisamente un proyecto grande, complejo y con muchos requisitos funcionales, se requiere de varias personas, y en ese momento es donde no puedes de una sola que tenga todo el contexto de requisitos y arquitectura del código en la cabeza). Lo puedes hacer cuan determinísitico desees, pero obviamente cada lenguaje tiene su nicho, y a nadie se le ocurriría programar la necesidad más ultraperformant a nivel de milisegundo o el firmware más low-level en Java (y hasta Minecraft, videojuegos), por ejemplo; y si te prima que el lenguaje sea ultraultraparanoico hasta el punto que te haga programar de una manera antinatural o poco intuitiva para asegurar al 99.99% que no permita un error del factor humano = programador porque vidas humanas dependen de ello, pues entiendo que no se escoja, pero no es el caso de la mayoría de iniciativas. Y aún así, la puedes soltar igual, porque siempre puede suceder un "pensaba que me habías dicho que tenía que hacer esto"

De todos modos, comparar lenguajes no me parece fácil, creo que se necesita mucha experiencia y uso avanzado de uno para poder dar una opinión autoritativa, solo por la cantidad de apis, frameworks y experiencias en producción en proyectos grandes, y es muy difícil que alguien trabaje a ese nivel con dos lenguajes no-complementarios como para compararlos. Yo he programado también en Ensamblador, Visual Basic, Ansi C, C++, Perl, PHP, JS, pero en distintas épocas, y ahora mismo no tengo ni idea del estado de las cosas de ninguno de estos, ya no trabajo en el sector, aunque sigo jugando con el Java a título personal de vez en cuando
OOP es una fruta hez. Si tienes alguna idea de matemáticas de 1st de la carrera antigua lo entenderias, te suena una cosa que se llama álgebra abstracta? : OOP ha nacido lenguajes con sistema de tipos rotos, que mezcla efectos mutables con inmutables a troche y moche,

Como ingeniero si voy a hacer algo serio y crítico exigo que tenga pruebas de corrección y replicabilidad. Y la OOP no tiene nada de eso. Es aceptable si estas dispuestos a tragarte pufos y tener que emplear a decenas de machacas para quemarlos con incidencias. Pero si tengo que programar para sistemas críticos y cosas serias, por supuesto al funcional de cabeza, y antes a un subcojunto del procedural (el probado con el formalismo de los triples de hoare) antes que la fruta hez del OOP. Capisce, amico ?

Al que inventó el Java (la fruta gaia del Gosling), deberían ahorcarlo.
 
Última edición: