edición general
180 meneos
10344 clics

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.

| etiquetas: desarrollo , software , sorpresa , lenguajes , programación , premio , honorífico
73 107 2 K 279 tecnología
166 comentarios
73 107 2 K 279 tecnología
12»
  1. #101 --630082-- *
    #97 Tambien se usa en Blockchain mucho, así como AI y VR (Unreal Engine esta que lo peta).
    0 K 6
  2. apetor #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...
    1 K 16
  3. apetor #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.

    www.youtube.com/watch?v=VSlBhAOLtFA
    2 K 19
  4. #104 --630082-- *
    #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.
    3 K 33
  5. box3d #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 xD
    0 K 8
  6. #106 --630082--
    #39 No confundes con PL/SQL?
    0 K 6
  7. #107 --287400--
    #106 no, el sql puro y simple puede hacer todo lo que he dicho.
    1 K 12
  8. #108 --630404--
    #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.
    0 K 7
  9. apetor #109 apetor
    #105 Simplicidad no es cutrez... Para mi, la frase es: C es simple y NO SE PONE En MEDIO.
    0 K 9
  10. apetor #110 apetor
    #104 Genericidad si, pero con cabeza, que el 90% no se usa y contribuye al mierdon.
    0 K 9
  11. #111 --630082--
    #108 Hay varios factores, C# no se consulta tanto porque el propio IDE ya te da casi todo lo que necesitas para rellenar.
    0 K 6
  13. perro_marron #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 :palm:
    0 K 6
  14. bitman #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.
    1 K 17
  15. #115 --625430--
    #2 Go es lo que C++ debería haber sido desde el principio.
    0 K 7
  16. #116 --625430--
    #6 Joder, con lo facil que es el 6502, pa qué coño vas a usar cc65. Si me dices el Z80, pues vale.
    0 K 7
  17. #117 --625430--
    #16 WASM NO es para sustituir a JS.
    0 K 7
  18. #118 --625430--
    #50 WebAssembly no va a sustituir a JS, NO ES su trabajo. WASM no accede al DOM.
    0 K 7
  19. #119 --625430--
    #63 Qt es C++.
    0 K 7
  20. diskover #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.
    2 K 28
  21. #121 --625430--
    #31 No, C++ cambia bastante sobre C. Código que tira en C te petará en C++ y viceversa.
    0 K 7
  22. #122 --625430-- *
    #120 Ya ví proyectos como los de La Churrera, para juegos simples pues OK, pero no me imagino un Gradius con CC65.

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

    Hay IDEs cojonudos para 6502 y librerías ASM.
    0 K 7
  23. #123 --625430-- *
    #77 Go le ha desbancado en esa tarea.

    #82 En Linux puede, OpenBSD no tiene tantas. Solo 331.
    0 K 7
  24. diskover #124 diskover
    #122 Precisamente Gradius no le veo ningun problema para desarrollarse en CC65.

    Igual te podía dar algun quebradero de cabeza algo como Battletoads, por poner un ejemplo.
    0 K 10
  25. #125 --625430-- *
    #124 La secuencia de los volcanes/meteoritos no sé no sé, en cuanto a tema de sprites.

    Bueno el BattleToads y otro shooter plataformero que no recuerdo y que también exprimia la cacharra.
    0 K 7
  26. #126 --194262--
    Seguramente estos datos del número de búsquedas sea también por estudiantes, ya que C es de lo que más se enseña en universidades.
    0 K 10
  27. #127 mcfgdbbn3 *
    #123: A veces los profesores prefieren C++ a C por la mayor facilidad para manejar vectores o las funciones cin y cout respecto a printf y scanf.
    0 K 10
  28. #128 --625430-- *
    #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:

    gotour-es.appspot.com/#1

    EDIT: Tutorial online español.
    3 K 23
  29. #129 mcfgdbbn3
    #128: Vale, gracias. :-)

    De todas formas, si tiene la filosofía de C, deberían haberlo llamado de alguna forma similar a C, por ejemplo Cgo, C-go o algo por el estilo, como C++ y C#, del que yo nunca me imaginé que ese # significaba "dos incrementos" (son cuatro mases ++ ++), pero además, es una referencia al sostenido en música (que eleva el tono), de hecho C# es una nota musical, en concreto un tono de 277.183 Hz. :-P xD

    Al final son tantos lenguajes de programación (tal vez más que criptomonedas), que aclararse de cual es cual se vuelve complicado. :-/
    0 K 10
  30. #130 --625430-- *
    #129 Bueno, Plan9 es Unix, pero no Unix, si no su evolución cual Pokémon. Go en cuanto a C lo mismo, no es C, pero cogieron lo mejor que pudieron, lo simplificaron al contrario que C++, cogieron la filosofia de compilación cruzada para tontos de C en plan9 para Go, e hicieron un lenguaje mal llamado "pa tontos", puesto que tiene ideas cojonudas para escribir lo menos posible.

    Ejemplos en el C de plan9:

    Compilar un programa para amd64:
    9c cosa.c
    9l -o cosa cosa.9

    Compilar para ARM:
    5c cosa.c
    5l -o cosa cosa.5

    En Go:
    GOARCH=arm go build ex.go
    GOARCH=amd64 go build ex.go
    Obviamente si ya estás en ARM o AMD64 no hace falta poner nada, solo "go build loquesea.go".
    1 K 17
  31. diskover #131 diskover
    #125 No habría ningun problema ¿que problema le ves al tema de sprites?
    0 K 10
  32. #132 --625430--
    #131 Tema de rotar y mover los tiles en memoria, en ASM es mucho más rápido.
    0 K 7
  33. diskover #133 diskover *
    #132 Con las librerias actuales (como la NESlib de Shiru, por ejemplo) no tiene ningun problema.
    0 K 10
  34. musg0 #134 musg0
    #118 WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
    Para mí están diciendo que en un futuro puedes mandar javascript a la mierda y escribir código para la web en cualquier lenguaje para el que haya un compilador, que el navegador leerá y procesará el código wasm. Que actualmente no se pueda prescindir totalmente de javascript es normal. No puedes ponerte a correr antes que andar con todo el desarrollo actual que depende de javascript, pero el paso lógico del wasm es prescindir de javascript como lenguaje único para la web
    0 K 7
  35. Caresth #135 Caresth
    #119 Creo es originalmente para C, también vale para C++. Yo utilizo el QtPy que funciona con Python, pero cada vez que tengo que buscar una propiedad o cómo se hace algo, acabo en un ejemplo de C
    0 K 10
  36. #136 --625430--
    #135 No, QT es C++ desde siempre. No hay QT para C.
    0 K 7
  37. #137 --625430--
    #134 No, WASM no puede acceder al DOM, que es la web que estás viendo.
    0 K 7
  38. Caresth #138 Caresth *
    #136 Tienes razón. Ahí se ve que no distingo el C del C++ en los ejemplos :-D
    0 K 10
  39. musg0 #139 musg0
    #137 Ahora no puede hacerlo (lo de andar antes de correr de mi comentario), pero que yo sepa le están dando vueltas al tema, así que no creo que sea un imposible. Y si por alguna razón deciden en un futuro usar para algunas tareas siempre un enlace con Javascript por debajo, conque el compilador lo tenga en cuenta y abstraiga al programador de eso ¿Qué más da si no tienes que usar javascript al programar?
    0 K 7
  40. #140 --625430-- *
    #97 Habia JVM's muy peladas pero ya no se usan, como Kaffe JamVM.

    Hubo más: en.wikipedia.org/wiki/Mika_VM
    0 K 7
  41. #141 --625430-- *
    #101 Si eres programador en QT, C++ es ta casa sí o sí. Y en videojuegos y consolas es lo que hay, con C# en segundo lugar para juegos indie del store de la Play, XBOX o similares.
    0 K 7
  42. Conde_Lito #142 Conde_Lito
    #4 Donde esté Fortran o Ada...
    1 K 30
  43. Conde_Lito #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.
    en.wikipedia.org/wiki/Instruction_set_architecture#/media/File:Mips32_
    0 K 11
  44. #144 --625430--
    #143 Un intérprete de binarios Linux escritos en MIPS se puede realizar en dos patadas incluso en Perl.

    blog.schmorp.de/2015-06-08-emulating-linux-mips-in-perl-1.html
    0 K 7
  45. #145 tusko
    #62 Eres tú un Dios??
    0 K 10
  46. Conde_Lito #146 Conde_Lito
    #144 Y de cualquier otra arquitectura, normalmente el ASM de cualquier arquitectura es una traducción literal a máquina.
    Yo por ejemplo normalmente, dependendiendo que programa y que micro, veo más claro algo programado y programar en máquina que en ensamblador, comprendo mejor el funcionamiento del programa y del microprocesdor/controlador y de toda la circuitería asociada.
    Esto seguramente sea porque soy electrónico y no informático, con lo que me entiendo mucho mejor a nivel de hardware que de software. {0x1f605}
    1 K 18
  47. #147 --625430-- *
    #146 Jo, pero ASM está bastante ligado a codigo máquina, al menos sabes dónde y como va a escribir cada registro, si te sabes en los flags que actúa.

    El tema en ASM es comentar cada linea.

    Por cierto, programar para la vectrex con vectores en el 6809 es infinitamente más sencillo que hacer un juego similar para el CoCo o similares con igual CPU.
    1 K 18
  48. #148 --8899--
    #145 Si algo he aprendido en el cine, es a responder a esa pregunta con un "sí" :-D
    1 K 21
  49. Conde_Lito #149 Conde_Lito
    #147 El ASM no es que esté muy ligado al código máquina, es que es código máquina escrito de forma abreviada y memotécnica.
    Aún así yo veo mucho más claro ver las tensiones que hay en cada pata de los integrados y las que le tienes que meter, cosa que con ensamblador no ves a menos que te sepas de memoria los opcodes y el formato que tienen las instrucciones del micro en cuestión.

    Programar para la Vectrex será más fácil por las capas de abstracción que tendrá la propia máquina, date cuenta que estas máquinas llevan un programa metido en varias EPROMs o similar que define los aspectos de la consola.
    Es como programar un x86 para un IBM PC o compatible o para otro cacharro con un firmware diferente a BIOS. Aun siendo el mismo micro la programación puede ser totalmente diferente a nivel de hardware, interrupciones, acceso a memoria, etc., a menos que programes directamente sobre el propio micro saltándote el firmware, si es que este permite hacer tal cosa en su totalidad.
    2 K 25
  50. #150 --625430-- *
    #149 >El ASM no es que esté muy ligado al código máquina, es que es código máquina escrito de forma abreviada y memotécnica.

    Bueno algunos compiladores permiten macros y saltos :-P

    Sobre la Vectrex, si, tiene una BIOS, y editar la fuente de la ROM es trivial.
    1 K 18
  51. Conde_Lito #151 Conde_Lito
    #150 Los macros y saltos es ya cosa del compilador, pero yo creo que programar para estos compiladores no se le podría llamar ensamblador, es parecido, es una derivación, y es prácticamente igual, pero... no es igual. xD :shit:

    De todas formas una gran mayoría microprocesadores/controladores también permiten saltos a la hora de programarlos en máquina, mira el opcode jmp en los x86 por ejemplo. en.wikipedia.org/wiki/JMP_(x86_instruction)
    Estos ensambladores lo hacen un nivel por encima del de máquina, o sea sobre el propio programa, luego el compilador lo que hace es pasar directamente a la línea que le has marcado con el salto y traducir a partir de esa línea obviando todo lo anterior, de ahí que sea igual pero no sea igual. xD
    2 K 25
  52. #152 --625430--
    #151 Sí, el tema de labels para los saltos, pero aparte.
    1 K 18
  53. #153 --164239--
    #115 no, resuelven distintos problemas
    0 K 6
  54. comadrejo #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.

    benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are
    www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fo
    1 K 13
  55. #155 --630082--
    #141 Se de sobra lo que se emplea en videojuegos, es mi sector desde hace unos años, y C# se usa mucho más de lo que piensas.
    0 K 6
  56. #156 --630082--
    #121 No veo por qué C debería petar en C++, aunque tampoco hago experimentos en el trabajo.
    0 K 6
  58. #158 --625430-- *
    #155 Soy usuario de OpenBSD. Todos mis juegos comprados de Steam usan C# de algún modo, y tenemos un port de fnaify mucho antes que Linux, donde es un wrapper para convertir y adaptar todos los juegos de XNA a FNA. ¿Que decías?

    github.com/rfht/fnaify

    Nuestros juegos se reducen a source ports, emulacion (hasta la Wii, RPCS3 tira pero necesitamos una QT más reciente, la PSP con PPSSPP tira perfecta desde hace años) y juegos con C#.

    Nos falta .Net core, pero poco a poco.

    Por cierto, el programa que usamos para bajarnos juegos de Steam también usa C#, "depotdownloader".
    0 K 7
  59. #159 --630082--
    #158 Decía que los videojuegos es mi sector profesional. Evidentemente no es el tuyo. Te molesta?
    1 K 13
  60. #160 --625430-- *
    #159 No, son los sistemas, pero conozco bien el uso de C#, es lo que hay si queremos jugar a algo "reciente". No me molesta, al contrario :-P

    EDIT: Si acaso me molesta no tener un port de .Net Core 2.0, que es el futuro y que Unity va a tirar hacia eso de forma nativa sin wrappers/juegos en C++, añadiendo más juegos en mi SO favorito.
    0 K 7
  61. #161 --630082-- *
    #160 Y yo lo decía más por Unity. Hay muchos juegos y VR hechos así, incluso para consola. Y no es que me guste el intrusismo "scripter" pero es lo que hay.
    1 K 13
  62. #162 --625430--
    #161 No, sí Net Core tiene un rendimiento muy decente, como Go. Al menos no es la mierda de Java. Dicen GraalVM y demás, pero hasta que no vea el JPCSP tirando los juegos de la portátil de Sony a la misma velocidad ultrasónica que PPSSPP, donde con un Celeron y una Intel Mobile 4 Series tiras casi todo con 1 de salto de frames, no me creeré nada.
    0 K 7
  63. #163 --630082--
    #162 Gente que sabe más que yo dice que Mono es peor que Core pero es ya otro tema.
    1 K 13
  64. #164 --625430-- *
    #163 Bueno, el último Mono en realidad ha cogido todo lo de Net Core, no estamos en el 2008.

    Lo mismo con OpenJDK11, tiene parte del AOT de Graal
    0 K 7
  65. bitman #165 bitman
    #157 no has entendido nada de lo que te he dicho. Si A es un conjunto y B pertenece a A... ¿podemos decir que B pertenece a A?
    0 K 7
  66. Shyish #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.

    // www.jetbrains.com/lp/devecosystem-2019/kotlin/
    0 K 6
12»
comentarios cerrados

menéame