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.).
O Doom, que corría en cualquier máquina.
#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.
#0 Ésta también está guapa:
#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.
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...
#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.
#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.
https://collapseos.org/
Recomiendo tambien este libro:
https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
#9 Abuse (que también es de disparos pero a alienígenas) funciona sobre TCL/TK
#12 Creo que va sobre Lisp.
#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).
#6 Bien, hablemos de Java...
#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.
#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
#17 https://www.jwz.org/doc/cadt.html
#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?#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.
#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.
#24 ¿Qué frameworks usas? ¿O no usas nada? No sé si entiendo tu última frase.
La pregunta es en serio. Programo por afición.
#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.
#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.
#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.
#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
#28 #25 #15 Bueno, lo he encontrado. Pinchad en la foto.
#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.
#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...
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.
#4 Terry Davis... un individuo curioso cuanto menos.
#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)
#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.
#24 Yo he estado ahí.
Serás feliz en golang.
#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
#27 Megas perdón.
#14 Al Wolfenstein 3D jugué con un 8086 a 8 Mhz en CGA.
#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
#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
#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ú.
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?
#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).
#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á.
#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.
#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
#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.
#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)
#25 A mi el quake me tiraba decente cuando subí la velocidad del bus de 33mhz a 40mhz en mi 486dx2
#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)
#50 Si no quieres tener que reaprender nada te recomiendo Java, la sintaxis de Java es parecida a C++ pero sin punteros
#2 al Wolfenstein 3D lo vi correr en un 386.
#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
#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
#58 Aghhh y ahora me entero
#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.
#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.
#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"
#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.
#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.
#62 Al contrario. Para programar en ASM es más facil que C++ con las templates y aprendiendo cosas como mutex y semáforos.
#54 #51 Golang está hecho por los creadores de Unix y tiene un GC.
#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.
#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
#71 mutex y semáforos hay en C. ¿A qué te refieres exactamente?
#75 que asm es mucho mas sencillo.
#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.
#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.
#1 #3 Leeros esto:
https://tonsky.me/blog/disenchantment/es/
Al que me adhiero totalmente.
#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".
#24 ¿Qué pasaba con la conio.h? Por qué no te gustaba?
#81 que no era parte de las librerías estándar de C. En aquellos oscuros y divertidos tiempos había quien nos enviaba librerías (su parte de una aplicación) usando la conio.h o aquella otra que era propia de TurboC... y claro, aquello no compilaba en los Unix donde iba la aplicación completa. Cosas de las cárnicas de entonces y de la carne de becario gratis que las alimentaba.
#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í
#72 Gracias por sacarme de la ignorancia. No lo sabía.
#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.
#78 Pues no, hace años (bastantes) que me deshice de él. Sorry.
La verdad es que a parte de instalar 40 mil veces MS-DOS y Windows 3.0 y 3.1 no le hice mucho más, porque estaba todo el día probando juegos y toqueteando cosas del sistema, además de hacer mis primeros pinitos en programación con Quick Basic. Mi bautismo de fuego trasteando con hardware fue con el Pentium, ya que nada más comprarlo tuve problemas con el procesador por el tema del calentamiento, la pasta térmica, el ventilador e incluso la placa base. Vamos que me salió una rana Goliath el puto Pentium, pero al menos me sirvió para aprender bastante sobre hardware.
#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.
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#
#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.
Yo programo a veces en C, en concreto ahora tengo algo que estoy haciendo por afición en mi tiempo libre (en paro...), eso sí, el código resultante es una chapuza, pero bueno, es en C. Como otras cosas, cuando más o menos termine algo "que funcione", aunque sea poco, lo colgaré en Github con una licencia GPL y listo (quizás lo continúe más, quizás me ponga a continuar otra cosa que dejase parada antes). Quizás sea muy raro, pero por afición...
Las páginas web de hoy no serán compatibles con ningún navegador dentro de 10 años (probablemente antes).
Triste pero cierto, incluso usando funciones básicas, te pueden cambiar algo y obligarte a volver a editar una aplicación de la que creías que te podías "olvidar" por haberla dejado más o menos funcional y para el que la quisiera usar. Por supuesto, esa aplicación la programé con JS a pelo, no tiene nada moviéndose por la pantalla, ni transiciones suaves, pero bueno, se meten los datos, se pulsa en funcionar y funciona, ya está, el usuario recoge los datos de retorno y todos felices. Puede que sea un poco chapucera, pero bueno, más o menos funciona y ahí la dejo colgada y a quién le interese, que la use.
#88: El problema es que... ¿Tanta memoria necesita un intérprete de JavaScript?
Es que estamos hablando de que ocupa más que Windows 95. Recordad las aplicaciones en Flash que se distribuían en torno al año 2000 ( #Mundo_Viejuno ), entraban perfectamente en un disquete de 3 1/2', y Flash creo que iba interpretado también, y en esa aplicación iba el intérprete, porque no necesitabas instalarte Flash, y Flash en esos años hacía muchas cosas que hoy hace HTML5, quizás no tantas, pero vamos... que no hay excusa que valga. Eso, o bien el hecho de usar Electron implica meter TODO lo que un navegador necesita, incluso reproductores de vídeo, y no hay manera de ajustar lo que se incluye al compilar el programa...
Yo me acuerdo perféctamente de un PPKiller donde tenías que matar a Aznar... y eso, tenía sonido (o sea, iba ahí un reproductor) y entraba en un disquete y podías usarlo en ordenadores sin Flash.
#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.
#59: Con C++ puedes hacer eso, vectores donde la memoria va automáticamente según añades elementos a los vectores.
#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".
#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.
#91 >. y eso, tenía sonido (o sea, iba ahí un reproductor)
No, llamaba a DirectX.
#96: Genial. ¿No se puede hacer lo mismo ahora para no tener que empaquetar más cosas de la cuenta? Es decir, que el paquete de Windows, no incluya nada que no se pueda hacer con DirectX, con alguna versión que sea muy compatible y listo.
Es que lo que no tiene sentido es que cada vez se acumulen más cosas, a este paso para usar un editor de textos, vamos a acabar con un sistema operativo emulado que pueda correr el intérprete adecuado para el editor de textos.
#97 https://tinyapps.org
#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
#79 mierda! mis ojos!!!