La sorpresa en la lista de los lenguajes de programación más utilizados del año

Una vez más, el índice Tiobe, que se basa en la popularidad de búsquedas de los distintos lenguajes de programación en Internet, ha otorgado el premio honorífico de lenguaje de programación más importante de 2019 y también ha lanzado la lista de los más utilizados a enero de 2020. En lo que respecta al premio honorífico del lenguaje de programación más importante de 2019, contra todo pronóstico, ha recaído en C a pesar de contar con 48 años desde su implementación.

[#19 box3d]

De todos esos lenguajes, solo... C, ASM? Pueden ser compilados "freestanding" (sin runtime, sin sistema operativo, sin nada) sin perder demasiadas características.

Mientras esto siga siendo así, C no morirá.

[#43 llorencs]

#19 Pregunta de ignorante, como se puede compilar sin sistema operativo?

[#44 box3d]

#43 compilar para ejecutarse sin sistema operativo.

[#51 box3d]

#43 ya no puedo hacer

editado:

..
Cuando compilas freestanding, El programa se ejecuta 'tal cual' sin necesidad de tener un sistema operativo debajo y sin necesidad de librerías externas ni nada. Esto te limita bastante algunas cosas (generalmente no tienes acceso a ficheros, redes, etc...) pero te permite que puedas compilar para prácticamente cualquier máquina, por cutre que sea, y te permite controlar el acceso al hardware sin muchos impedimentos.

Que ventajas tiene esto? Pues entre otras, te permite escribir sistemas operativos, drivers, firmware, programar en máquinas con pocos recursos...

[#79 Desactivado]

#43 La compilación debe de hacerse con un compilador en un sistema operativo. A lo que se refiere el compañero es a sacar un fichero a la salida del compilador que la CPU pueda "entender" sin necesitar nada más.

Cuando tú en C usas la función read para leer un fichero realmente le estás diciendo al sistema operativo lo haga por tí, y él lo hará de la forma en la que esté programado. A ésto se denomina "llamada al sistema". En una compilación freestanding esto no se hace, y además, si no me equivoco (corregidme si está mal), no se encapsula el código en una estructura que le da información adicional al SO, como es el caso del icono del programa en Windows (que va dentro del .exe sin ser código).

[#86 box3d]

#79 puedes tener ejecutables freestanding dentro de un ELF o un COFF o lo que quieras. No es obligatorio sacar un binario "plano" pero es muy habitual que así sea.

[#67 apetor]

#19 Tambien rust, aunque ahi ahi.

[#84 box3d]

#67 pierdes todo lo que dependa del runtime de rust, que no es poco. En eso se parece a C++, que "funciona" sin apenas runtime si estás dispuesto a perder funcionalidades. Por ejemplo intenta hacer un try/catch sin el

En C no pierdes nada en lo que lenguaje se refiere, solo librerías.

[#96 apetor]

#84 Bueno, puedes meter una libc minima y hacer que el resto funcione con eso y no requiera nada mas de un SO. Yo hago cosas para UEFI ( y es mas, no solo UEFI, sino que usando solo alguna cosa ultrabasica, digamos que hago bare metal ) en C y hay peña que hace cosas del estilo en rust con una capa minima que tira en bare metal.

editado:

hay binding para musl libc, creo recordar. Musl libc es una libc minima para linux, pero se puede adaptar facil a bare metal.

[#105 box3d]

#99 #96
Es como usar C++
Tienes disponible "más que C" pero bastante menos que C++ completo. En el caso de C, por lo "cutre" que es, no pierdes nada. Y esta cutrez es su fuerte

[#99 apetor]

#84 http://www.randomhacks.net/bare-metal-rust/

[#143 Conde_Lito]

#19 El ASM normal que pueda ser compilado de la misma ya que es una traducción literal a código máquina.
Una instrucción en ensamblador la puede pasar a máquina cualquiera sin esfuerzo alguno en unos segundos.

En este ejemplo que hay en la wikipedia se puede ver perfectamente el tema.
https://en.wikipedia.org/wiki/Instruction_set_architecture#/media/File:Mips32_addi.svg

[#21 casius_clavius]

Lo del C es porque en los últimos meses he tenido que rehacer un proyecto antiguo y como no tenía ni puta idea he copado yo solito las búsquedas en interné

[#63 Caresth]

#21 Apúntame a mí al carro, que me he puesto a hacer una aplicación con Qt + Python y en todas las búsquedas de Qt acabo en páginas de C.

[#119 Desactivado]

#63 Qt es C++.

[#18 TiJamásLlevaTilde]

#16 Recomendar a alguien que estudie cuando tú mismo has escrito "callendo"... ejem, ejem, como que no. O igual te referías a hacer la calle, a prostituirse... y en ese caso no tengo nada más que decir.

[#15 RubiaDereBote]

#13 Que no tío, que no te enteras.
Para hacer algo con webassembly no puedes usar cualquier lenguaje. Hay un subconjunto muy reducido que compila a webassembly, encabezado por Rust.
Y cuando dices que se programa en javascript porque no hay otra alternativa tampoco es cierto. Si te refieres a programar para un navegador web hay infinidad de alternativas, como coffeescript, typescript, ... y un montón más. Que se ejecute javascript no significa que tengas que programar en javascript.

[#16 gonas]

#15 chavalin, estudia antes de decir gilipolleces.

[#17 RubiaDereBote]

#16 has demostrado no tener ni idea y aun así sigues igual de ignorante pregonando tus desdichas. Haz el riduculo todo lo que quieras, pero a mí no me molestas más. Al ignore que vas.

[#27 musg0]

#17 #16 estáis diciendo cosas parecidas y pegandóos por los detalles como si os fueran a dar un premio. No sé cuál de los dos me parece más imbécil

[#38 Desactivado]

#27 tú, por decir que dicen "cosas parecidas" cuando dicen todo lo contrario.

[#50 musg0]

#38 ni de coña porque los dos dicen cosas que son verdades a medias. Y a ti ya te conozco cuando vas de troll, así que pasó de discutir, que no venía a eso

[#54 Desactivado]

#50 ah perdón, no sabía que estaba hablando con el mismísimo poseedor de la verdad.

Mis disculpas.

[#74 RubiaDereBote]

#50 ¿Verdades a medias? ¿Pero de qué guindo te has caído? Uno dice lo que no es, y el otro le corrige de forma fulgurante

[#81 musg0]

#74 uno dice que en webassembly se pueden programar en todos los lenguajes, menos en JavaScript, porque se ve claramente que no le gusta, no porque no se pueda. El otro dice que no, que sólo en los que tengan compilador (obvio) y luego se pegan porque para navegador puedes programar en coffescript, typeacript, Python o lo que te salga del coño siempre que haya un traductor a javascript (que no es cómodo andar recompilando en cada cambio del fuente así que es normal no considerarlos lenguajes "web") y entre todo eso que si subnormal, que si estudia, que si no sabes leer, cuando realmente y bajo mi punto de vista lo que están diciendo es muy parecido

[#87 RubiaDereBote]

#81 No, hazte un favor y lee todo bien hasta que lo entiendas. Mientras tanto estás mintiendo y creando un ruido inncesario.

[#88 musg0]

#87 Pues no me contestéis

[#118 Desactivado]

#50 WebAssembly no va a sustituir a JS, NO ES su trabajo. WASM no accede al DOM.

[#117 Desactivado]

#16 WASM NO es para sustituir a JS.

[#62 Desactivado]

#47 Antes de nada quiero avisar que lo que voy a decir lo se "de oídas", por lo que tómalo con mucha sal...

La NES lleva un procesador basado en 6502, y su diseño hace que se adapte bastante mal al lenguaje C. En general, los procesadores de 8 bits tienen bastantes limitaciones (entre ellas el tener pocos registros, y que el juego de instrucciones es poco ortogonal) que hacen que el código generado sea bastante pobre, pero en el caso del 6502, al tener una pila relativamente pequeña y limitada a 256 bytes lo hace especialmente problemático. Yo trabajé hace tiempo desarrollando un pequeño proyecto para el Spectrum usando el z88dk, que tiene un compilador de C "optimizador" para Z80, y acabé pasando y escribiendo directamente en ensamblador las partes que requerían máximo rendimiento, porque el código de bucles y demás era bastante malo, así como el uso de punteros para acceder a la memoria de vídeo. Y eso que en el Z80, con su pila de tamaño "ilimitado" y registros índice, el código de las llamadas era relativamente aceptable.

Algunas de las fuentes de lo que digo:

https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code

https://www.xtof.info/blog/?p=714

https://www.cc65.org/doc/internal.txt

[#70 Desactivado]

#62 Al menos los ensambladores del Z80 y del 6502 son lo suficientemente simple, en número de instrucciones y registros, y direccionamientos, como para poder hacer algo medianamente eficiente sin haber tenido que estudiarlo mucho. En x86 me sacas del direccionamiento directo y los 20 mnemónicos más usados y necesito el manual al lado sí o sí.

[#145 tusko]

#62 Eres tú un Dios??

[#25 Desactivado]

Menuda sorpresa!! El lenguaje que lleva 20 años siendo el primero o segundo, ante todo pronóstico está primero!

Lo llamaremos C, el Numancia Fútbol Club de los lenguajes.

[#29 foxaxel]

#25 Lo que es un lenguaje bien hecho cojones. Los demás pasarán C perdurará.

[#30 Desactivado]

#29 tiene sus problemillas, pero desde luego que su nicho de mercado siempre estará ahí.

[#31 Desactivado]

#2 #3 #25 #28 Este estudio da lugar a engaño, todo programador C++ hace "consultas" sobre C. Pero aún así está programando en C++.

[#66 apetor]

#31 Ya, pero no olvides que una gran parte de programadores de C++ programan ficheros .CPP pero lo que hay dentro es C con clases y poco mas, y por cierto, haciendo POO peligrosamente forzada.

[#100 Desactivado]

#66 Si, la gente lo mezcla todo. Por eso a mí me gusta declarar cada variable del namespace std explícitamente.

[#102 apetor]

#100 Ojala fuera solo eso. Me refiero a mierdas donde se fuerzan constructos por que si, por no hablar de patrones de disenyo, que tambien se fuerzan bien forzados. Y eso, mil capas, interfaces y su puta madre en aras de una autoenganyada genericidad que nunca se usa, siempre aberra y bueno, muchas cosas mas...

[#108 Desactivado]

#31 Este estudio solo me sirve para saber en que lenguajes el personal tiene menos idea y necesita hacer mas busquedas para copiar el trozo de codigo pertinente de stack overflow.

[#121 Desactivado]

#31 No, C++ cambia bastante sobre C. Código que tira en C te petará en C++ y viceversa.

[#76 mcfgdbbn3]

#25: Sorpresón en Los Pajaritos.

[#55 Desactivado]

He visto que la empresa Tiobe que elabora esta estadística se basa mucho en las búsquedas en motores de búsqueda. A mí me parece una medida muy sesgada, la verdad. Se me ocurre, por ejemplo, que C puede salir muy beneficiado porque al ser un lenguaje más completo la gente se dedica más a buscar resolver problemas y dudas.

https://www.tiobe.com/tiobe-index/

[#72 anv]

#55 Ah, entonces php aparece muy abajo porque la página oficial de php tiene un manual buenísimo y no hace falta usar motores de búsqueda...

[#75 Desactivado]

#72 bueno es casi como dices: el php lo aprende un mono pajeándose al mismo tiempo. No quiero ofender, es así.

python también. Pero da la casualidad de que python se usa mucho más en proyectos actuales.

Sólo he dicho que creo que el criterio que utiliza la empresa del artículo puede ser muy sesgado. No estoy negando nada.

[#85 solotexto]

#75 Gracias por ofenderme. Pero llevo programando PHP desde la versión 4, y un mono podrá hacer 4 cosas contadas, alguien experimentado hace bastante más.

[#91 abuelillo]

#85 Pues realmente a mi no me parece una ofensa, que un lenguaje de programación pueda ser aprendido por un mono sería más bien una virtud.

[#92 Desactivado]

#85 yo también llevo ya añitos y reconozcámoslo lo mejor de PHP es que cualquiera puede programar en ęl...
Y justo eso es también lo peor... Cualquiera puede programar en él y así sale el código a veces

[#77 mcfgdbbn3]

#55: Y es el preferido para aprender.

[#123 Desactivado]

#77 Go le ha desbancado en esa tarea.

#82 En Linux puede, OpenBSD no tiene tantas. Solo 331.

[#82 Desactivado]

#55 Efectivamente. Sólo debido a errores de sintaxis y a parámetros especiales del compilador C se puede llevar muchas más preguntas que el resto, y usa si metemos llamadas al sistema (que es imposible saberlas todas de memoria) de los diversos sistemas operativos apaga y vámonos.

[#94 Desactivado]

#82 Las llamadas al sistema no son específicas de C. Las puedes hacer casi en cualquier lenguaje.

[#6 diskover]

Cuando quiero hacer cosas para la NES con el compilados cc65, escribo mis programas en C.

[#11 Shinu]

#6 Yo para eso me creo una interfaz gráfica en Visual Basic.

[#45 impaler]

#11 Hehehe, por si alguno no lo captó:

[#53 Desactivado]

#45

BAIA

[#47 Desactivado]

#6 Pregunta de novato: Cómo de rápido/eficiente funciona un código escrito C en la NES? Tenía entendido que tiene un hardware muy limitado y si necesitas exprimirlo has de irte a ensamblador, pero claro, para aplicaciones sencillas, desde luego puede ser lo más sencillo...

[#120 diskover]

#47 No hay nada más eficiente que el ensamblador, si o si.

No obstante puedo corroborar que la programación en C, gracias al compilador CC65, esta bastante bien optimizado y no me ha impedido hacer virguerías varias. Mucha gente hoy en día incluso hace juegos completos y con toda la complejidad que te de la gana.

Tambien es cierto que todo esto tiene la ayuda de librerias escritas en ensamblador que te dan funciones que te facilitan mucho la vvida luego en C.

#116 Es por falta de tiempo el no poder ponerme a ello.

[#116 Desactivado]

#6 Joder, con lo facil que es el 6502, pa qué coño vas a usar cc65. Si me dices el Z80, pues vale.

[#2 perro_marron]

No me extraña. C++20 llega a un punto de frikismo que ya es inmanejable.

[#28 foxaxel]

#2 Joder que lástima haberme separado de C++. C++11/14 era la ostia, qué ha pasado?

[#113 perro_marron]

#28 ha pasado que "concepts" y "modules" en vez de #include y volatile redefinido y las lambda han cambiado y muchas otras cosas destructivas.
Mi favorito es que funciones constexpr ahora pueden tener try/catch

[#64 apetor]

#2 C++ nacio "inmanejable".

[#93 j0seant]

#64 C++ es un lenguaje complejo, no está a la altura/alcance de todo el mundo (y más hoy en día en el que no se valora tanto la optimización y se busca el mínimo esfuerzo aunque al final las soluciones sean mediocres), pero al integrar C te permite hacer cosas de manera sencilla mientras sigues aprendiendo.. y teniendo en cuenta que prácticamente los compiladores e intérpretes de casi todos los otros lenguajes de la lista están hechos en C y/o C++, además de todos los sistemas operativos actuales y todos los grandes programas que siguen siendo desarrollados en estos lenguajes, yo diría que es una complejidad bastante agradecida. Al final esa complejidad hace de filtro algo que en el fondo es de agradecer

[#95 apetor]

#93 Hace de filtro >> el problema es que C++ no hace tanto de filtro y sin embargo si provoca que mucha gente haga monstruos arquitectonicos que son un mierdon para mantener. Y no es que sean dificiles de mantener por requerir conocimientos de C++, sino por que son arquitecturas innecesaria y absurdamente complejas y demas basura.

[#104 Desactivado]

#95 #102 Estoy convencido de que hay gente que ofusca código a posta, para asegurarse trabajo fácil en la empresa.

Lo de las capas me recuerda a un ex compañero que se dedicaba a hacer "wrappers" para todo. Los diseñadores encantados con él, por supuesto, aunque su trabajo no sirviese para nada.

Eso sí, la genericidad no es mala y tener una buena estructura y arquitectura es importante. Pero no es algo que cualquier mindundi pueda hacer.

[#103 apetor]

#93 Mira, no soy, de momento, ningun flipado de rust, sigo siendo muy de C, pero al menos rust quita mucha mierda de C++, no solo de morralla aberrante del lenguaje, sino incluso del concepto, no es una POO forzosa.

[#115 Desactivado]

#2 Go es lo que C++ debería haber sido desde el principio.

[#7 Desactivado]

La sorpresa fue Ook!

[#59 Jakeukalane]

#57 lo mío era un comentario amistoso puesto que me pasa a veces con esa palabra. Por otro lado WebAssembly se asocia mucho actualmente con malware de criptominado en el navegador.

[#4 ctrl_alt_del]

Bah, nada como el COBOL.

[#58 BananaAnanda]

#4 El COBOL son los padres!

[#78 Tom__Bombadil]

#4 Poco se habla del COBOL. Luego bien que hacen transferencias.

[#142 Conde_Lito]

#4 Donde esté Fortran o Ada...

[#56 gonas]

#46 Aquí tienes un ejemplo de como acceder al DOM desde Blazor. Y a las Web API's se accede sin ningun problema.

https://github.com/kevinjpetersen/BlazorQuery

[#23 capitansevilla]

# REXX sigue siendo el rey

[#41 Desactivado]

Y Java el primero... Lastima ser pobre y no tener dinero para comprar mas RAM.
Solo los CRUD cuentan para esa lista o que?

Y no se como PHP no esta mas arriba, cuando toda la web esta en PHP y con la version 7 es muchisimo mas rapido que Java y que casi C o ensamblador.

[#60 bitman]

#41 que ensamblador lo dudo. Todo termina traducido a código máquina. Y quitando cosas como las extensiones Jazelle en algunos ARM todo lenguaje de alto nivel tiene que ser traducido a C/M.

[#68 Desactivado]

#60 Busca benchmarks y veras

[#89 bitman]

#68 no hace falta buscar benchmarks sobre ejecución de código. Todo lo que se codifica en alto nivel se termina compilando a bajo nivel.
El problema del código máquina es que pierdes toda la abstracción de los lenguajes de alto nivel y programar algo medianamente complejo se vuelve impracticable.

[#90 Desactivado]

#89 Si bueno, demuestralo con un benchmark

[#114 bitman]

#90 en serio, no se trata de demostrar nada. El código máquina es tan rápido como cualquier lenguaje de alto nivel compilado y sustancialmente más rápido que cualquiera interpretado. Cuestión de lógica. Si todo el código se traduce a CM, ya me dirás cómo CM podría ser más lento...
Otra cosa es que me digas: hazme un algoritmo determinado en Python y en ensamblador. Ahí dependerá de la pericia del programador que pueda o no resolver con éxito el trabajo.

[#71 anv]

#41 Diría que Java está primero porque es lo que más se usa para programar para Android.

con la version 7 es muchisimo mas rapido que Java y que casi C o ensamblador.
Eeeehhh, no te pases. ¿ensamblador?

[#73 Desactivado]

#71 Java no se usa en Android desde hace tiempo ya

[#80 Desactivado]

#41 ¿Más rápido PHP que C? Permíteme que lo dude.
Cuando tenga tiempo hago el mismo código en C y PHP, un generador de números primos, y veo cuál tarda más y cuál tarda menos

[#154 comadrejo]

#41 #80 PHP es un caracol comparado con por ejemplo rust, C o incluso java bien llevado.

Si adicionalmente utilizas "relentizadores" como symfony tendrás la sensación que vas marcha atrás.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=yyj0ji-f

[#42 llorencs]

Cofeescript, typescript no son más que subtipos/dialectos de Javascript.

[#61 Desactivado]

#c-42" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3234681/order/42">#42 Aplicando esa lógica, Java y C# son dialectos de C.

[#3 Desactivado]

Juntas en una misma lista Ensamblador y Python. Lista basada en busquedas. Bien.

[#33 Desactivado]

pues yo no lo considero una sorpresa

[#34 Desactivado]

#13 No has programado nada (ni ejecutado) en WebAssembly en tu vida.

[#36 mr_b]

La sorpresa es D, que está en el 17 y lleva entre los 20 primeros un par de meses o tres después de más de 10 años de desarrollo.

Por cierto, D es una verdadera maravilla, especialmente su programación genérica (templates o generics, como queráis).

[#1 otrohastalasnarices]

Me sorprende JavaScript bajando

[#8 gonas]

#1 A ver si sigue callendo. WebAssambly, se lo va a ventilar en menos de un año.

[#12 RubiaDereBote]

#8 Ya te aseguro yo que no. Webassembly es un formato de código binario, nadie programa en webassembly.
Se programa en otro lenguaje y se compila a webaseembly.

[#13 gonas]

#12 Se programa en el lenguaje que te de la gana. En cualquiera menos en JavaScript. Ahora se utiliza JavaScript porque no hay alternativa.

[#22 JusticiaParaMAG]

#13 Con permiso... aquí dice que no se lo va a ventilar: https://www.itdo.com/blog/webassembly-puede-sustituir-javascript/

[#35 Desactivado]

#22 Que lo diga en un blog de no se sabe quien no significa nada. Y mas en la epoca de Medium, donde el mas tonto suelta gilipolleces sin tener ni idea para ganar algo de visibilidad.

Lo he abierto y he leido 2 cosas, esta parte es mi favorita:

¿En qué tipos de proyectos puedo usar WebAssembly?
Mejora de rendimiento. Si tu proyecto está relacionado solamente con el manejo de datos numéricos y necesitas que los cálculos complejos se hagan de forma rápida, WebAssembly es tu herramienta.
Código ofuscado. Si algún cliente tuyo desea ver el código de su aplicación ofuscado en el navegador, gracias a los módulos de WebAssembly lo puedes hacer.


Me estoy partiendo de risa aqui solo en mi casa

[#26 Jakeukalane]

#8 cayendo. Ya me cuesta escribirlo bien a mí, como para encima leerlo

[#57 gonas]

#26 #40 #52 ¿No teneis nada más inteligente que aportar?

[#112 Desactivado]

#57 danos tu dirección y te mandamos un diccionario si te parece

[#32 Desactivado]

#8 lo que dices es como decir que Python, Java o C caerán porque ya existe el lenguaje ensamblador

Si alguien puede aspirar a desbancar a Javascript son otros lenguajes de alto nivel, gracias a que pueden compilar a WebAssembly. O TypeScript. Pero pocos escenarios veo en los que pueda salir a cuenta programar directamente en WebAssembly.

[#40 llorencs]

#8 Callendo? En serio? CaYendo con Y

[#46 mariomka]

#8 Mientras no pueda llamar directamente a las Web APIs o tener acceso al DOM no va a sustituirlo.

[#52 Desactivado]

#8 ke vien heskrivir!!!

[#128 Desactivado]

#127 Si echas un vistazo a Go verás que tiene la filosofía de C, que son los mismos creadores, pero mejorado. Los channels y la concurrencia son la hostia en verso. Compilar cruzadamente para Windows o Linux/ARM/RISC o lo que sea instalando el paquete "go" en OpenBSD, es magia. No depende ni de compiladores cruzados de C/C++ ni nada.

Si quieres te paso el "The Go programming language" en privado.

Aunque tambien tienes esto online, en castellano:

https://gotour-es.appspot.com/#1

editado:

Tutorial online español.

[#24 Ormuzd]

Yo no sabia que las busquedas SQL se consideraran un lenguaje de programacion.

[#39 Desactivado]

#24 pues lo es. El sql no son sólo búsquedas, tiene diría que prácticamente todos los elementos que puedas esperar de un lenguaje de programación: variables, procesos condicionales, iterativos, funciones, etc...

Eso sí, no es un lenguaje de programación de propósito general, es evidente que está intrínsecamente especializado en trabajar con bases de datos.

Como es lógico es un lenguaje interpretado pero aún así dependiendo del servidor que utilices el propio servidor es capaz de optimizar vistas, stored procedures y cosas así para que se ejecuten mñás rápidamente.

[#106 Desactivado]

#39 No confundes con PL/SQL?

[#49 impaler]

#24 Quizás a T-SQL se le podría considerar, aunque realmente no sea un lenguaje de programación al 100% (es más un juego de extensiones de programación), pero sí que tiene declaraciones y funciones que se pueden utilizar para que se ejecuten procedimientos y así obtener resultados específicos. En los procedimientos almacenados se pueden crear procesos, con envío de parámetros y con estructuras complejas como si fueran funciones hechas en un lenguaje de programación estándar.

[#10 Desactivado]

Sorpresa por qué

[#48 mariomka]

Por qué sigue existiendo Visual Basic

[#98 SeriousBig]

Donde este el lenguaje de ensamblador q se quite todo lo demás

[#5 gan]

Lo sorprendente es la subida de Swift, cuando el 99% del desarrollo de este se enfoca al iPhone, mientras que Kotlin ni aparece en la lista.

[#9 Zade]

#5 bueno, Swift lleva ya mucho tiempo bien asentado en iOS y no consiguió superar a ObjC en esta lista hasta prácticamente ahora. Kotlin dando fuerte de verdad en Android lleva poco más de un año. Casi todo el desarrollo Android de esa lista está aglutinado en Java, que imagino que bajará en función de lo que suba Kotlin en los próximos años.

[#65 Desactivado]

#5 Me he hecho la misma pregunta. Acabo de darme cuenta ahora mismo en el trabajo mientras buscaba algo en google.

No busco "blablabla kotlin", lo busco para Android. Si los demás hacen como yo, lo lógico es que muchas búsquedas de desarrollo en kotlin no estén cuantificadas.

Total, a mí me da igual que mi solución me la den en Java o en Kotlin.

[#166 Shyish]

#5 Es cierto que Kotlin lleva más tiempo en el mercado que Swift pero ambos se anunciarion como oficiales relativamente a la vez para sus respectivos ecosistemas, por lo que la principal diferencia es cómo funcionan ambos ecosistemas de Android e iOS.

Al ser iOS un sistema cerrado y al controlar su principal entorno de programación (IDE) tienen mucha más libertad para forzar más fácilmente el uso del lenguaje, libs y demás que quieran. En el caso de Android con Kotlin, el crecimiento por ahora está siendo bastante alto y se está viendo mucho esfuerzo por parte del equipo de Android en promocionar el lenguaje, por lo que habrá que ver este año si cambia el panorama.

// https://www.jetbrains.com/lp/devecosystem-2019/kotlin/

[#14 Macharius]

No veo COBOL en la lista

[#20 snosko]

#14 Eso será porque en las encuestas los que se lo llevan calentito de los bancos nunca ponen que mantienen código en COBOL.

[#37 Desactivado]

#20 Esa lista no esta basada en ninguna encuesta

[#69 anv]

#14 El otro día, pensando en los pajaritos, me estaba preguntando... cuando llegue el 2070, a quién le tocará arreglar los parches que se hicieron al software en cobol para el efecto 2000 que consistían en asumir que si el año era menor que había que sumar 2000 y si era menor, 1900?

Y ojo, no es que me queje de ese software. Estoy seguro de que es mucho más confiable que cualquier programa hecho por becarios de alguna consultora.

[#83 Razhan]

#69 igual no tienes ni que esperar tanto para ver gente arreglando parches del efecto 2000:

https://rt.cpan.org/Public/Bug/Display.html?id=124787

[#97 Desactivado]

C/C++ vuelve porque hay un sector en alza donde optimizar importa, en todo el tema iot volvemos a tener micros de 8 bits, o sistemas arm con muy poca memoria y que encima queremos que no gaste energía de más. Metedle una jvm a eso si teneis cojones

[#101 Desactivado]

#97 Tambien se usa en Blockchain mucho, así como AI y VR (Unreal Engine esta que lo peta).

[#140 Desactivado]

#97 Habia JVM's muy peladas pero ya no se usan, como Kaffe JamVM.

Hubo más: https://en.wikipedia.org/wiki/Mika_VM