Vi esta imagen en la página de Facebook 'El Arte de la Programación' y me gustó bastante. Me sorprende como juegos de la GameBoy Color ocupaban tan poco con la buena calidad y jugabilidad que tenían, y lo largos que eran.
Portada
mis comunidades
otras secciones
Comentarios
La verdad es que es muy interesante. Los programadores de antaño estaban más relacionados con la programación de bajo nivel, o un alto nivel pero directamente compilable, sin pasar por "entornos virtuales". Ahora están de moda estas virtualizaciones y y los lenguajes interpretados, por lo que requieres más potencia de cálculo para hacer lo mismo y, sobretodo, muchísima más memoria RAM y disco.
Se podrían hacer programas que ocupen poco espacio en entornos virtuales como Java, pero ya requieres ese entorno. To do se complica.
Yo recuerdo el Prince of Persia 1 que ocupaba nada menos que un disquete de 3 1/2 de baja densidad (720K) y me lo pasaba super bien en un PC de 640KB de RAM (también funcionaba en 512KB de memoria menos la consumida por el S.O.).
#1 El problema son los frameworks. Para una aplicación de chichinabo, si quieres programarla rápido y a un presupuesto bajo, tienes que tirar de frameworks y librerías externas. Entonces esa aplicación que normalmente sería un puñado de ficheros de pocos kb cada uno, termina teniendo decenas de miles de ficheros.
Y si resulta que la aplicación es grande, también necesitas librerías y frameworks porque facilitan el mantenimiento, los tiempos de desarrollo y a veces incluso el cliente exige la tecnología que desea.
#1 #3 Leeros esto:
https://tonsky.me/blog/disenchantment/es/
Al que me adhiero totalmente.
#3 uno de los problemas.
Otro, es que no se considera, ni se tiene en cuenta, en fase de diseño o de implementación ningún aspecto de rendimiento o consumo de recursos.
"Eso ya se irá ajustando" es la frase clave.
Y ahora con los contenedores, peor. 'Ya si eso metemos más réplicas" está causando estragos.
Cuando llegas y te pones a explicar a un Junior que hay ciertas cosas que comprometen el consumo de memoria, es como hablarles en klingon. Si ya te metes en algún tema de concurrencia de hilos y deadlocks les pierdes más allá de toda esperanza.
Y hablo de programadores de back. Si nos pasamos al front, la cosa empeora y mucho, sin que haya ningún motivo que de verdad justifique esa falta de interés.
Como siempre: son generalizaciones y como tales, un poco injustas: estoy seguro de que aquí nadie es así, y todos los javeros del lugar os conocéis la estructura de la VM, y todos los de JavaScript entienden la gestión de hilos en Node y tal.
#3 Tranquilo, para ésto hay una solución que se llama Cloud: AWS, GCloud, Azure, ... En el momento en que te toca pagar directamente las ineficiencias es cuando ves que realmente necesitas optimizar y crear mejor software. A las empresas les va a pasar lo mismo, tendrán dos opciones: crear un software muy bueno y muy caro pero que tendrá poco coste operativo en la nube o crear un software nada óptimo mucho más económico pero por el que tendrá que pagar mes a mes un coste operativo alto.
#3 Y el problema es? Los discos duros van baratos y el tiempo es dinero.
La complejidad, tamaño, necesidades de escalabilidad, la cambiabilidad del entorno (SO, Libs, Drivers, Hardware)... no tienen nada que ver con las que había antes. LAs App de antaño son juguetes en entornos ultraestables en comparación con las actuales que han de ofrecer una resiliencia infinitamente mayor.
#3 Estoy en completo desacuerdo. Cualquier aplicación medianamente compleja hoy en día se hará con un Framework (o como algunos se denominan ahora "MicroFrameworks") , sea este público o inhouse, pero un Framework al fin y al cabo (de hecho serán muchas veces varios si hay microservicios).
El problema, aunque prefiero verlo como la causa, es que las aplicaciones de hoy son monstruosamente grandes, han de ser altamente escalables y lo más mantenibles que se puedan hacer, todo estoy limitados por el tamaño de los equipos que no puede irse de madre.
Otro debate que sí me parece más interesante y realista es el de buen Framework vs mal Framework, que si creo que limita lo optimizada que pueda estar la aplicación.
El objetivo de un framework es ofrecerte un entorno en el que los problemas que tiene el 90% de las aplicaciones ya estén resueltos y dónde puedas conectar las partes que resuelven los casos de tu negocio.
Un buen framework te ofrecerá formas de limitar su aparición a la capa más externa de tu proyecto (ej: capa HTTP, Manejo del DOM, Routing...) un mal framework te obligará a hacer las cosas de una manera e infectará tu aplicación hasta lo más profundo.
Un buen framework te ofrecerá modularidad y posibilidad de no incluir el código que no necesites (ej: Tree Shaking).
Un buen framework te ofrecerá una IoC atractiva porque tiene unas interfaces solidas y bien definidas, además de un buen sistema de inyección de dependencias permitiendo que tu codigo esté libre de detalles de implementación (lenguaje, frameworks y libs es lo que son, detalles de implementación).
Un buen framework se encargará de adaptarse a los cambios de esas capas de infrastructura (HTTP, Window API, APIs del lenguaje, libs de sistema) minimizando el impacto que pueda tener en tu aplicación. Esto hace precisamente que, si no es un proyecto de chinchinabo, puedas centrarte en lo que te hace viable: tu capa de negocio sin necesidad de decicar tanta cantidad de esfuerzo a todas esas capas externas y comunes a todas tus aplicaciones (seguridad incluida).
También podríamos hablar de como se usan en muchas ocasiones los Frameworks, que algunas personas no terminan de entender que NO son librerías.
#6 Pero el problema ahí es de análisis y diseño de la solución, no el framework en sí, el problema es de quien decide que ese framework y ese lenguaje son los correctos para dar solución a determinado problema. Es como si yo diseño un sistema de seguridad en aviones con Visual Basic, el problema no es el lenguaje, es la elección.
Si no se entiende que el lenguaje, el framework y en general toda la infrastructura es un detalle de implementación y que ha de ser elegido pensando en el producto a implementar... ningun framework o lenguaje serán buenos. Es como usar Java para un SO, mientras Java puede ser una buena elección para implementar Servicios SOAP, nunca lo será para implementar un SO, pero el problema no será Java, será de quien lo eligió para implementar esa solución.
De todas formas siempre hay excepciones y creo VS Code, no parece siquiera Electron, me sorprendé muy gratamente siempre que lo uso.
Me metí aquí creyendo que por fin podría salirme del monotema y la política y ahora quiero volver...
El 90% de los comentarios parecen escritos por gente que no conoce la industria del software. Pero voy a intentar arrojar mi rayito de luz sobre el tema.
- Cuando entras en un proyecto, no escoges framework, lenguaje o tecnología. Solo unos pocos tienen tales privilegios. Así que #3, tienes razón a medias. En la vida real no existen las aplicaciones de "chichinabo". Ergo los frameworks son una consecuencia derivada del mercado al que se enfrenta la industria. El espacio y la ram son muy asequibles hoy en día. Se puede ver como "hacer un puente de acero cuando a lo mejor si fuese de madera soportaría el peso requerido". Hoy sí, pero mañana igual no. El precio que pagas por el framework es por curarte en salud cuando vengan "las nuevas especificaciones".
- El odio a Javascript y todo el ecosistema a su alrededor es común en las redes, pero marginal entre los expertos. #6 citaba tres aplicaciones, y pasaba de lo particular a lo general de forma muy discutible. Se le olvidó hacer mención a Visual Studio Code. Escrito en TS/JS, corre sobre electron (node) y desarrollado por ni mas ni menos que microsoft. Es el mejor IDE que he utilizado, y la lista es larga. Mira si es bueno, que el motor intellisense de Visual Studio que tanto nos mola se ha migrado a node.
- #1 toca un tema interesante. Los lenguajes interpretados comenzaron su auge en el contexto de la multiplataforma. Compilo una vez (a bytecode) y lo ejecuto en cualquier PC, móvil, cafetera o dispositivo que soporte el runtime de Java (JRE). Esto fue especialmente importante con la llegada de Android, entorno en el que mayoritariamente se programa en Java. (Muy a mi pesar por que creo que el lenguaje es un truño). ¿Por qué ahora JS lo peta si ya estaban ahí la JVM de java y el CLR de .Net? Si a alguien le interesa respondo contando mi punto de vista.
- #85 en mi opinión pone un poco los pies en la tierra. Lo verdaderamente triste es que hoy en día, enfrentarte a un proyecto supone asumir unos plazos imposibles, y los clientes, ya muy inmersos en la era digital, tienen muy poca tolerancia a fallos. Especialmente a aquellos que detienen el sistema parcial, o totalmente. Por eso es necesario utilizar herramientas que te permitan hacer el trabajo de forma rápida y segura. A veces esto te obliga a tomar ciertas decisiones, como la de utilizar muchas bibliotecas de código por que ya están testeadas. Pero eso no quiere decir que el resultado tenga que ser malo, ni mucho menos.
Volviendo a los juegos de game boy, la comparación es absurda. El cliente final ya no se conforma con música de 8 bits y 160 × 144 píxels. Ahora lo que vende son los reflejos súper realistas del agua, ciudades tan grandes que tal vez no llegues a recorrerlas enteras, cada uno de los edificios debe parecer real, los pedestrians deben tener una IA súper avanzada y saber cuando cruzan la calle, las explosiones nosecuantos, las físicas newtonianas y así podría seguir hasta el infinito. Por eso ahora necesitas cosas como Unreal Engine que ya de por sí es enorme y consume muchos recursos.
Esto al final se puede transportar a los frameworks, lenguajes y lo que se os presente. Es que el mundo entero tiene nuevas especificaciones.
#3 El problema son los costes. Hoy en día, cualquier juego necesita mucho personal. Incluso tirando de engines ya hechos, librerías de recursos ya hechas, arte ya hecho, hacer un juego es un esfuerzo importante de tiempo y dinero. Si además quieres unos valores de producción altos, el presupuesto se dispara.
Antes un equipo de una docena de personas te hacía un AAA en relativamente poco tiempo; en los ochenta, meses y siendo la mitad de personas. En los noventa, si se era técnicamente ambicioso quizá se tardaba algo más (digamos de uno a dos años, tres a lo sumo si la cosa se desmadraba) y normalmente se construían sus propios motores casi siempre. En los dosmiles, para terminar un juego en ese intervalo de uno a tres años necesitabas un equipo muy grande, cohesionado y bien dirigido, partiendo como mínimo de algún tipo de middleware y normalmente con un engine completo ya funcional.
Ahora, los últimos call of duty o assasins (que son productos digamos prefabricados, donde el molde "ya está hecho" y se construye a partir de ahí) necesitan no uno, sino varios estudios trabajando codo con codo para sacar los proyectos adelante.
Por otro lado, antes tenías un hardware simple: una serie de registros, unos chips que configurabas y programabas adecuadamente y aprovechar los recursos de la máquina, no había más. Era muy fácil programar (una curva de aprendizaje al principio elevada, eso si) porque tenías acceso directo a todos los recursos, todo lo que hacías tenía coreespondencia directa con el hard. Más adelante, se programaba en sistemas que no controlabas directamente, tenías que tirar de drivers y de llamar al sistema operativo. Ya las cosas no eran tan directas, no todo funcionaba en todos lados, había complejidades extra y ya tenías que tirar de liberías escritas por ti o por otros. Ya los programas no son tan pequeños, tenían que arrastrar un buen puñado de funcionalidades que no se usaban pero que venían en esas librerías. El siguiente paso son los engines, que de ser especializados en según qué tipo de juegos y por tanto muy ligeros, empezaron a engordar para poder ser muy flexibles y abarcar todo tipo de aplicaciones. Hoy en día puedes hacer un juego con unreal engine para móviles donde sólo el engine ocupa más que juegos completos en cdrom de los 90. Pero es el precio a pagar por el que cualquiera pueda desarrollar un juego y publicarlo.
#3 No para todo hace falta un framework. Un programador experto debería tener los suyos propios, muy específicos y de pico peso.
El problema es el uso de.frameworks de.propósito general
#3 Frameworks............
Un programador de verdad usa mariposas
#1 Un lenguaje como TCL/TK o Jimtcl no ocupa una mierda, es una VM y es bastante rapido.
Y por cierto, sobre entornos, la maquina virtual Z (Zork, Curses y otros) rulaba hasta en un Spectum +3.
#9 Abuse (que también es de disparos pero a alienígenas) funciona sobre TCL/TK
#12 Creo que va sobre Lisp.
#13 Cierto
#1 el Príncipe de Persia era una maravilla programada en ensamblador; pero para programar en ensamblador hay que ser informático, no basta un becario con un cursillo.
https://github.com/jmechner/Prince-of-Persia-Apple-II
#62 Al contrario. Para programar en ASM es más facil que C++ con las templates y aprendiendo cosas como mutex y semáforos.
#71 mutex y semáforos hay en C. ¿A qué te refieres exactamente?
#75 que asm es mucho mas sencillo.
#75 Eso es sencillamente falso, compañero. De hecho, es el motivo por el que existen C y C++. Por que el ensamblador era un infierno.
Ahora vendrá alguien a responder que programar en código máquina es mas fácil que en ensamblador...
#176 El comentario #75 que cito en mi respuesta.
#71 Si te refieres a que existen más herramientas para el desarrollador en C++, sí. Si te refieres a que es más sencillo en ensamblador que en C++ hacer el mismo programa, ni de broma.
En ensamblador puedes decirle exactamente a la CPU qué instrucciones ejecutar, y controlar entradas y salidas de forma directa, pero para ello necesitas un conocimiento absoluto tanto de la parte interna de la CPU como de los periféricos que estén conectados a ella.
Ésto en una Atari, un Spectrum, un Amstrad, un Commodore, es relativamente sencillo, por usar CPUs con pocas instrucciones y con pocas I/Os, pero a día de hoy en una CPU medianamente moderna es inabarcable.
Incluso para programar muchos microcontroladores y DSPs potentes de la actulidad, lo normal es al menos usar una HAL proporcionada por el fabricante, y si hay que usar ensamblador en una región crítica, se mete en la función de C/C++ donde sea necesaria y santas pascuas.
#71 hasta aquí he llegado.
Demasiado internet por hoy, ya.
#71 ni de broma, en mi opinión.
C y c++ es un paseo por el bosque del edén comparado con ensamblador.
#62 El tema es que hacer algo como Prince of Persia en ensamblador ya es una locura, pero si pretendes hacer algo mucho más grande y complejo como se hace ahora es directamente inviable.
#62 También te digo una cosa, yo como adolescente de los 90 me vicié al ensamblador empezando por el maravilloso arte del cracking y pasando a cosas más complejas, y luego al llegar a la facultad tardé en pillar para qué querías variables locales a funciones y por qué no les molaba que todas fueran globales
#1 no estoy solo...
Yo con el tiempo he flipado de que juegos como ese o Pinball Fantasies, Monkey Island, Lemmings, Golden Axe, Eye of the Beholder, Budo Khan, Stunts, Battle Chess y bastantes más que me dejo en el tintero funcionaran decentemente en un triste 8086 a 10 mhz y 640 k de ram que heredé de una oficina... Entonces sí se optimizaban a tope los juegos, vaya que sí...
#1 La diferencia es que antes la memoria y la capacidad de procesado costaba más que el tiempo del programador, ahora es al reves. Es así de sencillo.
#1 Los programadores de Spectrum si que eran buenos, con 48K de memoria hacían unos pedazo de juegos increíbles. Y encima en aquella época había un buen número de empresas españolas de videojuegos triunfando en todo el Mundo, igualito que ahora.
Made in Spain, Opera Soft, Zigurat,...
https://es.wikipedia.org/wiki/Edad_de_oro_del_software_espa%C3%B1ol
#1 Bueno, pero es que es parte del progreso. Hoy en día disponer de 1gb es más barato que 1Mb, según el año que elijas. Y tirando dos líneas de código puedes hacer cosas que en 1996 no se podían ni imaginar, y ni siquiera haría falta ser un experto.
O Doom, que corría en cualquier máquina.
#2 No es cierto. El Doom, cuando salió, necesitaba una máquina doméstica con ciertas prestaciones. De hecho, dudo mucho que corriera en máquinas sin coprocesador matemático o con poca RAM. En un 286 creo que no tiraba, porque recuerdo a compañeros de la universidad quejarse de que en su ordenador no iba.
#2 #5 Ostras, es que Doom ya era un pepinazo de juego, son palabras mayores incluso el 1 (y nunca me ha gustado). Antes que Doom deberías buscar el primer tipo de juego de ese estilo: Wolfenstein 3D (que tampoco me convenció por el estilo de juego), que si no recuerdo mal también requería un 386. Eso sí, creo que sin coprocesador.
De hecho, y aunque reconozco que alguno sí jugué y me pudo entetener, nunca me gustaron los juegos de disparos.
#10 Yo me pasé el Wolfestein 3D en mi 386 SX, que no tenía coprocesador, y tan solo 1 Mb de RAM. Pero el renderizado de Doom era mucho más vistoso, tanto en texturas como en iluminación, y requería más potencia de cálculo. He hecho una búsqueda rápida por internet sobre los requisitos mínimos de Doom, pero no los he encontrado.
#14 Minimo un 386 SX como el tuyo seguro pero si no recuerdo mal ya quería 4MB de RAM. Eso sí, para un 386 deberías reducir la ventana al tamaño de la mitad de la pantalla. Vamos, Injugable, porque su resolución además creo que era VGA de 320x200 a 256 colores. Para jugar "bien" ya pedían un 486 y con gráfica VL-Bus (un salto de rendimiento bárbaro).
#28 #25 #15 Bueno, lo he encontrado. Pinchad en la foto.
#34 Mira, clavado. 386 (recomendado 486) con 4MB y VGA. Pero cuidado, que si vuelves a jugar tu cerebro puede sufrir un duro revés, retroceder varios años de tu vida y quedarte enganchado ahí de por vida...
#37 Yo lo instalo otra vez cada 2 o 3 años. Es un juegazo. Me pasa que intento mirar para arriba y abajo para apuntar a los bichos que están a otra altura
#25 El Doom no requería un 486 (goto #34). En un 386 DX se podía jugar bien.
#15 Aquí un servidor se pasó el Wolfenstein 3D cuando salió (allá por el '92) en su Amstrad 80286 con 1 Mb de RAM. Eso sí, recuerdo que en algunos momentos el equipo se quedaba más tieso que la mojama por falta de recursos para mover semejante monstruo para la época, pero la experiencia de jugar en 3D compensaba de sobra (con ese equipo también me pasé enterito el Wing Commander 2, aunque este aún era más tocho, ergo, aún más paciencia para jugarlo)
#5 Te lo confirmo. Tuve un 286 un 1MB de RAM y Doom no funcionaba. Wolfenstein 3D si, aunque en mi caso tenía que bajar un poco el tamaño de la pantalla para que los fps fuesen aceptables (si recordais, con las teclas ' y ¡ se cambiaba el tamaño de la pantalla que renderizaba la cámara).
#10
#40 #48 #63 Cierto, va en un 286. Y no se ve mal, no...
#40 ¿Un Amstrad? ¿Qué modelo? Yo tuve el Amstrad PC3086, que era un XT 8086 a 8MHz pero con una gráfica brutalmente buena, una Paradise (quizá la misma que la tuya). Qué bien me lo pasé con ese ordenador.
#69 Mi Amstrad era un PC2286/40 a 12'5 Mhz, 40 Mb de disco duro y 1 Mb de RAM, comprado en un Pryca en el año 90 por 150 mil pelas de la época. Me dió muy buenos resultados hasta que se me quedó anticuado y pasé directamente al primer Pentium a 120 Mhz que salió al mercado (y que parecía un 747 despegando por el ventilador de la CPU)
Era este modelo de la foto.
#73 Te envidio. No lo tendrás ya, ¿no?
Que digan todo lo que quieran de si la envidia no es buena. Me da igual.
Ese ordenador lo tuvo un amigo mío de Barcelona, de mi infancia, que era un poco más mayor que yo y vivía cerca de mi casa. Le puso una Sound Blaster ASP y lo conectó a su equipo de música. De mi XT a 8 MHz a su (bueno, tu) 286 era un cambio notable. Pero eso me hizo investigar más sobre mi propia máquina y descubrí que también era de 16 bits. Igualmente, la diferencia con procesadores 286 era tirando a altita.
PD: Realmente, como ciertamente la envidia no es buena, reconozco que cada uno vive la situación que marca su destino. Estoy contento con lo que tengo y tuve, y agradezco mucho la máquina que pude tener en mis manos. Pasé por placas 286 al cabo de bastante tiempo pero no fueron Amstrad sino otros modelos (las puse entre maderas en mi caja, ya que no eran compatibles) y eso me hizo descubrir muchísimas cosas.
#2, #5, #10, #157, #40, #63, #56, #20, #23 (y alguno más que se me escapa). Como veo que sois de la vieja escuela como yo, os recomiendo un juego hecho por un solo programador y como homenaje a Doom y todos esos shooters de la época. Lo podéis encontrar en Steam (en GOG está más caro) y se llama Project Warlock. Paradójicamente, es un "soplo de aire fresco" para los que disfrutamos con aquellos títulos antiguos en su época.
#15 iba perfectamente sin reducir nada con un 386 con coprocesador. El descent si que habia que reducir un poco para que fuese fluido.
#14 Al Wolfenstein 3D jugué con un 8086 a 8 Mhz en CGA.
#14 -------------------------------------------------------------
SYSTEM REQUIREMENTS
-------------------------------------------------------------
DOOM(TM) requires an IBM compatible 386 or better with 4 megs of
RAM, a VGA graphics card, and a hard disk drive. A 486 or
better, a Sound Blaster Pro(TM) or 100% compatible sound card
is recommended. A network that uses the IPX protocol is
required for network gameplay.
#14 el 386 tampoco tenía coprocesador. Los coprocesadores eran externos hasta el 486
#10 #5 #14 el Doom necesitaba minimo 386SX con 4MB de RAM y ejecutaba utilizando el DOS4GW para poder utilizar la memoria por encima de los 640k como memoria protegida o algo asi creo que le llamaba.
El Wolfstein creo que funciona hasta en un 286.
#10 No es tanto lo bueno que era el juego, que lo era para la época, sino el talento con el que estaba programado, sin apenas depencias, todo estaba en el core y corria fantásticamente en casi cualquier máquina por pocos recursos que tuviera. Su distribución shareware de las primeras fases en demo, la capacidad de permitir mods de programadores externos y sobre todo el primer modo online potente para varios jugadores (comunicados con un modem) cambiaron internet y la industria del entretenimiento para siempre:
#20 >y corria fantásticamente en casi cualquier máquina por pocos recursos que tuviera
Eh, no. En el resto, de sobra, pero DooM pedia un pepino para la epoca para ir BIEN.
Jugar en tamaño GameBoy no es jugar.
#21 https://www.reddit.com/r/itrunsdoom/
#22 No, te confundes. Hoy en dia existen controladores ARM mucho mas potentes que un i386.
En la época, lanzar DooM bien exigía un buen cacharro. Tener un PC con un 486 de gama media-alta exigía un alto desembolso. Y la RAM era cara de narices.
Si es por plataformas, la Maquina Z se folla a Doom en portabilidad. Tengo el Curses rulando en la primera game boy con un
Z80primo hermano del Z80, y lo puedo jugar perfectamente en cualquier portatil o maquina desde 1982. Como te quedas?#23 Doom lo ha jugado medio planeta durante años, fue pionero en graficos, compatibilidad, capacidad de modificación, concepto de juego y sobre todo modo online, está tan bien programado que se puede hacer correr casi en cualquier CPU desde hace más de 20 años.
Y me quedo con que eres un memo que dices cosas como "se folla" para valorar y comparar unas cosas con otras que no tienen nada que ver. Seguramente el "Alex Kidd" de la Master System (que corria en un Z80) sea más portable tambien que el Doom pero no ha roto los moldes como los rompió Doom.
#29 Teniendo en cuenta que gracias a Zork y Aventure tienes hoy RPGs y juegos con guion, pues no se qué decirte. Rogue nació de un intento de meter Collosal Cave bajo ncurses, y de este derivan muchos de los conceptos de hoy dia.
https://en.wikipedia.org/wiki/Zork
La maquina Z es un predecesor de Java y maquinas virtuales similares.
#30 Y yo te hablo de un producto que sigue vigente tal cual hoy en día. No es solo una caractéristica, la portabilidad, la que se tuvo en cuenta, se tuvo en cuenta todo (arte, concepto, rendimiento, compatibilidad) y se sacó un producto completo que rompió los moldes. Siempre hay un antecendente en el que inspirarse para todo, pero este fue uno de los puntos de inflexión del desarrollo tecnológico, creo un género por si mismo y comenzó a dibujar lo que sería el futuro del juego online.
#c-31" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/31">#31 Lo mismo collosal cave y luego Zork con la maquina virtual Z. Solo que Doom no creo un género, ya existia Wolfenstein 3D.
Sobre vigencia de la maquina virtual Z: https://ifdb.tafs.org, y joyas en 1999 como Anchorhead y Curses, con un guion que se mea en toda la saga de HL y Final Fantasy, los pisotea dos veces y sigue ganando...
En tecnologia, la maquina Z era pionera de compilar una vez y ejecutar donde sea. Y donde digo donde sea, literalmente donde sea. Hasta en boligrafos inteligentes, PDA's, y hasta una FPGA donde implementan dicha maquina en hardware. C#, Java, Smalltalk... dale las gracias a dicha maquina donde rulaba hasta en un C64 en su version 3. Hablo de maquinas con una CPU donde hoy se usa como microcontrolador en teclados.
Se puede incluso crear juegos en castellano con las librerias INFSP el interprete Inform6, que es un lenguaje que compila contra dicha maquina virtual con una sencillez bestial. Puedes crear tu juego con muy poco.
Eso si, a diferencia de los juegos graficos vas a tener que aprender a escribir decentemente. La narrativa cuesta cojón y medio de hacerla bien y de forma sugerente. Sobre todo que no sea ni pastelosa pero tampoco parca.
#31 Perdon, era https://ifdb.tafs.org y
http://www.ifarchive.org/indexes/if-archiveXgamesXzcode.html
http://www.ifarchive.org/indexes/if-archiveXgamesXzcodeXspanish.html
Sobre juegos en castellano recomiendo "El archipielago" como obra narrativa y "Resaca" para descojonarse un poco, que encima es cortita.
#23 Exacto. Yo tenía un 486 dx33 y recuerdo jugar al Wolfenstein pero no al Doom porque no tiraba bien.
#10 Y además de lo que dice #20 es que el salto del Wolfenstein era brutal. Y eso sin ser verdaderamente 3D. Doom incorpora novedades como juego en red y otras que justifican el aumento de requisitos.
Requisitos mayores pero visualmente mejor y con juego en red. Lo que denuncian algunos comentarios como el de #79, que suscribo por completo es que el software ha ganado tamaño sin apenas añadir funcionalidades. Cualquier aplicación de Android tipo "la calculadora" pasa de ocupar unos kilobytes ocupar unos megabytes.
Un editor de texto mínimamente avanzado con resaltado de sintaxis y funciones de búsqueda avanzada ocupan decenas o cientos de megas. El Turbo Pascal ocupaba dos disquetes con las todas las librerías para empezar a programar. Y me refiero a un IDE con librerías y todo el toolchain necesario para generar binarios ejecutables. Un editor de texto sin librerías ni nada ocupa una barbaridad (por ejemplo el notepad ++ portable que utilizo son 22 Megas solo el editor de texto y algunos plugins que vienen con él que jamas es utilizado). Solo utilizo reconocimiento de sintaxis para un par de lenguajes. El instalador de atom para windows 7 y superior son 170Mb. Instalado son más.
Cualquier aplicación de tablet pero que puede ejecutarse en móvil es inmensa porque entre otras cosas trae los assets para ejecutarse en decenas de tamaños de pantalla diferentes. He incorpora librerías de manipulación gráfica cuando solo quieren necesitan mostrar los botones de la interfaz.
Y ese crecimmiento no es como comparar Wolfstein 3D con Doom, o Doom II con Quake. Es comparar en editor de texto con el que vas a editar texto con un editor de texto con el que vas a editar texto con los mismos atajos de teclado. No es comparar Oblivion con Skyrim y este con lo que venga después dentro de un par de años o cuando sea.
#10 si no recuerdo mal también requería un 386
con un 286 bastaba, incluso hay versiones parcheadas que lo hacen funcionar en un 8086
#48 Se nota que ese tío sabe, porque está usando DR-DOS
#10 tiraba el wolf en mi 286 a 16Mhz perfectamente
#5 el doom requería un 486 con 4Gb de ram, el quake ya quería el 486 dx4 pq el compro del dx2 era pelin castaña.
#25 ¿4 gigas? ¿En el 93? ¿No se te ha ido un poco la mano? Si hasta los discos duros de aquella época eran de menos de 500 megas.
#27 Megas perdón.
#25 A mi el quake me tiraba decente cuando subí la velocidad del bus de 33mhz a 40mhz en mi 486dx2
#58 Aghhh y ahora me entero
#25 GB? Seguro?
4Mb más bien.
#5 Puedo equivocarme, pero creo que el DOOM iba en un 386 con 1MB RAM (que era lo normal en esa CPU). El que cuando salio casi nadie podia jugarlo fue el Quake, porque ya necesitaba una CPU capaz de hacer muchos calculos en coma flotante, el Pentium, que en esa epoca pocos tenian.
#28 mi primer equipo era un 386SX con dos megas de RAM y no era nada del otro barrio, me suena más que los habituales con un mega eran los 286
#55 Es posible. Cuando me compraron mi 486 DX2 lo normal eran 4MB, yo le puse 8 porque me lo aconsejaron (en realidad fue un desperdicio de dinero, creo que no le saque provecho y la ampliación costo unas 25.000 pesetas.)
Los Pentium si que salieron con 8MB, que era lo mínimo para que windows 95 fuera bien (yo me espere al 98)
#5 en mi 486 iba de lujo .......pero recuerdo amigos q no le iba muy bien ! (386 )
era un olivetti de este estilo :
https://hipertextual.com/files/2019/03/hipertextual-ordenadores-olivetti-busca-pc-perfecto-2019449161.jpg
#5 El Doom usaba 32 bits, así que por debajo de un 386 no podía funcionar.
#5 Doom podia funcionar en equipos sin coprocesador matematico. Yo lo ejecutaba en mi 486sx a 25, los sx eran 486 sin coprocesador matematico, si querias uno podias comprar un 487 y 'pincharlo' en placa junto al 486.
En mi caso nunca llegue a comprar un coprocesador, pero si 2mb de ram adicionales, puesto que el juego requeria 4mb.
Aqui tengo el doom 2 en su caja original y disketes, menudas viciadas.
#5 Si corría sin copro. El doom original lo jugué yo en mi 386SX (sin copro), lo que si necesitaba eran los 4MB de memoria (no sé cuántos 286 había con 4MB de memoria en esa época). Creo que conseguía que funcionara con 2MB, pero entre que iba a patadones, con tamaño de ventana diminuto, etc...
Cuando vi por primera vez correr el doom2 en una tienda en un 486 con tarjeta de sonido, con esa suavidad y atmósfera y la música cañera era un espectáculo. Probar el doom1 con un equipo donde se arrastraba, se veía enano y el speaker fue un baño de realidad...
#5 el Doom lo vi yo la primera vez funcionar en un IBM PS1 y era un 386
#2 #5 Doom corría en mi 386SX sin coprocesador matemático. Eso si, podías cambiar el tamaño de pantalla (para que tuviese menos resolución) y había que hacerlo, o no se movía. Era simpático tener un monitor de 15" de tubo que se veía todo negro excepto un pequeño recuadro en el centro. No recuerdo qué resolución era eso, pero no creo que pasase de 320 x 240, quizá ni llegaba a eso...
#5 Yo pasé de un 286 a un 486 DX2 y no pude jugar Doom hasta tener el 486.
#2 al Wolfenstein 3D lo vi correr en un 386.
#2 Mentira en mi 086 no iba, hasta que no tuve el 486dx4 no pude jugar
#2 ¿Doom en cualquier máquina? Ni de coña.. necesitabas un maquinón de la época, y si podía ser con una gráfica Voodoo mejor aun.
#0 Ésta también está guapa:
#4 Terry Davis... un individuo curioso cuanto menos.
#39 encontré al HNero.
#4 Terry Davis.
Descanse en Paz.
Y que los negros que brilan en la oscuridad no le persigan en el cielo.
#4 tio, que chiste tan friki, estas muy metido en el tema no?
Lo peor son todos esos "programadores" de javascript que usan ese puto cancer llamado "Electron" porque son unos vagos incapaces de aprender otro lenguaje decente y te meten todo un chromium en cada una de las
aplicacionesbasuras que cagan y por consiguiente consumen recursos como si no hubiera un mañana...Si, me refiero a todos esos "programadores" que han cagado Discord, Slack y Atom por ejemplo.
Sois unos putos mierdas!
#6 Completamente de acuerdo. Hijos de puta.
#7 Por lo menos Ruby ha muerto...
#8 La sociedad del siglo XXI está enferma, es indolente, infantil, estúpida, borrega y se deja llevar fácilmente por los populismos baratos.
Afortunadamente, no lo suficiente como para adoptar Ruby como lenguaje. Cuando lo vi por primera vez, allá por 2004 o así, ya sabía que esa mierda la iban a acabar usando 4 freaks y gracias.
#17 https://www.jwz.org/doc/cadt.html
#17 Debía ser por el 2000 y algo que alguien me dijo que Ruby era el lenguaje del futuro. Y todavía lo sigue siendo.
#8 La mejor definición que he leído
#6 Bien, hablemos de Java...
#c-16" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/16">#16 A mi no me mires, yo programo en C#, que es el hermano buenorro de Java
#c-18" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/18">#18 Discrepo, el hermano buenorro de Java es Kotlin, aunque C# tiene su punto también
#c-43" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/43">#43 Kotlin es el nuevo groovy.
El lenguaje que va a reemplazar a Java, pero que corre sobre Java.
Cambiad a otra cosa, que las hay.
El infame C#, el sobrevalorado Python, el Go...
#c-18" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/18">#18 C# ? Joder, ya no te puedo quitar el positivo de #6
#16 Oracle y java llevan dándome de comer desde que empece a currar así que ojito con meterte con Java!
Oracle es lo puto peor aunque también me de de comer, con ellos puedes meterte
#16 Java la verdad es que es bastante decente, compilado, tipado, se ejecuta en entorno virtual lo que lo hace independiente del sistema operativo, un buen garbage collector.
Tiene antiguedad y comunidad, la interfaz de funciones de java 8 cada vez me permite programar con estilo más funcional y muchas librerías y las nuevas versiones van en esa dirección, no va a ser Haskell pero aceptable.
Si quieres hacer un sistema para que dure Java es una buena opción.
#6 yo, que aprendí a programar con C a pelo sobre una Unix compartida por todo el departamento de informática; y que aprendí a manejar ese Unix empollando por mi cuenta el libro de Pike y Kernighan. Yo, que inicié mi carrera laboral programando con Borland C++ Builder y que denostaba a los que usaban la conio.h. Yo, que hice mis pinitos con TCL/TK. Que analicé pequeños programas Cobol en tarjetas perforadas. Que manejaba punteros con doble indirección como quien come pipas. Yo...
...ahora, hoy día, si me preguntan, digo que "hago webs"; porque me da vergüenza auto-denominarme "programador". He caído tan bajo que dudo que me vuelva a levantar.
Eso sí, aún no metido las zarpas en esos frameworks con un navegador por debajo. Eso ya no me lo perdonaría a mi mismo.
#24 ¿Qué frameworks usas? ¿O no usas nada? No sé si entiendo tu última frase.
La pregunta es en serio. Programo por afición.
#26 para web, ahora uso Laravel.
Con mi última frase me refería a que por ahora he conseguido negarme a hacer "apps" (ejem) basadas en Electron o similares, que básicamente son una web y un navegador privativo por debajo.
#32 usas PHP y te quejas de los de js.
Electrón usa Chromium que es libre.
#24 Eres una deshonra para los informaticos. Ada y Turing se revuelven en su tumba al oir tu nombre
#24 Yo he estado ahí.
Serás feliz en golang.
#42 ahora que están de moda los microservicios y los sistemas headless, quizá sea una opción, a ver si recupero la motivación...
#52 Es que tenemos una carrera muy parecida. Yo también vengo del C y he pasado muchos años en php sobretodo. Y estaba hasta las narices.
Ahora estoy en un entorno donde todo es golang y es una delicia. Como C, pero bien hecho. Rendimiento, poco uso de memoria, programas compilados sin librerías de mierda que no están instaladas en el server.. Frameworks que no cargan nada porque al final son sólo librerías potentes..No hay 200 PSRs para explicarte donde poner un paréntesis.
Ya te digo, si vienes del C y php, golang te encantará.
#53 me lo estás pintando muy bien, tendré que sacar tiempo para meterme con ello. Aunque lo que veo complicado es eso, reorientarme ahora, a mis años... no por mi, sino por "la industria".
#53 #80 Con C puedes usar macros para medio parchear la.falta de genéricos.
No soy experto en Go, ¿pero hay alguna forma de saltarse la limitación?
Aún me cuesta entender por qué a Go le falta funcionalidad tan básica.
#42 Has despertado mi curiosidad, después de muchos años sin picar código quiero volver a retomarlo.
He probado con Python, pero no me termina de enganchar, no le veo utilidad en "mi mundo". Quizás para aplicaciones concretas de Big Data o proyectos de ese estilo puede encajar, pero no es mi caso.
Voy a darle una oportunidad a Go.
¡Gracias!
#24 Conio tío, qué talibán
Seguro que no usabas ni realloc: te copiabas tú a mano los bloques de memoria de un lado a otro. Como los hombres de verdad: qué es eso de dejar que otro haga algo que puedes hacer tú.
#49 le cogí manía a las liberías no POSIX (¿o era no ANSI? ni esto recuerdo ¿ves como soy una vegüenza?) cuando me llegaban cosas que alguien había hecho con el TurboC para que yo las compilase en Unix...
¡Los mallocs a pelo, como los hombres de verdad! ¡Y los garbage collectors son para millenials vagos!
Ains... sí que me gustaría volver a programación más a bajo nivel, más entretenida, pero no veo la forma de reorientar mi carrera a estas alturas. No sé si me veo en un puesto de junior otra vez (y las empresas no quieren a un senior que cambie a otro "sector" para ser junior, a los "reclutadores" les hace sospechar por alguna razón que se me escapa).
#51 Creo que te refieres a POSIX, sí.
Bueno, la primera vez que oí eso del "garbage collector" aluciné. Un entorno que da por hecho que dejas la memoria llena de porquería y que tiene que consumir recursos en recogerla, y que además el propio "collector" puede dar problemas por la frecuencia de ejecución y blablabla: un despropósito que haría vomitar el desayuno a cualquier programador serio de los 80. Estoy poniéndome en el caso de Kernighan y Ritchie, programando UNIX, que está optimizado al detalle, con miles de cuidadosos ajustes para que sea ligero, portable, consistente, uniforme, y que vean cómo una VM Java se come un montón de memoria sólo para ejecutar un cliente gráfico o un editorcillo de texto .
Respecto a tu carrera, lo mismo te puedes dedicar en tu tiempo libre (no es sarcasmo) a desarrollar alguna aplicación que te interese e intentar venderla. Si tienes éxito puedes dar el salto a lo que te gusta de verdad.
#54 #51 Golang está hecho por los creadores de Unix y tiene un GC.
#72 Gracias por sacarme de la ignorancia. No lo sabía.
#54 te agradezco el consejo y los ánimos.
Creo que ese es más bien mi problema: no hay nada que me interese hacer realmente, estoy totalmente desmotivado/quemado/desencantado de la industria. Sigo aprendiendo cosas en mi tiempo libre por gusto, pero una vez aprendo un poco lo abandono porque no me veo con ánimos de ponerme a hacer algo real.
Hace años sí que era muy de "si tal aplicación web no existe tal y como me gustaría que fuese, me la hago yo y listos". Pero ahora estoy desmotivado, y si no existe... pues o uso lo que haya o me olvido del tema.
Qué triste, ahora que lo medito así
#24 ¿Qué pasaba con la conio.h? Por qué no te gustaba?
#24 me has recordado al replicante de blade runner en su discurso final
#24 Veo que hemos tenido trayectorias parecidas, yo tambien aprendi con el famoso "The C programing Languaje", compilando a pelo en un 8086 con monitor monocromo, ahi si que tenia que usar un "dark theme" o fondo oscuro por cojones.
Bueno, solo queria recomendarte como ya han hecho otros Golang, aunque solo sea por diversion, para iniciarte podrias usar el libro "The Go Programing Language", veras que el propio Kernighan es co-autor.
#6 Acabo de probar algo por curiosidad. Arranco Atom, vacío, sin ningún fichero que editar: 300MB sólo por estar arriba. Una joyita...
Por comparación, EditPad Lite arranca con 15MB (que ya está bien para un editor).
#46 Encima es solo un editor de texto con pijadas! Coño ni siquiera Word traga tanta RAM... Lo dicho, programadores de mierda que por no aprender otra cosa tiran con JS y sus mierdas... Y si, en este saco meto tambien a Node.js
#47 yo programo en node y lo hago no porque sea un vago o un programador de mierda, lo hago porque es por lo que me pagan. Pero por favor, continúa.
#6 Atom... nunca entenderé porque tiene tanto éxito. Yo solo lo he probado 3 o 4 veces para eso, para probarlo porque me hablaban muy bien de el. Pero enseguida lo cierro, me parece muy lento y es de los editores que mas tardan en abrirse.
Sublime Text es instantáneo y es el que más me gusta. Aunque para typescript prefiero Visual Studio Code que también es lento en abrir, pero me gusta bastante más que Atom.
#66 Atom murió el día que salió vs code.
#6 Un 10 por el meme de los perritos, y ahora a por el subnormal de turno:
Me la suda JS pero tu eres un puto FLIPADO para empezar Electron no es un lenguaje. A ver como haces una aplicación web sin usar JS con un "lenguaje decente" como tu dices. Coincido con que la aplicaciones con chromium suelen ser una mierda (por muchas cosas) pero se suelen hacer asi por ciertos motivos que veo que no entiendes y que no te voy a explicar. Tengo comprobadisimo que la gente que dice "este lenguaje es mejor que este otro" no tiene NI PUTA IDEA ni de JS ni de C ni de Python ni de programar en general. Sois como los subnormales de PlayStation VS XboX o Win/MAc no aportáis nada y no teneis ni puta idea, solo os chupais la polla entre vosotros.
#67 Vaya, un "programador" de JS que se ha ofendido y encima boca-sucia
A ver como haces una aplicación web sin usar JS con un "lenguaje decente"
Yo no he dicho que no se utilice en web (de hecho hasta hace poco era la unica opcion) pero ahora existe web assembly y si se limita el uso de JS a web no me parece mal
Se suelen hacer asi por ciertos motivos que veo que no entiendes y que no te voy a explicar
Jajajajajajaja ya te acabas de retratar "programador"
#68 yo trabajo con 3 lenguajes distintos pero no lo soy lo suficientemente tonto como para pensar que hay uno mejor que otro (cada uno tiene su utilidad) y tu al no responder a la ultima parte de mi comentario te acabas de retratar como lo que eres, un pobre troll que no tiene ni idea de lo que dice.
#70 Claro que si "programador"
Sigue defendiendo que JS es la hostia para escritorio
Encima de flipado, eres un analfabeto funcional ya que nunca he dicho que electron sea un lenguaje.
Los retrasaditos al ignore
#74 al ignore que vas pues.
no se como has aguantado tanto tiempo aquí con tantos comentarios vomitivos la verdad....
#74 Eres todo lo que está mal en el mundo de la programación. Arrogancia, "trolleo" y falta de empatía todo junto. Menos mal que he salido de esto. Y parece que las cosas están cambiando pero quedan muchos como tú.
#68 Otro que se piensa que WASM es sustituto para programar en lugar de JS
#67 #50 Yo a todo el mundo que me pregunta por un nuevo lenguaje le digo lo mismo:
PYTHON.
#67 cada lenguaje tiene su puntito.
hay mucho taliban que no sabe vivir sin echar bilis sobre el contrario.
A mi no me gusta Java por una mala experiencia inicial...podríamos decir que lo odio (a nivel personal) ,
pero no me dedico a decir que java es lo peor (de hecho, al contrario...si se usa tanto, malo no será)
#6 Gracias a Electron tienes todo eso que dices para la plataforma que más te guste.
Ya sé que para ti sería mejor si hicieran versiones nativas superoptimizadas para Linux, Windows, Mac, Android, etc... pero lo más seguro es que si todavía tuvieran que hacer eso, sólo habría versión Windows y web.
#6 Este de que cueva ha salido? (Y cuanto lleva dentro...)
#6 La mayoría de esos "programadores" te saben programar en otros lenguajes, pero la mayoría de los que programan en otros lenguajes no saben "programar" en js y se pierden con frameworks etc etc
#6 desde cuando hay lenguajes decentes y lenguajes indecentes? Javascript tiene su utilidad (bastante ademas) no todo tienen que ser virguerías funcionales programadas en Haskell.
Qué cansancio de discusiones absurdas de programadores. Programa en lo que te salga del toto y deja a la gente vivir. Seguro que tú nunca has hecho preguntas tontas. Seguro que tú has nacido sabiendo programar en Cobol, o cualquier mierda que pienses tú que es decente.
#6 Hijos de puta... Atom es uno de mis editores favoritos.
#6 El problema no es saber otro lenguaje amigo.
El problema es tener que programar la misma aplicación más de una vez. Si no eres una gran empresa no es rentable. Y con esta solución tienes un solo código para todas las plataformas.
No es cuestión de ser vagos es cuestión de tiempo y dinero.
#6 Se prima la rapidez del desarrollo y no la eficiencia del programa, total hoy en dia la ram y la cpu es barata, y luego pues pasan cosas como Atom...........
#6 Estuve unos 8 meses trabajando con esa mierda de Atom, y soportando a frikis que le ponían todo tipo de extensiones chorra. En cuanto mejoraron un poco VS Code, le di la patada.
#6 no todo el javascript necesita un chromium.
Está node.js, y hay SDKs que mezclan C++ con .JS,
Javascript es muy bien para ciertas cosas, y permite hacer mucho con muy poco código.
https://collapseos.org/
Recomiendo tambien este libro:
https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
Touché... yo empecé a trabajar hace dos años directamente con Angular y siempre tengo pendiente repasar el C++ de la carrera o aprender más. Al final hay que saber de todo un poco pero yo al menos creo con tanta abstracción encima luego cuesta entender como funcionan las cosas por detrás.
Una pregunta para los que estáis en "la crema" de la programación:
Hace milenios programaba mucho en C, y cuando tengo que hacer algún miniproyecto para mi trabajo (ya no programo de manera habitual, sólo me hago herramientas que me ayudan en las otras tareas de mi curro), sigo usando C.
Para ser sincero, C siempre me ha gustado y además le tengo cariño por la costumbre, pero tengo que reconocer que la gestión dinámica de la memoria es un coñazo. Control absoluto, pero al mínimo error con un puntero, todo el programa a la mierda.
¿Qué me recomendaríais, siguiendo la filosofía y la ligereza de C, que sea más sencillo para manejar datos de manera dinámica?
#c-50" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/50">#50
Habría que ver cuáles son tus necesidades reales, dicho esto, por lo que me cuentas (donde supongo que el rendimiento no influye gran cosa) te recomendaría:
Cualquier lenguaje que tenga recolector de basura, por ejemplo:
C#, java, Python
Para lo que tu quieres, que supongo que va a ser crear vectores/listas a los que puedes añadir nuevos elementos con un “.add()” sin preocuparte de redimensionar el vector o eliminar la lista y luego hacer cuatro bucles... pues te sobra con cualquiera de ellos y te va a facilitar bastante.
PD: El concepto de ligera ya me resulta un poco más ambiguo o dificil de responder, aunque con él en mente seguramente muchos te dirian que vayas más por Python (yo no lo haría)
#59: Con C++ puedes hacer eso, vectores donde la memoria va automáticamente según añades elementos a los vectores.
#50 #59 #93 #60 #65 #89 #113
Lo más sencillo hoy en día para tener potencia y no preocuparse de punteros y memoria es hacer uso de C++11, C++14 y/o C++17 (pronto saldrá C++20) que ya tienen los "smartpointers" con std::unique_ptr y std::shared_ptr... aparte de todas la nuevas caracteristicas y mejoras del lenguaje.
Además usando C++ Standard el programa puede compilar en Windows, Linux, Android, iOS, Mac, etc... Y si necesitas UI puedes usar C++ y el framework Qt5 también crossplatform...
https://es.m.wikipedia.org/wiki/C%2B%2B11
https://es.m.wikipedia.org/wiki/C%2B%2B14
https://es.m.wikipedia.org/wiki/C%2B%2B17
https://es.m.wikipedia.org/wiki/Qt_(biblioteca)
#50 Si no quieres tener que reaprender nada te recomiendo Java, la sintaxis de Java es parecida a C++ pero sin punteros
#50 Yo te recomendaría python por su simpleza y ligereza pero su sintaxis un poco diferente a lo que estás acostumbrado y la documentación es la peor de todas las existentes de lejos.
#65 Yo sigo leyendo que la documentación de Python es mala. Pero yo sin ser programador me apaño con la documentación de la documentación de la biblioteca estándar. Eso sí, hay bibliotecas que están muy mal documentadas, pero eso ocurre en todos los lenguajes.
#50 Si necesitas que sea de bajo nivel: Rust, esta diseñado para evitar errores.
Que hace al lenguaje de programación Rust especial
Que hace al lenguaje de programación Rust especial
mozilla-hispano.orgSi puede ser de alto nivel, python tiene fama de ser el que menos te dificulta la tarea que quieres hacer. Tambien tiene muchas librerias de cosas ya hechas.
#50: Yo es que C lo he usado hasta en plan "script", o sea, en vez de meter funciones de scanf, o lectura de ficheros, meto a pelo las variables en el código y lo compilo cada vez que quiero cambiar una variable, si no es muy grande no se tarda gran cosa.
Si tengo un vector lo hago muy grande y listo, así no tengo que hacer asignación dinámica de memoria.
#50 golang. Sin dudarlo
#c-50" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/50">#50 Cada uno te va a recomendar lo que haga él
Yo intentaría no salirme mucho de la zona de confort ni obligarme a aprender mucho más. ¿Qué IDE usas? Si unas Visual Studio, por ejemplo, yo iría a C#
#50 Lo más directo es aprender C++ moderno, el estándar 11 o superior, con sus punteros inteligentes y demás facilidades.
#50 #116 Veo que en Udacity sigue lo del mes gratis (tienes que meter tarjeta y cancelar luego, eso sí). Le puedes echar un vistazo al curso de C++ está bastante bien explicado lo del manejo de memoria con estándares actuales https://www.udacity.com/course/c-plus-plus-nanodegree--nd213
#50 para hacer scripts guarros. Se recomienda Python.
#50 C++ Builder, de Embarcadero (antes Borland). Tiene una VCL espectacular y multitud de componentes, muchos gratuitos, que hacen prácticamente cualquier cosa que se te venga a la mente.
#50 Coincido con quien te dijo que tires por Rust.
Es un lenguaje pensado para hacer las cosas bien y con muchas facilidades en calidad de vida a la hora de trabajar. Es compilado a nativo, no tiene recolector de basura pero administra la memoria e impide que la cagues, e incorpora todo lo bueno de los lenguajes modernos sin las partes malas (gestor de dependencias automatizado, linters, etc.). Te deja además bajar al más bajo nivel si lo necesitas.
Incorpora además un par de conceptos nuevos que no tiene ningún otro lenguaje hoy día, los lifetimes y la propiedad, que son precisamente los que impiden que hagas las putamierdas que puedes hacer sin ningún tipo de impedimento en todos los demás lenguajes (excluyendo unos pocos que son muy nicho, tipo Haskell o Ada). Es un lenguaje que te forzará a ser mejor programador.
No te metas ni de coña en el pantano y campo de minas que es C++ hoy día. Te vas a querer suicidar.
Programar C++ requiere un nivel absurdo de conocimiento de la inmensa cantidad de trampas y complejidad artificial que tiene. Usar librerías es una pesadilla, es extremadamente fácil cagarla con muchas cosas a menos que tengas mucha experiencia, es inseguro por diseño y tiene muchísimas features redundantes y superpuestas entre sí que nadie conoce al 100% por lo absolutamente elefantiásico que es.
Quien te diga eso te está aconsejando mal y porque ya es un experto en C++ y lo ve "fácil".Si estas dispuesto a meterte en algo de esa complejidad (sobre todo si es para aprender), no pierdas el tiempo y tira por Rust, porque tiene una curva de dificultad similar (manejas los mismos conceptos), pero a diferencia de C++, si te compila es casi seguro que te va a tirar bien lo que hayas programado, y sin muchas sorpresas, especialmente si utilizas concurrencia.
Para que te hagas una idea, Microsoft lo va a empezar a usar en lugar de C++ para los desarrollos de sistemas a partir de ahora ( https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ ), y otras casas como Dropbox, Google, Facebook etc. ya lo están usando en producción en sistemas críticos, sólo por el hecho de que hace imposibles una inmensa cantidad de bugs muy habituales en C++ y hace más fácil la vida de los programadores por el hecho de no poder cometerlos y sobre todo tener que depurarlos después. Los productores de Chromium están haciendo experimentos para ver si empiezan a sustituir poco a poco componentes de C++ en Rust porque llega un momento que no pueden sostener la complejidad que implican ciertos subcomponentes (por ejemplo, el motor CSS paralelo de Firefox fue escrito en Rust a la primera y Chromium lo abandonó tras fracasar por tercera vez su intento en C++).
#c-50" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/50">#50 #250 C++17 (C++ moderno) , para alguien que empieza desde cero, no es tan difícil como dices.
El viejo C++ si, el moderno yo lo veo bastante fácil y potente
(con el tengo las sensaciones que tenia cuando hacia mis pinitos en C# viniendo de C ...el verlo todo fácil)
#c-50" class="content-link" style="color: rgb(123, 125, 125)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3318781/order/50">#50 C#, Java o kotlin, pero sobre todo kotlin.
O bueno: C sin punteros...
#50 Estoy en tu misma situación, desde niño aprendí a programar a los 12 años usando el viejo Basic por principios de los 90's pero al ser interpretado sentía que no era lo mismo a simplemente teclear el nombre del programa.
De la misma manera que tu, me encanta C, me pasé a C++ y Qt , librería multiplataforma, sencilla de aprender sin hacer a un lado el potencial y rapidez que ofrece C++, dale un vistazo, no te va a decepcionar.