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
#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.
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!
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.).
#79 Lo que dice es cierto, pero actualmente es inasumible ser productivo programando de esa forma. La única forma de crear un producto rápidamente y barato, es usar algo que ya te lo da casi todo hecho, aunque sea ineficiente. Y tú dedicarte solamente a pegar trozos.
Las librerías y frameworks aparecieron por muchas razones:
- todos estábamos escribiendo las mismas funciones
- al usar librerías, que están testadas, evitas errores
- trabajar a bajo nivel se vuelve criptico a medida que el proyecto crece
- los frameworks ayudan a que todos los miembros del equipo hagan un trabajo ordenado
Aún recuerdo la pesadilla que era trabajar con el DOM directamente en javascript. Una simple librería como jQuery cambió aquello radicalmente. Y todos habíamos escrito nuestras propias funciones que ya venían incorporadas en esa librería. Y así todo.
#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.
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.
#1 #3 Leeros esto:
https://tonsky.me/blog/disenchantment/es/
Al que me adhiero totalmente.
#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.
#28 #25 #15 Bueno, lo he encontrado. Pinchad en la foto.
#7 Por lo menos Ruby ha muerto...
#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.
#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.
#76 nunca he llegado a tanto en ensamblador. Lo máximo que he hecho son programas sencillos de entrada y salida de texto, o como mucho algún cálculo aritmético y poco más. Sin embargo, desde el desconocimiento, cuesta creer que sea más fácil.
#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
#79 #85 No soy programador (soy de sistemas) pero sí hice alguna cosilla en programación. No me iba mal, no, pero decidí rechazarla, quizá por el tiempo que invertía, y para meterme en puñetas virtuales o "frameworks" como bien dice squanchy prefiero ni acercarme. Aunque siempre tuve cierta curiosidad por el ensablador (aunque requiere muuuchas hooras).
barcelonauta), vino con este el Lotus 1-2-3 versión 2.01. Qué pasada. En un disquete de 720K tenía una estupenda hoja de cálculo con el que hacía gráficos de barras normales, apiladas y sectores, y creo que líneas también. Los imprimía en la matricial que me venía. Y si me apuráis... ¡monté DOBLE PANTALLA en mi XT para el Lotus y funcionaba, ya lo creo! Macros incluidas. Ahora está todo orientado al gráfico, pero a nivel funcional... psé. Sí, bueno, el copiar-pegar (el texto bien manipulado no necesita copiar-pegar), pero si nos parásemos a pensar, poco más. ¿Iconitos? ¿La web? ¿TLS requiere GUI? ¿No os acordáis del IRC?
La idea está en que hemos llegado a un momento en que, a diferencia de lo que se programaba hace 20 o incluso 30 años y para hacer algo similar, y que corresponde a lo que nos quejamos muchos, todo es muchísimo más pesado, sobretodo en la programación en entornos Windows o incluso móvil, Todo es parecido, pero orientado a la "facilidad" de programación y no a la eficiencia. En cuanto a "librerías", que yo sepa, estas ya se usaban en C con la programación en alto nivel (que sepa, aquí me meto ya en terreno pantanoso para mí :p).
Ahora me iré de madre un poco. Cuando tuve mi primer ordenador en casa (el Amstrad PC3086 que comenté con
Los entornos gráficos son más "bonitos", pero menos funcionales realmente.
Aprendí con consolas MS-DOS, tuve MS-DOS en mi casa y mi ordenador me vino sin disco duro, pero no porque no los hubiese sino porque me acuerdo como si fuese ayer (con la ilusión que me desbordaba) que le dije a mi madre que lo quería "sin".
#6 Completamente de acuerdo. Hijos de puta.
#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
#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.
#76 Decir que ensamblador es más sencillo que C es no haber programado jamás en ensamblador. Ya sólo por la gestión automática de memoria en las llamadas a subrutina, te ahora una burrada de trabajo.
Y te lo dice alguien que ha programado ensamblador de 8086, 68000 y microcontroladores PIC.
O Doom, que corría en cualquier máquina.
#6 Bien, hablemos de Java...
#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).
#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...
#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)
#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.
#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...
#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.
#79 Pues yo no. El tío compara win95 con Android.
En Win95 tenías que buscar e instalar los putos driver de tu equipo a mano. Instalar Internet o cualquier otra cosa podía ser un puto infierno. En Android todo viene de serie y todo funciona sin hacer nada y la variabilidad de dispositivos y piezas de multitud de fabricantes distintos es abismal, por no hablar de tamaños de pantalla, resoluciones, etc. Obviamente eso no es gratis. Tienes los controladores y los sistemas dentro del SO. Del tirón.
El precio a pagar por la sencillez es que todo venga dentro de golpe sin tener que hacer cherrypicking de lo que necesitas.
Estoy de acuerdo en algunas cosas que dice pero ni mucho menos en todas. Y él lleva 15 años en esto, yo solo 10, pero tampoco soy el más nuevo del barrio. Las páginas webs y sistemas de hace 10 años eran rápidas y pesaban poco. Y eran una puta mierda. No tenían ningún tipo de funcionalidad, el mantenimiento era nefasto y no había que hacer que una web se viese bien en un puto reloj, en un Ipad, en un Iphone, en una TV de 52 pulgadas, no tenían que tener una API decente, no pintaban ni mucho menos imágenes enormes, el JS era simple pero tenían que cargar una mierda flash que era insegura por defecto...
No creo que el código actual sea peor que el de ayer. Son igual de malos. Las cosas funcionan casi de casualidad, y eso lo sabe cualquiera con unos tiros pegaos. ¿O acaso el TCP no tiene un sistema de redundancia de datos para recuperar que se pierde parte de ellos? ¡Y en UDP se asume que se pueden perder, simplemente consideramos que no importa que pase! Y estamos hablando de cosas básicas sobre las que funciona todo, pero es que... todo es así. Toodo va con pinzas. Yo hace ya tiempo que pienso que eso es el desarrollo, es lo que hay.
#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?#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
#71 ni de broma, en mi opinión.
C y c++ es un paseo por el bosque del edén comparado con ensamblador.
#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.
#24 Yo he estado ahí.
Serás feliz en golang.
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?
#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.
#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.
#24 Eres una deshonra para los informaticos. Ada y Turing se revuelven en su tumba al oir tu nombre
#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.
#0 Ésta también está guapa:
#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.
#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.
#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)
#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.
Normal. A día de hoy prima más la cantidad que la calidad o la velocidad, más aún teniendo en cuenta que donde más se desarrolla software es para entornos webs, y ahí JavaScript abunda. Para colmo, como JavaScript es interpretado y tan sencillo de aprender, ya se usa para todo.
A mí me molesta que muchas aplicaciones usen Electron por haber sido programadas en JavaScript, y que por ello tengan que consumir más de 200 MB o 300 MB de RAM (por ejemplo, VS Code), pero por otro lado comprendo que es mucho más sencillo para un proyecto grande y que hay más oferta de programadores que te lo puedan hacer que si se hiciera en C++ o en C#
#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
#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).
#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.
#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)
#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.
#162 En C++11 y en adelante tienes la clausula "auto":
auto x = 4;
auto y = 3.37;
auto ptr = &x;
std::set st;
st.insert();
for(auto it = st.begin(); it != st.end(); ++it)
{
std::cout
#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.
#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ú.
#24 me has recordado al replicante de blade runner en su discurso final
#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
#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.
#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
#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)
#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.
#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.
#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.
#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++).
#159 El problema es que cada vez se construyen mas castillos de mierda encima de otros castillos de mierda con esa excusa ya que es demasiado tarde para hacer las vosas bien y demasiado caro volver a hacerlo todo de nuevo.
El problema es que la ingenieria de software se ha vuelto el proyecto mas complejo que existe y para abordarlo se ha llegado a la conclusion de que es mas facil hacer parches y soluciones que simplifican los problemas a base de perdida de rendimiento, fiabilidad, etc... No creo que exista tal ahorro, solo a corto plazo.
#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.
#79 Un conocido ha escrito un libro que por lo visto va de un programador de la vieja escuela que sufre en la industria actual: Eugenio, memorias de un informático. 10 verdades que ocurren en los proyectos
#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
#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:
https://collapseos.org/
Recomiendo tambien este libro:
https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
#17 https://www.jwz.org/doc/cadt.html
#50 golang. Sin dudarlo
#71 hasta aquí he llegado.
Demasiado internet por hoy, ya.
#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.
#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.
#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í
#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
#54 #51 Golang está hecho por los creadores de Unix y tiene un GC.
#14 Al Wolfenstein 3D jugué con un 8086 a 8 Mhz en CGA.
#199 Disculpa. Me refería al #76 todo el rato. Es que no sé leer
. He ido a por lana y he vuelto esquilado...
#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...
#4 Terry Davis... un individuo curioso cuanto menos.
#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á.
#87 Obviamente me refiero en un Z80
En Forth puedes llamar a ASM Z80 con una facilidad asombrosa.
Sé obviamente que hoy es imposible hacerlo, pero en segun que microcontroladores de AVR no es tan complejo como lo pintan. Y sí, he visto ports de Unix para un MSP con compilador de C y Ncurses en 512kb de RAM. Se perfectamente lo que es el ensamblador, gracias. Acabo de hacer un Hello World para CollapseOS.
Sin ánimo de ofender, porque en cierto modo comparto vuestros perjuicios, algunos aún no entendéis que eficiencia no es hacer correr un programa con menos hierro. La eficiencia que importa, la que nos da de comer a nosotros y al empresario, es hacer correr el mayor número de programas en el menor tiempo posible (sin bugs, entiéndase). Y para eso se necesitan frameworks.
Además, la programación evoluciona: a día de hoy es más importante escribir codigo rápido, robusto y fácil de mantener. Si hace falta más hardware pues se compra. Eso es precisamente lo barato.
#104
he visto servidores Tomcat en llamas más allá del cinturón de IECISA...
#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
#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.
#249 Vaya, creí que nadie iba a encender esa mecha . Voy a tratar de ser breve, pero el tema da para mucho...
En primer lugar, todos más o menos hemos estado presentes en la evolución de la web. Cuando JS era el "lenguaje pegamento" para hacer las cuatro cosas que necesitaban programación dentro de una web estática. Pero con los años, la demanda de una web cada vez más reactiva y con una UX más completa fue desplazando más y más lógica de negocio al front end. Esto generó una época dorada del front end que dura hasta hoy.
Desde hace algunos años, el concepto de cliente servidor clásico, en el que un back end "compila" una web dados unos datos de entrada y genera un HTML "estático" de salida está muriendo. Ahora la web prácticamente se construye en tu navegador con JS (como en el caso de librerías como React o Vue y frameworks como AngularJS y Angular). La idea pasa por pedir al servidor la "receta" que viene en forma de scripts de JS, y ejecutar todo en front, de manera que las interacciones del usuario sean respondidas en el acto, y la información fluya entre servidor y cliente en segundo plano.
En paralelo a todo esto, la gente de google desarrolla chromium y junto con él, el motor v8 de JS dando resultados de rendimiento muy buenos. Como consecuencia de esto nace NodeJS, entorno de ejecución de JS en el lado del servidor y así se forja el ya famoso paradigma de "JS Everywhere".
Y aquí es donde entra mi opinión.
He trabajado con muchos lenguajes, arquitecturas y frameworks diferentes. Actualmente llevo casi 4 años como desarrollador fullstack JS. después de 3 años en ASP .Net Framework y ASP .Net Core. El hecho de tener el mismo lenguaje en cliente y servidor tiene una barbaridad de ventajas, como por ejemplo:
No tener que depender de librerías externas para el marshalling de JSON (ya que la notacion de objetos de javascript es reconocida directamente por el propio JS)
#4 Terry Davis.
Descanse en Paz.
Y que los negros que brilan en la oscuridad no le persigan en el cielo.
#10 tiraba el wolf en mi 286 a 16Mhz perfectamente
#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.
#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.
#104 #121 Todos esos códigos se perderán en el tiempo, como disquetes de 5¼ en la nube.
#66 Atom murió el día que salió vs code.
#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
#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 para hacer scripts guarros. Se recomienda Python.
Ha llegado un punto en el que la informática es suficientemente antigua como disciplina que ya, por fin, hay abuelos cebolleta programadores.
#85 yo sigo trabajando el DOM con vanilla y jQuery no me parece tan fantástico.
Mátame.
#338 Los nuevos frameworks tratan de que el programador no toque "a mano" el DOM. Por eso han tenido tanto éxito. Yo llevo un par de años con React, y ha sido un gustazo que el programador manazas del equipo no pueda hacer de las suyas.
#21 https://www.reddit.com/r/itrunsdoom/