Hace ahora dos años era noticia que Python superaba a Java como lenguaje de programación más usado según uno de los más reconocidos índices que se hacen al respecto, el TIOBE. Y ahora, en el último informe, tenemos que Python se mantiene líder mientras Java sigue perdiendo fuelle e incluso ha sido superado por C++. Por tanto, tenemos que el índice TIOBE de diciembre que concluye este año 2022 tenemos que Python ha conseguido mantener su enorme fama, seguido de C. Mientras que Java ha bajado a la cuarta posición desde la tercera de hace un año.
|
etiquetas: lenguajes , programación , java , python , c++ , popularidad 
Java es perfecto para las consultoras y los encorbatados. Con relativamente poca formación, y con lo verboso que es, da para facturar horas a saco. Kotlin, sin meterse en las complicaciones de C y C++, permite hacer lo mismo con una burrada menos de código.
Kotlin se ha cargado ante todo las dos peores cosas que tiene Java. Una, la porquería de las excepciones comprobadas, que al final lo único que fomentaban era que se silenciasen. Otra, el null indiscriminado. En Kotlin no hay más tu tía, o el valor es obligatorio y es imposible asignarle null, o es opcional y por narices hay que cubrir la posibilidad de null. Con razón lo llaman el error del billón de dólares en Java.
Como todo en esta vida, tienes parte de razón, pero seguramente viene dado por un contacto con monstruos del pasado, no se si JEE, si Struts o vete a saber que cosa basada en XML viste. De todas formas, aquí mi opinión:
Para empezar hay muchos proyectos, muy interesantes, hechos en Java, por ejemplo se me ocurre Apache Kafka, que es la puta hostia en cuanto a rendimiento (también tiene Scala) o Frameworks tipo Quarkus que hasta compilan con GraalVM a nativo para reducir principalmente la huella de memoria.
El soporte de java a la tecnología es absoluto, si existe es Java lo soporta con un grado muy bueno con casi total seguridad, posiblemente la contra-argumentación sería librerías de IA tipo Tensorflow, PyTorch o SKLearn (que para mi son la hostia), pero aún así tienes cosas bastante aceptables como Spark ML, H2O, etc.
Java es un lenguaje tremendamente sencillo, por ejemplo, yo sigo muy de cerca C++ (por motivos históricos), y desde C++11, cada 3 años tenemos más y más funcionalidad dificilmente de seguir, de hecho he visto código en los repos de facebook en los que usan mal cosas simples como el perfect forwarding (el lenguaje casi parece un fin en si mismo más que una herramienta). Pero incluso si nos vamos a lenguajes considerados sencillos, como Python, este es mucho más complejo que Java, solo hay que echar un vistazo a los atributos tipo __XXXX__ de las clases que dan mucha potencia para hacer frameworks tipo DJango, pero que difícilmente un novicio en Python va a entender. En Java, lo más complejo tal vez sea el procesador de anotaciones o desde un punto de vista de procesos la configuración de la JVM.
Pero hablando de configuración de JVM, en temas de monitorización, APM y similares, la JVM da sopas con ondas a cualquier lenguaje, y aquí no hay discusión, haz una búsqueda de empresas que dan soporte a esto y verás que hacer cualquier cosa relacionada con Java es mucho sentido, por ejemplo, Datadog. Obviamente esto es algo tramposo, porque sobre la JVM pueden correr muchos lenguajes (Kotlin, Scala, etc), pero no olvidemos que el principal es Java.
Es un lenguaje, que salvando el Type Erasure, tiene… » ver todo el comentario
Existen programas muy decentes, con arquitecturas de alta calidad, mantenibles y extensibles, desarrollados en todos los lenguajes populares. Ya basta de responsabilizar a las herramientas de tus carencias o las de tus compañeros. Don't blame the tool.
Pero decir que no pinta en ningún escenario es muy atrevido. Java es un gran lenguaje backend para casos de uso que requieren escalabilidad, multi-threading, gestionar solicitudes a escala, etc. Vete tu a cualquier empresa gorda a decirle que le vas a hacer todo el backend en PHP a ver qué te dice...
Hasta el nombre tiene un error, se debería preincrementar el lenguaje antes de usarlo.
Las excepciones comprobadas hace años que nadie las usa, si siguen ahí es por compatibilidad hacia atrás (algo que Java respeta mucho).
Para manejar "nulls" tienes los "optionals" que mezclados con la programación funcional de Java hacen más sencillo tratar el problema de los nulls.
Y luego tienes todos los cambios que han ido haciendo al lenguaje en las últimas versiones: records, pattern matching, sealed classes, nuevos switch, etc.
Creas un proyecto nuevo, desde cero,vbajas un framework tipo react o angular, alguna otra librería de moda y esperas 30 días. Sin picar nada. Como si estuviese madurando.
Haces un npm clean, npm install y ya tienes 4 o 5 avisos de librerías deprecadas, dependencias peligrosas, etc..
Legacy empaquetado.
He picado muchos años en PHP. Proyectos muy tochos. Con arquitecturas hexagonales, CQRS y otras exoticidades. Lo he sufrido.
En cuanto a node, por suerte he conseguido evitarlo. Mi mayor mérito al respecto fue destruir una app react native llevándola a flutter. Canela fina. El equipo dejó de tapar agujeros para construir software.
El que quiera vivir en un pantano, allá el. Yo me fui hace tiempo de allí
Es que la máquina virtual de javascript es la única computadora universal que existe ahora mismo. Universal en el sentido en que cualquier programa escrito para la computadora de javascript, puede ejecutarse en cualquier tipo de computadora relevante.
El resto de lenguajes/plataformas tienen que aceptar ser un "second class citizen en la web".
Trabajar en la web transpilando es horrible, por que es díficil comprender lo que pasa cuando tienes ese nivel de indirección que te agrega el transpilado. Por lo que si quieres hacer aplicaciones web de verdad, necesitas hacerlas sobre javascript/typescript.
Luego, con javascript/typescript puedes hacer aplicaciones nativas 100% para el teléfono con react-native, y puedes hacer aplicaciones para escritorio, como spotify o vscode, que son basicamente Electron, y son buenas aplicaciones.
Sobre juegos y 3d, tienes librerías como Three.js, y otras de mas alto nivel por encima, como react-three-fiber, que son literalmente una pasada.
En el servidor, node.js te ofrece acceso a un motor event-based reactivo (v8), con millones de paquetes NPM e interoperatibilidad con el navegador. Yo programo mis objetos de dominio una sola vez, en typescript, y los uso tanto en backend como en frontend, y muevo codigo (import) del backend al frontend y del backend al frontend sin mas limitaciones que las infraestructurales evidentes.
No se, me debo estar perdiendo algo
Me gusta como lenguaje de script para el usuario final, pero nunca para el core de un proyecto medianamente serio.
Muchísimas aplicaciones completamente serias están escritas en javascript/typescript, y me gustaría que argumentes donde está el problema.
Y sobre el dinero tirado... yo me dedico a esto hace 20 años aprox, y he visto tirar millones en todo tipo de proyectos y todo tipo de lenguajes.
Hay herramientas más susceptibles que otras a descomponerse.
Lo que se descompone no es la herramienta, es tu proyecto, por tus decisiones de diseño.
Creas un proyecto nuevo, desde cero,vbajas un framework tipo react o angular
React no es un framework, y que digas que es un framework o que lo compares con angular, me demuestra que o no has programado en angular, o no has programado con react, o ambas.
alguna otra librería de moda y esperas 30 días. Sin picar nada. Como si estuviese madurando.
Si te dedicas a decidir el DBOM/Supply chain/dependencias de tu proyecto en base a las modas, es normal que salgan nuevas versiones. Las cosas de moda están en evolución. El ecosistema de NPM te ofrece librerías y frameworks en todos sus estados de madurez. Desde cosas nuevas y de moda, que se quedarán obsoletas al poco tiempo, hasta librerías asentadas y refinadas, que puedes fijar la versión con SEMVER y no moverte de la minor/patch, que todo va a funcionar genial. Usar cosas mas nuevas e inestables o mas asentadas y estables es una decisión de diseño que tomas TU.
Haces un npm clean, npm install y ya tienes 4 o 5 avisos de librerías deprecadas, dependencias peligrosas, etc..
Todas las cosas serias en npm usan semver. Tu sabrás como gestionas tus dependencias. Obviamente las dependencias están vivas y tienen errores de seguridad y evolucionan. Eso es así en javascript/npm y en java/maven o en php/compose o en cualquier otro sistema. ¿O que quieres, que el mundo se pare para que tu desarrolles? no entiendo este argumento tuyo, la verdad.
¿que te molesta, que haya librerías innovadoras que evolucionan rápido? no las uses, usa las mas tradicionales y estables, que también las hay. ¿Que te molesta, la libertad para decidir?
Legacy empaquetado.
No sabes de lo que hablas.
Estoy aprendiendo Typescript en un curso de Nest_Js. Al fin le veo sentido a TS
"No sabes de lo que hablas." Aprende a dialogar con más respeto. Por mi parte, aquí we acaba la conversación
Excel tiene un lenguaje de formulas dentro, que no ha sido turing complete hasta el año 2021:
www.infoq.com/articles/excel-lambda-turing-complete/
Si bien es cierto que a día de hoy, el DSL (es.wikipedia.org/wiki/Lenguaje_específico_de_dominio) de excel es turing complete, y como tal, ya sería un lenguaje de programación, la realidad es que la mayoría de la gente aprendió a usarlo antes de ser turing complete, y como tal, es usado mas como un DSL incompleto que como un lenguaje completo.
Aunque es controvertido, y quizás tienes razón.
Ya te he dicho que todo lo que he hecho en node javacript es migrarlo a otra cosa y acelerar, desbloquear el equipo. Todas esas mierdas forman parte del ecosistema.
Pero entonces tu problema es con el legacy que la gente hace, no con la plataforma. Yo he ganado mucho dinero refactorizando cosas en PHP, Java, C++, C, perl y javascript. Y no pienso que ninguna de esas plataformas sean legacy, sino que los equipos que hicieron esos programas no tomaron las decisiones de diseño adecuadas para su contexto.
Tu has venido aquí a decir que el problema es la herramienta, y en general, en ingeniería del software, se sigue mucho este principio:
en.wiktionary.org/wiki/a_bad_workman_always_blames_his_tools
Por eso pienso que no sabes de lo que hablas. Si supieses de lo que hablas no pensarías que los problemas derivados que tu arreglabas en esos programas eran por las plataformas subyacentes. Entenderías que en realidad, tu puedes esribir un buen o mal programa en cualquier plataforma profesional popular.
Yo he portado muchos programas ASQUEROSOS de C++ a javascript, y no considero que C++ sea asqueroso, por que colaboro con proyectos open source en c++ donde las cosas están muy bien hechas
Yo asocio las propiedades objetivas de calidad de un software a las decisiones de diseño del programa, no de la plataforma sobre la que está construído (siendo una plataforma grande y popular, obviamente). Y en general así creo que se entiende en el 100% de libros de ingeniería de software que he leído sobre el tema. Entiendo que tu quizás tienes otra bibliografía, me gustaría conocerla, la verdad.
Y luego, explicame que tiene PHP de malo, y no me digas php nuke que eso es que no has visto php 7 en adelante.
En esta charla, tanto conmigo como con otros meneantes, sólo has hablado de lo bueno que es tu martillo.
6. El rendimiento de Javascript (o cualquier lenguaje "dinámico") es horrible en comparación, así que depende de lo que quieras implementar
Eso es falso, y además tiene dos contraargumentos muy fuertes:
1. la mayoría de programas informáticos están MUY lejos del rendimiento que la plataforma las puede proporcionar. Se pueden hacer programas MUY rápidos en Javascript, sobretodo si tu motor es v8. De igual forma que se pueden hacer programas muy lentos en Java, y de lejos. Por lo que hablar de rendimiento computacional cuando se comparan plataformas, suele ser un argumento pobre, por que todas las plataformas modernas tienen un rendimiento muy superior al que necesitan el 99% de programas. Por lo que si tu programa va lento, seguramente no es culpa de la JVM o de v8, es mas bien culpa de tus decisiones de diseño. La mayoría de las veces las cosas van lentas por una gestión inadecuada de la concurrencia y de la entrada/salida. Teniendo en cuenta que en Javascript la concurrencia es colaborativa, y la entrada/salida se apoya en la concurrencia colaborativa, en muchos escenarios es directamente mas rápido que el típico programa de concurrencia preemptiva que la gente escribe para la JVM.
2. incluso si dejamos de lado el punto 1, y nos fijamos en el rendimiento puro a la hora de manipular datos en situaciones de laboratorio, v8 tiene optimizaciones JIT que se activan cuando tu código no abusa de depende que dinamismos, donde el rendimiento es superior al de la JVM. Por lo que si tu codigo es optimizable o no lo es, es una decisión de diseño tuya en JS. Lo bueno que tiene eso, es que puedes hacer que todo el código pegamento sea mas conciso a base de usar dinamismo, y luego puedes no usar dinamismo cuando te interese.
Mira, yo hace años hice un descompresor de imagenes LZSS en javascript, que alcanzaba rendimiento increíbles, muy superiores a los de las librerías disponibles para la JVM que encontré que hacían eso. Obviamente, para alcanzar ese rendimiento necesité prescindir de ciertos dinamismos. Pero me permitió mantener un solo lenguaje tanto para la parte dinámica, como para la parte de alto rendimiento. Y como digo, en la parte dinámica también me beneficio de un mejor rendimiento, pero derivado de otros factores.
Si la heap sobrepasa 512MB seguramente algo muy malo estás haciendo. Ahora mismo no recuerdo cómo funciona el GC de JVM, para ser completamente sincero hace bastantes años que no lo toco, pero si me permitís hablar de .net para llenar la heap con tantos objetos grandes que llega a ocupar 512MB es que hay algo mal en el código. Me huele a leak, porque los objetos pasarían por los niveles de la pila sin que el GC pudiera borrarlos y si no puede borrarlos durante tanto tiempo... malo.
Veo que la heap de la JVM tiene por defecto 128 y es habitual cambiar la configuración para usar medio giga. Debería ser suficiente si no se cometen errores.
Es divertido que cuando te has quedado sin argumentos, en lugar de rebatirme (por que ya no puedes) has decidido que me vas a acusar de mantener esta postura por que sólo se trabajar con javascript. Me parece un adhominem horrible y me parece de mucha bajeza intelectual.
Dicho esto, programo en C, C++, javascript/typescript, Rust, GO, Java, Python, Perl, PHP, Bash y lo que me echen, ya que mi trabajo no me suele permitir el lujo de centrarme en un solo martillo. No como te pasa ti, que culpas al martillo de todo.
Yo, como uso todos los martillos todos los días, pues entiendo bien que el problema no son las herramientas, sino la arquitectura/diseño, como es evidente cuando le das un par de vueltas
Y ahora te reto a contraargumentar lo que he escrito en mis comentarios previos, en lugar de atacarme sin argumentos.
oradarhoradarPartiendo de la base de que por la propia definición de lo que significa enrevesado, es algo subjetivo, porque lo que es fácil para unos puede no serlo tanto para otros, tengo que decir que lo siento pero no, para mi Java no es más enrevesado que C. Según tu definición de enrevesado el lenguaje menos enrevesado es el ensamblador, que tiene un número de instrucciones relativamente pequeño a partir de las cuales puedes construir cualquier cosa en comparación con el resto de resto de lenguajes.
Que sí, que ya se de que va todo esto, que se que estas discusiones se terminan demostrando que uno es la polla en comparación con el resto de mortales y decir que C es tu lenguaje de cabezera y que es supersencillo de utilizar te da un aura de superioridad. Pero es que a mi eso me da mucha pereza y tampoco tengo la necesidad de demostrar nada.
¿PHP? Por lo que hice hace doce años. PHP es muy lioso y además arrastraba errores y malas decisiones de diseño entre diferenes versiones. Era realmente complejo navegar entre la documentación. Recuerdo cuando con exactamente el mismo código a veces salían errores y a veces no, esto solo lo he visto en PHP,en Actionscript 2 y en Visual C++ con Visual Studio 95 que era una fantástica película de terror.
En la época ni siquiera tenía lambdas, no sé si las tiene ahora (podría buscar pero prefiero reconocer mi ignorancia). Y daba un poco de rabia, porque se abría un munto de asincronismo en el que PHP no entraba.
En general, al menos entonces, comparar PHP con cualquier lenguaje moderno le dejaba en mal lugar. Alguien le dijo una vez, como chiste, a los compañeros de soporte, "como ponga un punto y coma te jodo la vida"
Sin embargo, permíeteme que lo reconozca, me he dejado llevar por el chiste fácil. Hace una década que no toco PHP ni creo que lo toque más.
No, C ser, lo que es el lenguaje, se aprende echando ostias, en pocos dias. Lo que pasa con C es que no lleva de la manita al desarrollador, pero tampoco se le pone en medio. C es puro y duro "esto lo que hay", y en esa faceta es brutal para lo bueno y lo malo. No achaquemos la dificultad de tener que saber de algoritmos, del SO y de la maquina, al lenguaje. Y tampoco achaquemos facilidades de tener una cojolibreria que te da de todo, cosa que pasa en otros lenguajes, al lenguaje.
Rigor, que estamos mezclando cosas. C es simple y escueto, y muy rara es la vez que hace algo de manera oculta, poco intuible, etc., muy rara la vez que entorpece la labor del programador.
Y esto solo lo pueden decir C, el ensamblador ( que requiere saber mucho mas ) y quiza pascal y alguno mas, pocos.
Como conducir sin cinturón de seguridad o sin casco.
De hecho he visto a quien ha decidido trabajar con Kotlin transcompilando a JS porque también le da cosa y prefiere que un lenguaje/entorno dicte ciertas normas.
Ahora, no seré yo el que diga que es mala idea. Puede que sea el lenguaje más flexible hoy en día y cosas serias hechas con JS... a patadas.
Solo mis dos céntimos.
Sub-millisecond max pause times
Pause times do not increase with the heap, live-set or root-set size
Handle heaps ranging from a 8MB to 16TB in size
¡Joder!
Dios me libre de llevar esos proyectos
Si claro. Intenta hacer algo en java sin un postgresql u oracle que te ayude, ya verás que divertido, eso si, usa una silla comoda.
Tu sabes la cantidad de datos que mueve una BBDD decente. Son de los software mas optimizados que existen.
Anda que no hay otros orientados a objetos y con sintaxis más liviana.
Luego ves algo bien hecho en Symfony o Laravel y se te quita la tontería.
Java no es de pago. La especificacion es abierta, cazurro. Por eso cualquier empresa grande se crea su JVM custom q solo con eso ya barre a cualquier otra tecnologia en servidor. Por no hablar de la performance. Node, PHP?? ... lo intentaron. .NET es la copia cutre de MS de la JVM.
Quien coño usa MS para desarrollar?!?
Más allá de esto sí, el juego de instrucciones en lenguaje ensamblador es relativamente pequeño comprado con todas las llamadas que puedes hacer con cualquier lenguaje como C o Java, te pongas como te pongas. Cuando quiera comparamos todas las llamadas a la última API oficial de Java con el juego de instrucciones de cualquier arquitectura X86.
Yo soy del litoral, aquí pantanos hay, pero tampoco tantos
Si quieres saber pq se usa java mira alguna pagina seria de benchmarking. Java se cepilla a casi todo excepto C++ y algun rust.
debería convertirsese convertirá en el lenguaje para programar… EN JAVA. Es tremendamente superior. 100% interoperable. Ninguna desventaja.Yo no vuelvo a Java ni aunque me paguen el doble.
Bueno, recruiters, por el doble puede que sí
Lo que he dicho, esque las bases de datos suelen ser de los principales cuellos de botella en una aplicación que sea medianamente decente. Pero eso no es una crítica a las bases de datos, es una mención de que cambiar el lenguaje del backend "por rendimiento" es absurdo, ya que el propio servidor python/node no suele ser el cuello de botella.
La solución a esto que dices, suele ser typescript. Typescript es un superset de javascript que se transpila de forma limpia y directa a Javascript. Es simplemente javascript + tipos. El validador/compilador de typescript verifica los tipos, y luego ya genera JS normal, stripeando los tipos.
Es una solución de Microsoft, y es bastante popular hoy en día. Además tiene una cosa buena, y es que puedes usar tipado en zonas críticas, y dinamismos en zonas menos críticas, manteniendo una interoperatibilidad completa, ya que Typescript es en el fondo javascript + tipos, por lo que puedes usar el código de Javascript en Typescript, y el código de typescript en javascript, de manera directa, sin mucha indirección que complique el diagnóstico/depurado.
Yo estoy de acuerdo en que Javascript, sin tipos (es decir, sin typescript) es un suicidio para cualquier cosa que requiere un mínimo de seguridad/mantenibilidad. Pero también pienso que hoy en día, cuando la gente dice Javascript, se refiere generalmente al combo Javascript/Typescript, por que son interoperables.
También creo que mucha gente cuando piensa en Javascript, está pensando en Javascript de los 90, y desde ES6 las cosas son mucho mas serias. Ya hay clases y todo lo que esperarías encontrar, y casi todo lo que era "the bad parts" ya lo han ido deprecateando.
Si me dices C++, rust, o go te lo compro aunq no me gusta la sintaxis y le veo carencias en temas de testi g y calidad.
debugar y corregir un error de una aplicación que usa un framework y que el error se produce cuando ya ha finalizado la ejecución de tu código.
Wow, buen comentario y ademas razonado. Y como mencionas, es cierto que la mayoria de la gente desconoce como usar LAMBDA
>> Aunque es controvertido, y quizás tienes razón.
Para hacerlo mas controvertido, el corolario de mi comentario es que la mayoria de los "programadores" usan una metodologia funcional pura ...
Ninguna web seria que no pete usa Java. La administración española y sus consultoras subcontratadas pues sí lo usan, y así funciona siempre todo.
... y JVM tb tiene optimizadores JIT.
Y si usas framework el tema de la programación funcional a traves de proxys es magia negra budu.
A mi me gusta empezar por un main que yo vea y sienta y saber por donde voy línea a línea. Eso en java es casi imposible si usas frameworks. La deprabación del uso de "magia negra" (anotaciones, xml, reference, proxy, funciones autoinvocadas por alguien que no soy yo), etc es bestial.
En cuanto a compadecimientos, nada mas lejos de la realidad, las toneladas de mierda, a nivel tecnico y no tecnico que se ahorra uno trabajando en cosas de bajo nivel comparado con esos entornos y lenguajes del infierno... por no hablar de que, quitando honrosas excepciones, no hay vida ni chicha fuera de esas excepciones, aburrimiento es poco decir.
Vale. Eso te lo compro. te habia entendido mal.
Pero he visto codigo que el cuello de botella era el patan que hacia 10.000 insert uno a uno y le echaba la culpa a la BBDD. O que realizaba 10 select simples independiente en vez de ejecutar 1 select completa para obtener todos los datos. (Siendo el tiempo de las select simples y completa similar).
Con el balcón cerrado me atrevo.
1. C++ es la ostia.
2. Hay muchas libs de java hechas en java y la propia JVM esta hecha rn java.
Hace tiempo estaba hecha en C++ pero eso se cambio. Si la propia JVM esta hecha en java no hay razon para q otras librerias no lo esten salvo q quien las haga decida hacerlas en C++
3. Python es tan rapido como una piedra.
Yo, para back, estaría más tranquilo que "solo" con un lenguaje fuertemente tipado. O para móviles. De hecho estaría bastante más tranquilo en móviles si hubiera algo que controlara aún más y te dijera "¡esto rompe Android 10!" . Igual existe ya, si no existe ojalá hubiera tiempo porque quizás no es tan complicado como proyecto de matar el tiempo como extensión de Android Studio.
En front web no creo que haga falta más. Al fin y al cabo ves los cambios en tiempo real.
menuda sarta de cuñadeces propias del que no tiene ni idea y habla de oídas.
No es comparable a java. Como ya te han dicho el equivalente es C#.
Php es brutal para hacer cruds, Asp ni eso.
Lo de Python, la mayoría de usuarios no necesita el extra de velocidad que les podría dar C++.