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
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.
#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...
#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"
#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
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.
#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.
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.
#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.
#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".
#94 Descárgate un keygen de esos que se usan para activar un producto de forma pirata, de los que tienen incluso música y efectos gráficos: no pesan absolutamente nada.
Pero claro, están programados en ensamblador accediendo directamente a las librerías de Windows, sin capas intermedias para facilitar el trabajo. Hay hasta concursos con keygens falsos a ver quién hace mas con menos.
#94 Adminsitro Unix principalmente Solaris y HP-UX, y ahora más Linux porque muchos de los productos que quieren instalar el cliente ya están para Linux y ahora ya no te viene SAP y te dice "La base de datos principal tiene que ser un Oracle y estar sobre un Solaris", sino que te da más versatilidad.
Cuando comencé hacía mis pinitos como desarrolladora de bases de datos.
La complejidad que comentas también está en el mundo de los sistemas. Como el software también es más complejo es completamente inviable migrar un producto de HP-UX sobre PA-RISC cuyo último parche salió hace 19 años a Linux o a HP-UX sobre Itanium, que al menos existen repuestos harware. Al final lo que se hace es poner un cluster con máquinas Itanium, crear una IVM y dentro de la IVM un SRP (es decir, una máquina virtual y con un contenedor dentro) que emula el sistema operativo para PA-RISC a partir de una imagen de la máquina física original.
Antes tenías un servidor físico en un centro y otro en otro. Un servidor un host, o al menos una system board equivalía a un hosts, según cableado y jumpers. Alta disponibilidad manual. Cuando se hacía la conmutación de un centro a otro se hacía un servidor cada día e implicaba un montón de cosas, desde cargar un backup manualmente del servidor activo al servidor de respaldo a tirar una interfaz en los switches y levantar otra.
Es decir, siempre sabías cual era el servidor activo, nunca conmutaban solos (te acordarías, o estaría en la pizarra cual era). Siempre sabías cuales eran los discos en uso y como estaba configurada la red.
La maqueta de pruebas era un servidor viejo.
Ahora para instalar una maqueta que tenga cierto parecido a un servicio que va a estar en producción cuando no tienes nada necesitas instalar y configurar una infraestructura de virtualizacón con alta disponibilidad y además todos los productos y capas que van en ello, todo para instalar una imagen docker que luego vas a personalizar para tu uso.
Y cuando la insfraestructura virtual falla o está mal configurada (pasa más veces de lo que parece en ciertas organizaciones grandes) arreglarlo no es trivial porque no tienes ni idea de donde está el fallo. Y si, ahora los servicios conmutan virtualmente ante fallos de hardware, y la conmutas manualmente con un click, pero mi experiencia me dice que ponerlo en marcha es un dolor de gónadas enorme, un tiempo de despliegue inicial y aprendizaje mucho mayor, para luego no tener tantos beneficios.
Eso si, si eres una organización enorme te sale a cuenta. O una organización de crecimiento exponencial.
#94 Por curiosidad, ¿por qué lo querías sin disco duro? Yo tuve un Amstrad PC2086 con disco duro de 30 MB
, y no me imagino la pesadilla que sería tener que arrancar y usar el sistema operativo siempre desde disquete. Aparte de que sin disco duro no era posible tener Windows, que yo sepa. Ni siquiera el Windows 2.0 que usaba por aquel entonces...
#85 el hardware de hoy en dia es muy rapido, puede funcionar con casi cualquier entorno sin problemas, incluso si la aplicacion no está hecha eficientemente
#85 yo sigo trabajando el DOM con vanilla y jQuery no me parece tan fantástico.
Mátame.
#79 mierda! mis ojos!!!
#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
#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.
#79 Y no, en mi mundo, una aplicación que te dice “voy a destruir una parte de tu trabajo, pero te dejo elegir cuál” no está bien.
¡Joder alquilen que lo entiende por fin!
#79 Seguramente has escuchado este mantra: “el tiempo del programador es más importante que el tiempo del computador”
Curioso, usaba otra frase, "es mas barato el kilo de metal que el kilo de carne"
#135 Yo creo que no está diciendo que el código sea peor, si no que como se cuenta en el enlace que ha puesto #79 (muy bueno) en general todo se complica hasta la naúsea, también lo han comentado varios. Ahora en general no es que todo tire de librerías más o menos gordas y que bueno, es pasable, puede que el binario y todo lo que arrastre ocupe más pero más lento no tiene por que ser, al final llamas a las funciones que llamas y por lo general las que ya están aceptadas por la comunidad van a ser mejores que las que puedas hacer tú. El problema es que ahora mucho SW tira de frameworks completos que simplemente muchos desarrolladores usan pq es lo que saben, aunque lo conozcan muy bien (si sólo tienes un martillo de oro todo te parecerá un clavo).
Creo que somos muchos ya los que hemos visto en el trabajo como se acaba implantando un entramado de capas, instaladores de módulos, virtualizaciones innecesarias simple y llanamente por que alguno que cae bien o tiene mucha labia vende la moto y el de los galones da el OK.
Al final para hacer una puta mierda de aplicación, tienes ahí un sindios de cosas que complican la entrada de gente nueva por los palos que hay tocar, complican el mantenimiento, aumentan el tamaño y reducen el rendimiento.
Cada vez me gusta más programar para Arduinos y similares por la cantidad de basura que no tienes que tener en cuenta y con la que nadie te va a venir a molestar.
#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.
#79 el artículo falla muy pronto, en cada sector se tiende a minimizar el uso del componente más costoso, que en el caso de la programación es el equipo de desarrollo. Todos esos frameworks, librerías, virtualizaciones... existen para que el coste de desarrollo sea muy inferior
#79 un enfoque bastante simplón y muy sesgado desde un solo punto de vista. la mejora en seguridad, por ejemplo, ha sido brutal gracias a Frameworks y Librerías... obviarlo en ese análisis me parece estúpido...Por no hablas del UX, los nivels actuales de complejidad de UIs no serían mantenibles sin lirerías que te abstraigan, no al menos por compañías pequeñas/medianas.
Y así con mil cosas que ese post o menosprecia o ni siquiera nombra.
#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.
#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.
#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.
#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.
#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.
#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.
#95 Perdona, no me había dado cuenta que hablabas de equipos antiguos.
Pd: Lo de UNIX en el MSP430 me sorprendido bastante, lo buscaré luego
#95 en C puedes empotrar codigo ensamblador. Al final es como programé yo unas prácticas en la carrera para intentar hacer más eficiente mi código.
Si no recuerdo mal con las directivas de gcc_inline. Por lo que podías elegir como montarte el programa para ser más eficiente.
#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.
#77 Es que no lo es. No hay comparación.
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.
#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.
#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.
#23 Exacto. Yo tenía un 486 dx33 y recuerdo jugar al Wolfenstein pero no al Doom porque no tiraba bien.
#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.
#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.
#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.
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)
#155 Muy interesante lo de std::unique_ptr y std::shared_ptr, todavía tiene el "problema" de que el programador tiene que tener en cuenta el tipo, pero facilite mucho todo, la verdad es que estoy totalmente desactualizado de c++, laboralmente no lo utilizo y se nota
#93 Sí, esta el vector dinamico, pero me sonaba que el delete hay que hacerlo, de todas formas con lo que comento MetalAgm del std::unique_ptr y std::shared_ptr veo que cambian las cosas
#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.
#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.
#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.
#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?
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#
#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.
#88 Bueno al final el tema de Electron es que no deja de ser un Navegador con funciones para Desktop, de ahí el consumo de RAM, no es por javascript en sí. Hay proyectos en NodeJS que no ocupan nada.
Lo que sí, usar Electron te permite ser multiplataforma y tener la flexibilidad de la visualización de una página web. Yo al menos no conozco nada tan avanzado en cuanto a interfaces visuales y experiencia de usuario como en web.
#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.
https://collapseos.org/
Recomiendo tambien este libro:
https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
#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.
#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.
#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
#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)
#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.
#97 https://tinyapps.org
#9 Abuse (que también es de disparos pero a alienígenas) funciona sobre TCL/TK
#12 Creo que va sobre Lisp.