Menéame: comentarios [3318781]

#389 Programadores antiguos vs programadores de hoy

txeke — Thu, 04 Jun 2020 12:21:32 +0000

#328 uso PHP y digo que estoy ~~hasta la po~~ quemado al máximo.

Y no me quejo de JS, de hecho prefiero JS a PHP. De lo que despotrico es de hacer "apps" usando por debajo un motor de navegador entero. Si es una app chorra, es matar moscas a cañonazos, y si es una app de cierta entidad, es mejor hacerla nativa por rendimiento, eficiencia, posibilidades de acceso a hardware, etc.

No critico que lo que use por debajo sea libre o no (que también es importante para mi), sino el que tengan que usar ese algo por debajo.

» autor: txeke

#388 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Fri, 29 May 2020 08:16:42 +0000

#378 Antiguamente cuando conmutábamos un servicio con éxito de un CPD a otro descorchábamos una botella. O cuando sobrevivíamos al pico de más carga del año sin cortar el servicio, aunque haciendo operaciones manuales por el camino. Ahora conmuta solo y si está bien montado ni te enteras. Solo quería decir que en el mundo del hardware la complejidad también se ha incrementado mucho, para en ocasiones no ganar funcionalidad, o que no se note. Desde soporte de serie para cosas que no usas y no piensas usar a querer hacer una instalación pequeña de una maqueta de pruebas y tener que meterte con contenedores, virtualización...

Creo que aún les falta bastante a las FPGA para asaltar masivamente el datacenter, aunque tienen todo lo necesario. Habrá aplicaciones concretas en las que sobresalgan, pero la tendencia es la contraria. Incluso la electrónica de red dedicada se está sustituyendo por una pila software cada vez más grande y compleja, por ejemplo en en firewalls y balanceadores.

Pero vamos, si IBM perdió su supremacía en el Datacenter, ARM está encontrando su hueco y han surgido granjas de ASIC o GPU dedicadas para ciertas tareas no es descabellado que las FPGA tengan también el suyo. Y con una caducidad menor que las ASIC dedicadas. Aunque claro, mi bola de cristal necesita un pulido, porque el futuro no lo veo con claridad.

» autor: empanadilla.cosmica

#387 Programadores antiguos vs programadores de hoy

--8899-- — Fri, 29 May 2020 08:11:14 +0000

#381 Ah, pues no es el que yo decía. Yo me refería a este: eltamiz.com/elcedazo/2014/09/10/memorias-de-un-viejo-informatico-por-f

Pero me anoto ese.

» autor: --8899--

#386 Programadores antiguos vs programadores de hoy

PortgasDAce — Fri, 29 May 2020 05:03:23 +0000

#377 simplonada != simpleza.

Con simplonada me refiero a una simplificación excesiva que obvia gran parte de la realidad que pretende describir, analizar o explicar.

Además la simpleza o la simplicidad, la sencillez, la elegancia... son terminos relativos y muy subjetivos. Un buen microframework enfocado a algo concreto podría entrar en la descripción de sencillez. Te ofrece la solución a una tipología de problemas concretos, de forma simple, bien modelada (ya sea en POO, Funcional o el paradigma que sea) y bien testeada sin querer abarcar una infinitud de casos posibles dónde pueda aplicarse dicha solución (Ej: Microframework HTTP, como flask, vs Web Full Frameworks, como Django).

Si nos referimos a UI, puede que sea sencilla de cara al usuario (lo que finalmente importa cuando haces una UI) pero conlleve cierta complejidad o una cantidad grande de código para llevarse a cabo. Código que si tienes que mantener tú o tú equipo en cada aplicación en lugar de depender de un Framework, tendrá más bugs y, encima, te saldrá más caro al necesitar profesionales especializados en ciertas tareas que a tu negocio le aportan poco y que sin embargo a otro (la compañía tras un framework, por ejemplo) le aportan mucho, acabando en una muy buena simbiosis.

Puedes obviar la realidad todo lo que quieras, está claro que no tienes argumentos para mantener tu postura inicial y por eso has acabado con una intervención de seis palabras que además tergiversa mi postura, algo bastante mediocre, como las simplonadas del artículo.

Por ejemplo, no has podido mantener tu afirmación de que meter Frameworks eleva los problemas de seguridad, cuando obviamente ha sucedido lo opuesto (acercandonos a la extinción de inyecciones SQL, por ejemplo).

Y así con el resto: calidad, mantenibilidad, complejidad accidental, testabilidad, coverage... la mayoría de indicadores han aumentado de forma sólida (no solo aparente) gracias a la existencia de todo tipo de frameworks, ayudando a atajar el problema que existe: (casi) todo el mundo quiere poner una Web o una App en el mercado pero no tiene recursos para financiar un proyecto que termine en un producto seguro sin apoyarse en soluciones generalizadas como librerías y frameworks, manteniendo a expertos en seguridad, actualizaciones cada vez que existe un problema, cambios en el código cada vez que hay un cambio en el protocolo HTTP o las capas más ligadas al hardware del lenguage, etc, etc.

Sinceramente, que una aplicación pueda hacer un "npm update", "sbt update" o "composer update" y resolver así un fallo de seguridad sin tener que intervenir en una línea de código porque el framework o librería de turno lo han hecho, es un alivio y ofrece una seguridad y fácilidad de mantenimiento nunca vista antes. ¿No hay aquí simpleza, sencillez o elegancia? Al menos yo sí la veo..

Eso sí, si crees que una buena solución informática es la más eficiente, la más cercana al hardware y que ahí radica la simpleza... no estás en tu momento, vuelve a cuando todo fallaba cada 2 por 3 y los programas tenían bugs y fallos de seguridad explotables en cada operación ofrecida, seguro que eran tiempos mejores y no es una idealización creada por un sentimiento de nostalgia

En resumen, tengo una visión del estado del arte que choca bastante con la del pesimista, sesgadísimo, parcial y mediocre artículo que enlazabas.

» autor: PortgasDAce

#385 Programadores antiguos vs programadores de hoy

JAVH — Fri, 29 May 2020 03:59:31 +0000

#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.

» autor: JAVH

#384 Programadores antiguos vs programadores de hoy

mitocondriaco — Fri, 29 May 2020 01:31:19 +0000

Lo que esta claro es que antes el negocio era el juego y ahora es la gráfica. Antes interesaba que el juego se ejecutara. Ahora que se ejecute regular para que amplíes equipo.

» autor: mitocondriaco

#383 Programadores antiguos vs programadores de hoy

--34825-- — Fri, 29 May 2020 00:55:28 +0000

#380 pues si ya no me acuerdo si habia que configurar el arranque, pero si.

» autor: --34825--

#382 Programadores antiguos vs programadores de hoy

impaler — Fri, 29 May 2020 00:36:55 +0000

#375 Yo al revés, soy más de FPS, pero también todo tipo de árcades y plataformas. De las recreativas antiguas recuerdo haberme viciado un montón con el Final Fight, Knights of the Round y el Aliens, y aún los juego en emuladores. Por cierto, ¿algún otro viejuno que recuerde haber jugado allá por el año 1998 juegos emulados en el Callus 95? Fue un adelanto para la época, te permitía jugar algunas ROMs con otros jugadores a través del módem. 22 años han pasado. ¡Qué tiempos!

» autor: impaler

#381 Programadores antiguos vs programadores de hoy

bitelchus74 — Thu, 28 May 2020 23:58:01 +0000

#192 es este: www.amazon.es/dp/B089465YX1/qid=1590349627&sr=8-1

» autor: bitelchus74

#380 Programadores antiguos vs programadores de hoy

Mustela — Thu, 28 May 2020 23:56:09 +0000

#329 Un 386 bien equipado puede hacer maravillas, ¿pero llegaste a poder ejecutar el Descent? Madre mía...

» autor: Mustela

#379 Programadores antiguos vs programadores de hoy

Mustela — Thu, 28 May 2020 23:51:19 +0000

#287 Los inicios de la informática que estudié fueron de niño, en un aula con ordenadores de pantalla monocromo. Relamente hubieron dos aulas diferentes, una por curso. La primera fue con monitores de fósforo verde, y en la segunda algunas pantallas pasaron a ser de blanco y negro. Estudiábamos conceptos del GW-BASIC y el famoso Logo.

Los ordenadores no tenían disco duro salvo 2 o 3 en el segundo curso, por lo que decidí que mi ordenador se asemejara a estos. Quería hacer mis experimentos y no tener la comodidad de los discos duros que ya palpé en el aula. Eso sí, el color de mi monitor me maravilló. VGA de 256 colores era brutal (precisamente, igual pasa a día de hoy). Una ventaja de no tener disco duro es menor ruido.

El concepto de la informática ha cambiado para el usuario en los últimos 30 años. Realmente es ventajoso e importante conocer y llegar a los límites de una máquina, pero lo más importante es que sepamos dónde está nuestra información en todo momento y qué se hace con esta, algo verdaderamente complicado en estos tiempos que se quiere - casi que obliga - digitalizar todo.

Ah, igualmente pude tener unos cuantos MB de disco gracias al Iomega ZIP de 100MB al cabo de unos años .

» autor: Mustela

#378 Programadores antiguos vs programadores de hoy

Mustela — Thu, 28 May 2020 23:33:55 +0000

#221 Válgame Dios, más que un comentario parecía un procedimiento jajaja. Cuando estoy fuera de horas de trabajo, salvo por privacidad y seguridad, me olvido de muchas cosas de lo que hago.

Cuidado con la tecnología. Mal empleada puede pasar factura, como invertir demasiado tiempo en ella, ser espiado/a, tener alguna fuga de información sin ser consciente, etc.

Por lo de la virtualización, soy propenso a virtualizar lo mínimo aunque reconozco sus ventajas, pero, desde mi punto de vista, si se hace a través de zonas de Solaris o LXC en Linux mejor

Por cierto, ¿qué piensas de los FPGA, al margen de la información que pudiera haber por ahí?

Saludos.

» autor: Mustela

#377 Programadores antiguos vs programadores de hoy

sillycon — Thu, 28 May 2020 23:25:57 +0000

#342 es lo que defiendo: la simpleza.

» autor: sillycon

#376 Programadores antiguos vs programadores de hoy

sillycon — Thu, 28 May 2020 23:22:40 +0000

#337 cuánto consume una raspi? Podría realizar la misma tarea? Si estuviera desarrollado en ensamblador o C, cuánto consumiría?
Y un microcontrolador?

» autor: sillycon

#375 Programadores antiguos vs programadores de hoy

Mustela — Thu, 28 May 2020 23:10:59 +0000

#186 Gracias por el aporte, Impaler. Quizá hace unos años todavía jugaba algo (incluso en red) pero, aunque incluso pudiera verlo divertido, en realidad nunca me acabé de sentir a gusto con este tipo de juegos. Soy más de simuladores o de plataformas, por ejemplo .

» autor: Mustela

#374 Programadores antiguos vs programadores de hoy

Mustela — Thu, 28 May 2020 22:54:09 +0000

#86 De un 286 a un Pentium. ¿Así, tal cual, directamente? No pasaste por 386 ni 486? ¡No está mal! Una preguntilla, ¿qué hiciste con el Amstrad? ¿Lo regalaste?

» autor: Mustela

#373 Programadores antiguos vs programadores de hoy

--636808-- — Thu, 28 May 2020 21:39:23 +0000

#155 con sinceridad, has visto código en empresas reales que use el unique_ptr ?

» autor: --636808--

#372 Programadores antiguos vs programadores de hoy

adrigm — Thu, 28 May 2020 20:30:27 +0000

#371 Que tiene que ver eso? Por mucho que tu aisles el core de tu aplicación (eso ya lo hacemos todos, gracias).

Sigues necesitando luego programar una interfaz con su lógica y sus pruebas para todas las putas plataformas y eso es tiempo y dinero.

Yo no sé en que mundo vives, pero yo vivo en el del desarrollo real donde el cliente te pide estamación de tiempos y costos.

» autor: adrigm

#371 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 20:19:39 +0000

#369 Con ninguno de los dos puedes hacer una solo base de código para: Android, IOS, Web, MacOS, Windows y Linux.

Como que no? No te han hablado de la arquitectura hexagonal?

» autor: --94561--

#370 Programadores antiguos vs programadores de hoy

Sandevil — Thu, 28 May 2020 17:57:00 +0000

#361 Y un infierno de versiones, librerías pesadas, sobreutilización de recursos..

Que con todo el amor y el cariño, es una genial idea las vm, pero deberían plantearse el hacer una nueva versión que rompa con lo anterior.

» autor: Sandevil

#369 Programadores antiguos vs programadores de hoy

adrigm — Thu, 28 May 2020 16:52:38 +0000

#367 En serio, Java y Mono son tus soluciones?

Con ninguno de los dos puedes hacer una solo base de código para: Android, IOS, Web, MacOS, Windows y Linux.

Por cierto lo del lenguaje dinámico tiene fácil solución: www.typescriptlang.org/

» autor: adrigm

#368 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:41:12 +0000

#50 C#, Java o kotlin, pero sobre todo kotlin.

O bueno: C sin punteros...

» autor: --94561--

#367 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:37:51 +0000

#327 J-V-M....
Mono....

No, el asunto es que es mas barato pq se suponer que hay mas gente que sepa hacer eso que uno de los dos que he dicho y les vas a poder pagar menos....

Y bueno, tambien he de decir que los projectos de startups que se sacan en JS para que salgan rapido suelen ser bastantee jodidos de mantener y evolucionar... Maravillas de los lenguajes dinamicos....

» autor: --94561--

#366 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:35:14 +0000

#224 Mira tio, te voy a decir una cosa que no te han dicho en tu casa:

Eres:

ABURRIDO

Dejanos decir gilipolleces tranquilamente, hombre! que no hacemos daño a nadie

» autor: --94561--

#365 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:34:18 +0000

#181 Recuerdo como petaron millones ~~literalmente~~ de paginas web pq alguien quito un metodo de hacer padding de ceros a la izquierda de un repositorio de JS...

» autor: --94561--

#364 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:32:55 +0000

#350 Menos groovy.

Groovy es una mierda.

» autor: --94561--

#363 Programadores antiguos vs programadores de hoy

--94561-- — Thu, 28 May 2020 16:29:49 +0000

#110 La JVM no esta mal...

Ademas Kotlin tambien compila a nativo y a JS.....

Kotlin es BIEN. Es lo mas.

Si tengo un hijo lo llamare Koltin.

» autor: --94561--

#362 Programadores antiguos vs programadores de hoy

GrogXD — Thu, 28 May 2020 16:21:08 +0000

#103 Python es para hace scripts de usar y tirar, no para hacer un sistema que quieras que viva años.

» autor: GrogXD

#361 Programadores antiguos vs programadores de hoy

GrogXD — Thu, 28 May 2020 16:10:44 +0000

#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.

» autor: GrogXD

#360 Programadores antiguos vs programadores de hoy

Peter_Coyote — Thu, 28 May 2020 16:10:29 +0000

Sólo venía a decir que los 'core' de algunas de las grandes empresas de nuestro país siguen en C, C++, o como decía un compañero de curro, C ofuscado. Que ha habido intentos de cambiar todo a Java (y digo Java) y no ha habido narices... Todos los sistemas de alrededor en Java, pero lo chungo chungo en C (y yo he visto trozos de ensamblador incrustados). Si quieres gestionar la memoria de forma eficiente y a lo burro lo mejor es que la reserves tú mismo, y la liberes tu mismo.... Sin intermediarios

» autor: Peter_Coyote

#359 Programadores antiguos vs programadores de hoy

--350694-- — Thu, 28 May 2020 16:08:25 +0000

#159 El problema es que cada vez se construyen mas castillos de mierda encima de otros castillos de mierda con esa excusa ya que es demasiado tarde para hacer las vosas bien y demasiado caro volver a hacerlo todo de nuevo.

El problema es que la ingenieria de software se ha vuelto el proyecto mas complejo que existe y para abordarlo se ha llegado a la conclusion de que es mas facil hacer parches y soluciones que simplifican los problemas a base de perdida de rendimiento, fiabilidad, etc... No creo que exista tal ahorro, solo a corto plazo.

» autor: --350694--

#358 Programadores antiguos vs programadores de hoy

Peter_Coyote — Thu, 28 May 2020 16:04:05 +0000

#194 Buff, recuerdo las prácticas de la universidad en Ensamblador, recuerdo hacer una práctica que en una ventana escribías un texto largo y buscaba palíndromos, y te los mostraba... Lo que sudamos esa semana. Aún no se cómo lo logramos, solo se que yo me desesperé y mi compañero empezó a levitar y entró en trance... Nunca te estaré suficientemente agradecido, Raúl.

Por cierto, recuerdo programar Pic... Si lo hacías en C te quedaba sin espacio en seguida

» autor: Peter_Coyote

#357 Programadores antiguos vs programadores de hoy

Patrañator — Thu, 28 May 2020 15:36:58 +0000

Quizás influya el hecho de que programar para una empresa a menudo implica que el código pasa a ser propiedad de la empresa y no del programador...se le daría más mimo a algo que va a ser tuyo, de la otra manera se queda en " si funciona podemos venderlo"

» autor: Patrañator

#356 Programadores antiguos vs programadores de hoy

Sr.Norte — Thu, 28 May 2020 15:35:30 +0000

#355 No se que ha pasado... Me equivoqué al citar en mi primera respuesta y ahora nada tiene sentido. En cualquier caso no había sido un gran aporte por mi parte

» autor: Sr.Norte

#355 Programadores antiguos vs programadores de hoy

Tom__Bombadil — Thu, 28 May 2020 15:26:42 +0000

#207 Llevo un buen rato intentando entender tu flujo de mensajes. ¿Sabes que #199 también eres tú?

» autor: Tom__Bombadil

#354 Programadores antiguos vs programadores de hoy

adrigm — Thu, 28 May 2020 15:16:19 +0000

#66 Atom murió el día que salió vs code.

» autor: adrigm

#353 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:37:57 +0000

#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)

» autor: --644441--

#352 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:34:02 +0000

#89 Qt ahora soporta Phthon de manera oficial.
Puedes añadir que se pueden hacer frontends de primer nivel

» autor: --644441--

#351 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:32:49 +0000

#155 suscribo lo que dices.
C++ ha vuelto ha renacer
docs.microsoft.com/es-es/cpp/cpp/welcome-back-to-cpp-modern-cpp?view=v

solo apuntar que se debe ver el "modern C++" como un lenguaje nuevo, separado de C++.
Si ya sabes C++, olvidarlo y aprender de nuevo... que te choque cuando veas un new ...

Puedes seguir haciendo las mismas barbaridades de siempre, incluso programar en C,
pero si no tienes vicios de C++, es una pasada, porque es muy sencillo.

Ahora ya cuando veo código de Visual C++ MFC ...me parece un jeroglífico egipcio.

Ya, si a eso le sumas Qt ....

» autor: --644441--

#350 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:24:50 +0000

#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á)

» autor: --644441--

#349 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:20:09 +0000

#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.

» autor: --644441--

#348 Programadores antiguos vs programadores de hoy

--644441-- — Thu, 28 May 2020 14:16:48 +0000

#204 y C++17 ya es flotar en el nirvana

» autor: --644441--

#347 Programadores antiguos vs programadores de hoy

omegapoint — Thu, 28 May 2020 14:05:37 +0000

#345 igual es que me he vuelto viejo y tras 18 años haciendo lo mismo, tardo menos de esta manera que lo que tardan mis juniors en buscar como se hace en stackoverflow o en el manual de referencia de la librería.

Hicimos una pequeña competición hace no mucho, un chavalito con 1 año de experiencia (bastante decente, eso si) usando VUE contra mi usando vanilla js (solo js, haciendo document.createElement y appendChild).

La prueba era llamar a un Json, formatear los datos de una determinada manera y hacer un toggle de CSS al pinchar sobre ciertos elementos.

La teoría decía que el iba a ser mucho más rápido y productivo, la realidad es que sabe más el diablo por viejo que por diablo.

Y que mientras el decía "voy a mirar como era esto", yo picaba en mi notepad++ como el que escribe una carta a su abuela.

Me supo mejor la victoria que el mixto con huevo y el zumo de naranja que gané.

Luego les preguntas que es un shadowroot y no saben de que cojones les hablas.

» autor: omegapoint

#346 Programadores antiguos vs programadores de hoy

squanchy — Thu, 28 May 2020 13:53:19 +0000

#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.

» autor: squanchy

#345 Programadores antiguos vs programadores de hoy

squanchy — Thu, 28 May 2020 13:46:09 +0000

#338 Los nuevos frameworks tratan de que el programador no toque "a mano" el DOM. Por eso han tenido tanto éxito. Yo llevo un par de años con React, y ha sido un gustazo que el programador manazas del equipo no pueda hacer de las suyas.

» autor: squanchy

#344 Programadores antiguos vs programadores de hoy

ur_quan_master — Thu, 28 May 2020 13:43:20 +0000

#25 GB? Seguro?

4Mb más bien.

» autor: ur_quan_master

#343 Programadores antiguos vs programadores de hoy

--130444-- — Thu, 28 May 2020 13:20:01 +0000

#301 de los comentarios más atinados de todo el hilo

» autor: --130444--

#342 Programadores antiguos vs programadores de hoy

PortgasDAce — Thu, 28 May 2020 13:00:49 +0000

#335 Claro que puedes discrepar pero, por supuesto, te equivocas profundamente.

Meter frameworks es ajustarse a la realidad de que no todo el mundo que ponía una aplicación o servicio informático podía permitirse expertos en seguridad o suficientes programadores para adaptar los cambios por leaks, al externalizarlo en equipos que lo hacen por ti se ha mejorado muchísimo el nivel de seguridad medio.

No sé si me expliqué mal o algo, pero es una verdad innegalbe. Obviamente no me refería a que los frameworks sean el camino a seguir para implementar un sistema muy concreto y que necesite una seguridad nivel CIA.

Y no, no es un lujo añadido, es una realidad necesaria o seguiríamos con PCs de 4kb de ram que usaría gente muy concreta. Para llegar a donde hemos llegado hoy y generalizar el uso de la tecnología eran necesarios esos "lujos".

Podemos valorar si donde estamos es mejor o peor, pero las simplonadas que afirmas no son más eso, simplonadas.

» autor: PortgasDAce

#341 Programadores antiguos vs programadores de hoy

PortgasDAce — Thu, 28 May 2020 13:00:20 +0000

...

» autor: PortgasDAce

#340 Programadores antiguos vs programadores de hoy

sieteymedio — Thu, 28 May 2020 12:53:21 +0000

Para qué queremos 9gag cuando tenemos meneame?

» autor: sieteymedio

#339 Programadores antiguos vs programadores de hoy

ccguy — Thu, 28 May 2020 12:46:09 +0000

#318 con react no me das un installable para Windows.

» autor: ccguy

#338 Programadores antiguos vs programadores de hoy

omegapoint — Thu, 28 May 2020 12:42:25 +0000

#85 yo sigo trabajando el DOM con vanilla y jQuery no me parece tan fantástico.

Mátame.

» autor: omegapoint

#337 Programadores antiguos vs programadores de hoy

Tecnocracia — Thu, 28 May 2020 12:40:57 +0000

#336 un móvil te parece que tiene un gasto energético exagerado?

Y en el campo de los PCs?

Pentium 4 3.2Ghz - TDP 82W
i7-8550U - TDP 25W

El 8550U es 22 veces más rápido que el P4

Vaya, no me lo esperaba

» autor: Tecnocracia

#336 Programadores antiguos vs programadores de hoy

sillycon — Thu, 28 May 2020 12:22:09 +0000

#315 El problema es el mercado, amigo. Nadie lo niega.
Mientras tanto necesitamos máquinas descomunales de potencia innecesaria y gasto energético exagerado para tareas básicas.

» autor: sillycon

#335 Programadores antiguos vs programadores de hoy

sillycon — Thu, 28 May 2020 12:20:34 +0000

#316 Discrepo.
Meter más niveles de frameworks no es más que agregar superficies de ataque al sistema. El programa principal debe estar creado según los principios de desarrollo seguro y buenas prácticas, no es necesario "añadirle cosas para protegerlo"

Un UI sofisticado 1º) Generalmente no es imprescindible, es un lujo añadido y 2º) Se puede hacer en un sistema ligero (incluso en HTML5)

» autor: sillycon

#334 Programadores antiguos vs programadores de hoy

kasugak — Thu, 28 May 2020 12:08:55 +0000

Aunque el chiste es un tópico muy manido y con mil consideraciones a tener en cuenta.
Los problemas de hoy en dia son bastante más complejos y simples a la vez.
Se junta una brutal evolución de tecnologías de las que es imposible tener un "expertice" amplio porque cada semana están evolucionando. Con una gran simplicidad de hacer cosas "funcionales".
Lo que se traduce en que cualquiera puede llevar a producción servicios funcionales en la tecnología de moda de turno con mucha facilidad. Al final te encuentras una amalgama de tecnologías diferentes, desactualizadas, con arquitecturas mal diseñadas, mal programadas y con una complejidad a nivel de dependencias brutal.

» autor: kasugak

#333 Programadores antiguos vs programadores de hoy

DangiAll — Thu, 28 May 2020 11:40:12 +0000

#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...........

» autor: DangiAll

#332 Programadores antiguos vs programadores de hoy

DangiAll — Thu, 28 May 2020 11:37:10 +0000

#3 Frameworks............

Un programador de verdad usa mariposas

» autor: DangiAll

#331 Programadores antiguos vs programadores de hoy

xavigo — Thu, 28 May 2020 11:31:26 +0000

#326 TCP y UDP están diseñados para correr encima de cualquier protocolo de nivel 3 (no tiene porqué ser IP) y, por tanto, podrías decir que su corrección de errores es redundante respecto a protocolos de capas inferiores.

TCP tiene reintentos porque las aplicaciones que lo usen necesitan que sus datos estén completos, aparte de que cada segmento pueda llegar en desorden.

UDP se usa cuando no es necesario que los datos lleguen íntegros, ya que puede no ser necesario o incluso, contraproducente. A cambio, te da una sencillez y un overhead pequeño ideal para baja latencia y poca necesidad de proceso. O también puedes usar UDP si capas superiores se van a encargar de toda esa parte porque sabes/supones que la conexión es buena y prefieres la rapidez de UDP.

No vas a meter voz sobre TCP, ni videoconferencias, ni los eventos de un juego online.

Otra cosa es que simplifiques la pila porque no quieras la independencia sobre las capas inferiores. Total, si todo es Ethernet para qué quieres suponer conexiones vía satélite, MPLS, 4G... Eso te lo compro, pero entonces toda esa conversión la vas a tener que hacer en los nodos que cambien de protocolo de nivel 2.

TCP y UDP son una implementación de la capas 4, 5 y 6 de la pila OSI, mucho más simple que ésta y sus particularidades son soluciones a problemas que había entonces y que ahora (como la calidad de las comunicaciones) no son tan frecuentes.

» autor: xavigo

#330 Programadores antiguos vs programadores de hoy

--257647-- — Thu, 28 May 2020 11:31:09 +0000

Yo creo que hay una correlación con la calidad de información memetica que ahora se extiende.

» autor: --257647--

#329 Programadores antiguos vs programadores de hoy

--34825-- — Thu, 28 May 2020 11:19:52 +0000

#15 iba perfectamente sin reducir nada con un 386 con coprocesador. El descent si que habia que reducir un poco para que fuese fluido.

» autor: --34825--

#328 Programadores antiguos vs programadores de hoy

adrigm — Thu, 28 May 2020 11:11:40 +0000

#32 usas PHP y te quejas de los de js.

Electrón usa Chromium que es libre.

» autor: adrigm

#327 Programadores antiguos vs programadores de hoy

adrigm — Thu, 28 May 2020 11:07:18 +0000

#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.

» autor: adrigm

#326 Programadores antiguos vs programadores de hoy

estoyausente — Thu, 28 May 2020 10:53:22 +0000

#325 Joder, es una forma de hablar. Nada funciona por casualidad, pero no es que sean los protocolos mejor especificados del mundo. Están repletos de parches que hacen que funcionen bien pero está por decidir si esos parches son genialidad que solucionan problemas o chapuza que aguanta el tirón.

Pero que todo es así, he visto tripas de bastantes sitios muy grandes, sistemas que usa muchísima gente, sitios que piensas "buah, esto tiene que estar niqueladísimo" y no, no lo está. Tiene sus mierdas dentro que huelen igual de mal que la de cualquier otro sistema. Pero ahí están, corriendo, dando servicio a millones de personas.

» autor: estoyausente

#325 Programadores antiguos vs programadores de hoy

xavigo — Thu, 28 May 2020 10:46:07 +0000

#135 por favor, aunque te entiendo, no metas TCP y UDP y su corrección de errores como ejemplo de “ir con pinzas” o de que funciona de casualidad

» autor: xavigo

#324 Programadores antiguos vs programadores de hoy

acidulante — Thu, 28 May 2020 10:35:35 +0000

#117 Yo igual! Creo que para empezar a formar la cabeza es lo mejor!

» autor: acidulante

#323 Programadores antiguos vs programadores de hoy

Sadalsuud — Thu, 28 May 2020 10:28:27 +0000

#5 Yo pasé de un 286 a un 486 DX2 y no pude jugar Doom hasta tener el 486.

» autor: Sadalsuud

#322 Programadores antiguos vs programadores de hoy

--625430-- — Thu, 28 May 2020 10:26:11 +0000

#147 Y no sirve usar "Elbereth".

» autor: --625430--

#321 Programadores antiguos vs programadores de hoy

fran89 — Thu, 28 May 2020 09:21:35 +0000

#147 jaja precisamente lo poco que sé de ensamblador fué así mismo, de adolescente aprendiendo un poco de cracking, incluso sin haber empezado a aprender a programar. Recuerdo los XOR para los NAGs, cambiar condicionales para que hicieran justo lo contrario (validar un serial incorrecto)... También herramientas como Win32dasm, que habían aplicaciones que tenían seriales correctos en las string references y los depuradores como Softice y Ollydbg. Desempacadores de Aspack, UPX...

Luego ya hice mis pinitos con Visual Basic, Neobook (no es un lenguaje exactamente pero algo así), Delphi, etc. De hecho una de las primeras cosas que hacía eran crackme, intentando programar los trials de X días y eso

» autor: fran89

#320 Programadores antiguos vs programadores de hoy

cristomc — Thu, 28 May 2020 09:06:53 +0000

#319 Es que como usuario final REAL nadie sabe lo que es electron (</corporate-mode>)

Tampoco estoy a favor de electron, solo estoy dando los argumentos por los cuales explico que criticar a js por electron es tontería (y ojo, lo digo por los que han empezando a rajar de js en esta noticia)

Sin embargo, también estoy explicando que ningun lenguaje de programación es bueno si te hinchas a usar librerias /frameworks porque si. Es una necesidad del desarrollador, y si este elije sus preferencias antes que las necesidades del proyecto, da igual que uses TS/React y suputamadre o python/django/pimpinela... tu software será pesado, será poco mantenible conforme escale el proyecto, y el usuario final tampoco obtendrá el producto que necesitaba.

» autor: cristomc

#319 Programadores antiguos vs programadores de hoy

llorencs — Thu, 28 May 2020 08:58:20 +0000

#317 Coño, no estoy en contra de bibliotecas o frameworks.

El problema es que lo veo como un problema como usuario final. Imagina que todos empezaran a usar electron. Para tener abiertas 4 o 5 aplicaciones acabariamos necesitando ordenadores con 32GB o 64GB de RAM. Es un gasto de recursos innecesario, solo por la comodidad del desarrollador.

Se puede optimizar con desarrollos rápidos sin tener que usar tecnologias tan pesadas. Critico electron, no el uso de frameworks o bibliotecas que te faciliten la vida. Coño, soy el primero que las usa. Sin ellas, al no ser desarrollador, sino alguien que programa por diferentes necesidades, las bilbiotecas me salvan la vida.

» autor: llorencs

#318 Programadores antiguos vs programadores de hoy

--30529-- — Thu, 28 May 2020 08:52:09 +0000

[Usuario deshabilitado]

» autor: --30529--

#317 Programadores antiguos vs programadores de hoy

cristomc — Thu, 28 May 2020 08:46:19 +0000

#308 la clave está en esto:

" Herramientas que de ser desarrolladas de otra forma no gastarian ni la mitad. "

Pero te cuestan el coste de desarrollo x (numero de plataformas + numero de desarrolladores)

Que los programadores a veces nos olvidamos del mundo real(TM), pero está claro que en nuestro modelo perfecto programariamos sin librerias, frameworks, en nativo para la plataforma y siguiendo las guidelines de cada SO/entorno... pero la realidad es que el modelo de planificacion de proyectos informáticos modernos solo tienen en cuenta 3 variables: coste, tiempo y calidad... y solo puedes tener 2 de 3.

» autor: cristomc

#316 Programadores antiguos vs programadores de hoy

PortgasDAce — Thu, 28 May 2020 08:28:59 +0000

#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.

» autor: PortgasDAce

#315 Programadores antiguos vs programadores de hoy

Tecnocracia — Thu, 28 May 2020 08:21:35 +0000

#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

» autor: Tecnocracia

#314 Programadores antiguos vs programadores de hoy

wondering — Thu, 28 May 2020 08:13:57 +0000

#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.

» autor: wondering

#313 Programadores antiguos vs programadores de hoy

Sr.Norte — Thu, 28 May 2020 07:43:38 +0000

#288 Totalmente de acuerdo. La idea es muy similar a la que yo comento. El hecho de que el intérprete y el propio lenguaje hayan nacido en el seno de los navegadores han hecho a JS partícipe del boom de la web. Pero creo que se habría quedado ahí de no ser por Node. El hecho de llevar un lenguaje sencillo y con buen rendimiento al lado del servidor lo ha puesto definitivamente en el mismo saco que Java y C#, dejando de ser un lenguaje de "scripting" al uso para asumir un papel mayor.

En cuanto al fundamentalismo anti-JS, una inmensa mayoría habla desde la ignorancia, pensando en scripts infumables incrustados en un head, "this" que son cualquier cosa menos "this", variables globales, etc... Sin embargo muy poca gente está familiarizada con ES 6/7 y Babel o con TypeScript y con que hace tiempo que están resueltas.

» autor: Sr.Norte

#312 Programadores antiguos vs programadores de hoy

drnth — Thu, 28 May 2020 07:39:27 +0000

#303 Gracias, llevo tiempo con ganas de aprender otro lenguaje y Python estaba en mi radar. Ahora sólo necesito tiempo libre.

» autor: drnth

#311 Programadores antiguos vs programadores de hoy

Sr.Norte — Thu, 28 May 2020 07:27:28 +0000

#294 Bizarro como su acepción principal: "Valiente"

» autor: Sr.Norte

#310 Programadores antiguos vs programadores de hoy

Ludovicio — Thu, 28 May 2020 07:24:35 +0000

#224 Pues básicamente javascript es... como si la gente fuese a trabajar o a comprar el pan en tractores.
No es que consuma mucho o poco... es que no se diseño para eso y no hace bien esa función.
Y ahora fabrican tractores con carrocería de coche y aire acondicionado, pero siguen siendo tractores.

» autor: Ludovicio

#309 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Thu, 28 May 2020 07:17:35 +0000

#275 No. No se hace. Que los efectos de sonido se creen con síntesis y luego se samplee para eincluirlos en un videojuego no significa que los videojuegos usen síntesis en tiempo real. Cualquier título triple A tiene cientos de megas de samples. Que se haga de vez en cuando sigue sin convertirlo en la edad dorada de los sintetizadores. Cuando en los videojuegos se sintetice el sonido en tiempo real y sea algo relativamente extendido podremos llamarlo la edad de oro del sintetizador.

Con esto del confinamiento tengo un vicio a Skyrim como no he tenido nunca y todo son samples. Los efectos de sonido son muy poco variados y siempre suenan igual. No sé si sin mis altavoces de mierda pero todas las pisadas suenan igual, da igual que sean botas de metal o de cuero y desenvainar siempre suena igual, no importa si es un martillo a dos manos o una espada. Y golpear un obstáculo suena igual, da igual si es una roca o un árbol.

Como no se pueden hacer samples para todas las casuísticas posibles hay que sintetizar en tiempo real si queires hacerlo innmersivo.

» autor: empanadilla.cosmica

#308 Programadores antiguos vs programadores de hoy

llorencs — Thu, 28 May 2020 07:15:18 +0000

#305 Creo que hemos dicho lo mismo

Cada herramienta tiene sus finalidades o sus puntos fuertes. Javascript para frontend de la web (no sé como traducir frontend al castellano, que mierda que no lo hayamos traducido como toca y usemos la palabra inglesa). Y quizás ahora también se puede usar en el servidor.

El problema que mencionaba era de usar JS para escritorio era acabar teniendo aplicaciones aparentemente sencillas que ocupan 200-400MB de RAM. Con lo cual teniendo un par de esas abiertas acabas gastando 2GB de RAM. Es decir, tienes herramientas super pesadas que desarrolladas de otra manera lo serían mucho menos. Afectando al rendimiento.

En mi caso, tengo Postman 600MB, Visual Studio Code, otros 600MB y una herramienta de la compañia 1GB. Con tener las 3 abiertas ya gasto más de 2GB de RAM. Todo por ser páginas dentro de un navegador completo. Este sistema es contraproducente.

Herramientas que de ser desarrolladas de otra forma no gastarian ni la mitad.

» autor: llorencs

#307 Programadores antiguos vs programadores de hoy

eqas — Thu, 28 May 2020 07:14:23 +0000

Pues si supierais lo que hacían los cartuchos del MSX (Salamander, Nemesis...) con 64 kb.... o incluso los de 32 (King's Valley, etc.), es para llorar con la comparación.

» autor: eqas

#306 Programadores antiguos vs programadores de hoy

Ludovicio — Thu, 28 May 2020 07:08:31 +0000

#18 C# ? Joder, ya no te puedo quitar el positivo de #6

» autor: Ludovicio

#305 Programadores antiguos vs programadores de hoy

cristomc — Thu, 28 May 2020 07:05:40 +0000

#292 ermmm Node (que es JS) está pensado para ese tamaño y más.

Los videojuegos de navegador (o hechos con JS, que los hay) superan esos tamaños sin problemas.

Sobre lo de Python y PHP solo te diré que si usas python para web terminas teniendo lo mismo que js, y si usases PHP para escritorio, lo que te faltaría son librerias y añadidos que otros lenguajes tienen y php no porque no hay comunidad que esté interesada en desarrollarlo (sin ir mas lejos, tienes GTK y QT compatible con PHP para lanzar una GUI en escritorio, y desktop PHP para generar ejecutables, pero poco mas).

Vuelvo a lo mismo de antes: el problema no son los lenguajes, si eres tan mendrugo como para elegir php para una app de escritorio ,serás igual de mendrugo escogiendo python para X proyecto aunque no sea el lenguaje que necesites.

» autor: cristomc

#304 Programadores antiguos vs programadores de hoy

ciquitraque — Thu, 28 May 2020 07:04:41 +0000

Vamos que no tenéis ni puta idea de programar muchos de los que opináis pero ahí estáis, dándole a la tecla.

» autor: ciquitraque

#303 Programadores antiguos vs programadores de hoy

FooDev — Thu, 28 May 2020 06:58:42 +0000

#269 Pues...principalmente por las siguientes razones:

- Es de propósito general
- Permite programar rápido
- Es fácil de leer y elegante (gracias a que prescinde de llaves y obliga a indentar)

Si no tienes experiencia con el lenguaje te recomiendo echar un ojo a los 20 principios zen de Python.

Por supuesto hay cosas que también me disgustan. Posiblemente de las que más, que los métodos y atributos de las clases no soportan restricciones de visibilidad.

» autor: FooDev

#302 Programadores antiguos vs programadores de hoy

Zopokx — Thu, 28 May 2020 06:52:01 +0000

Todo mi amor y eterno respeto a desarrolladores de #HandmadeSoftware y desarrollos como raylib (raylib.com) que muestran cómo se deberían hacer las cosas SIEMPRE.
O cambian las cosas, o el mundo se va a ir a la mierda por exceso de código y falta de optimización (literalmente)

» autor: Zopokx

#301 Programadores antiguos vs programadores de hoy

ringo2006 — Thu, 28 May 2020 06:51:10 +0000

La programación “actual”, con todos sus problemas, ha traido cosas como un buscador que te da resultados en un segundo sobre un conjunto de datos de tamaño mundial. Plataformas de video en streaming con miles, sino millones de usuarios simultáneos.
A los programadores de C, ya les criticaban entonces por no usar ensamblador, a los de c++ por no usar C, a los de java por no usar C++, a los de javascript por no usar java, etc.
En programación como en todo problema con recursos finitos y problemas enormes, hay que tomar decisiones de compromisos y gracias a todos esos lenguajes y librerías se han podido afrontar nuevos problemas, que hubieran sido inconcebibles con la generación anterior de herramientas para el 99% de programadores.

» autor: ringo2006

#300 Programadores antiguos vs programadores de hoy

SergioZgz — Thu, 28 May 2020 06:42:25 +0000

#224 Como que no todo tienen que ser virguerias funcionales programadas en haskell?? a pocas charlas has ido tu los ultimos 2 años... madre mia que puto coñazo todo el mundo mordernillo metiendo programacion funcional en cualquier sitio... no tio que los try catch son "EL MAL", mira mira que "mónadas".... que cansinos con meter "lo nuevo/de moda" donde sea

Me pasa como a uno que ha escrito por encima... antes era de los hacerme cualquier cosa que no existiera y compartirla... estuve colaborando activamente en OpenCV años y era de los de currar 8 horas y picar en casa otras 8 en proyectos personales... ahora estoy cansado/quemado

» autor: SergioZgz

#299 Programadores antiguos vs programadores de hoy

yeik — Thu, 28 May 2020 06:39:28 +0000

Yo me acuerdo con estas discusiones de usar o no usar frameworks, me acuerdo de el caso de un chaval al que el padre o el padrastro lo tenía secuestrado (a el y a toda la familia, no les dejaba salir de casa). No recuerdo si lo leí aquí en meneame...

Estuvo años así el chaval y le gustaba bastante la informática, así que en todo ese tiempo encerrado se montó su propio sistema operativo formandose con revistas y libros "antiguos" (no tenía acceso a nada nuevo mientras estuvo encerrado).

El caso es que hizo un buen trabajo e incluso implementó cosas "nuevas", al menos nuevas para cuando dejó de tener contacto con el mundo exterior.
Al final consiguió salir de allí, no recuerdo muy bien como si denunciaron y los sacó la policía o qué. Pero cuando el chaval volvió a la realidad la realidad le había adelantado por la derecha, todo había avanzado increiblemente a nivel de software y su sistema era un mojón ochentero que no valía para nada.

Moraleja: No reinventes la rueda. La RAM y los procesadores valen dinero pero tu tiempo vale más.

» autor: yeik

#298 Programadores antiguos vs programadores de hoy

ccguy — Thu, 28 May 2020 04:33:35 +0000

#183 Dime uno. Pero que tenga soporte de interfaz de usuario, no me digas un lenguaje maravilloso para backend pero que no tenga capacidad ni de pintar un cuadrado en pantalla.

» autor: ccguy

#297 Programadores antiguos vs programadores de hoy

almeriensis — Thu, 28 May 2020 00:06:16 +0000

#257 Tengo el número 1 de Microhobby. Todavía tengo en la memoría el día que lo compré. Un recuerdo muy claro, y muy bonito.

» autor: almeriensis

#296 Programadores antiguos vs programadores de hoy

almeriensis — Wed, 27 May 2020 23:57:34 +0000

Supongo que poquitos han programado en un CP/M con 5MB de disco duro. En COBOL, evidentemente.

» autor: almeriensis

#295 Programadores antiguos vs programadores de hoy

fleong — Wed, 27 May 2020 21:59:45 +0000

Y por eso es tan importante que los programadores sean conscientes de la arquitectura de la máquina, para exprimirla hasta el tuétano. Pero hoy haces dos cursitos online de un lenguaje y a picar código

» autor: fleong

#294 Programadores antiguos vs programadores de hoy

llorencs — Wed, 27 May 2020 17:58:50 +0000

#284 Bizarro como generoso?

» autor: llorencs

#293 Programadores antiguos vs programadores de hoy

pawer13 — Wed, 27 May 2020 17:50:27 +0000

#188 aquí otro Javero, encantado de que comparen a java con cobol:eso significa que durará unos 40 años más.
Y pasemos de oracle, openjdk FTW!

Python es JS hecho un poco más elegante, realmente entiendo que se use para que los no programadores pueden hacer aplicaciones para gestionar datos estadísticos porque la sintaxis es sencilla, pero no veo que aporte nada especial.

» autor: pawer13

#292 Programadores antiguos vs programadores de hoy

llorencs — Wed, 27 May 2020 17:49:15 +0000

#258 JS esta diseñado para web. No para correr aplicaciones de 200MB-400MB mínimo. Ese es el problema.

Python, está diseñado como de uso general y no necesitas un navegador para crear una interfaz gráfica. La memoria que requiere Python es muy inferior a Javascript + Electron.

PHP está pensado para esribir código de servidor web. No está diseñado para escritorio.

» autor: llorencs

#291 Programadores antiguos vs programadores de hoy

--84408-- — Wed, 27 May 2020 16:51:53 +0000

#277 Te confundes con los juegos de 3d de años posteriores, el Doom original solo requería esto:

Mínimo CPU 386 (recomendada 486)
4 Mb RAM
Tarjeta gráfica VGA
36 MB de HDD.
(recomendada Tarjeta de sonido Sound Blaster).

» autor: --84408--

#290 Programadores antiguos vs programadores de hoy

ny80 — Wed, 27 May 2020 16:21:07 +0000

#25 El Doom no requería un 486 (goto #34). En un 386 DX se podía jugar bien.

» autor: ny80

#289 Programadores antiguos vs programadores de hoy

ny80 — Wed, 27 May 2020 16:17:51 +0000

#112 Sí, pero se notaba si se lo ponías. El Doom en un 386 DX con coprocesador era bastante jugable a pantalla completa.

» autor: ny80

#288 Programadores antiguos vs programadores de hoy

scalvo — Wed, 27 May 2020 16:11:18 +0000

#281 Estoy en una situación parecida a la tuya... Todo el mundo odia Js, a mí me encanta...

Pero más allá de eso, yo creo que el éxito real de Js no está ni en los frameworks front (que sí), ni en Node (que también). Sino que Javascript es el primer, y probablemente único, lenguaje que cumple eso de "Write Once Run Everywhere" que prometía Java y que nunca cumplió. Y ese éxito, probablemente, se deba a que por el hecho de ser el único lenguaje interpretable en navegador han optimizado el intérprete de Javascript al máximo. Otros lenguajes interpretados como Python o Ruby no tienen intérpretes tan flexibles... no parece probable que metan un intérprete de python en relojes, o lavadoras, o neveras... Me da a mí que varios relojes ya llevan un intérprete de javascript... Las teles lo llevan, y las neveras lo llevarán...

» autor: scalvo

#287 Programadores antiguos vs programadores de hoy

ny80 — Wed, 27 May 2020 16:06:49 +0000

#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...

» autor: ny80

#286 Programadores antiguos vs programadores de hoy

--335641-- — Wed, 27 May 2020 15:58:06 +0000

#220 Aquí un arquitecto de software con mas de 15 años de experiencia. Entiendo tu reflexión perfectamente a nivel de sintaxis. Pero en cuanto a rendimiento, gestión de threading, es horrible. Se gana en velocidad de producción, pero la calidad general de aplicativos deja mucho que desear. I ese es un tema crucial por lo que se refiere a responsabilidad de mi rol. Otro tema también es la retrocompatibilidad entre versiones.

» autor: --335641--

#285 Programadores antiguos vs programadores de hoy

O.OOЄ — Wed, 27 May 2020 15:06:46 +0000

#48 Se nota que ese tío sabe, porque está usando DR-DOS

» autor: O.OOЄ

#284 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 14:45:14 +0000

- Un mismo desarrollador puede adaptarse a front o a back según las circunstancias sin necesidad de aprender un lenguaje.
- Lo que ya sabías de los tiempos de JQuery, puede servirte para hacer una API
- Una de mis preferidas: Las aplicaciones isomórficas y el Server Side Rendering. (Esto daría para otra biblia)
- La posibilidad de generar aplicaciones móviles nativas de forma sencilla con proyectos como ReactNative, NativeScript, o Vue Native.
- Se abre la puerta a las PWAs (aplicaciones web progresivas.

Y si te sientes bizarro, y metes MongoDB en la ecuación, hasta la BD estará en JSON.

Creo que en front sencillamente JS no tiene competencia. Y en back, ha demostrado que es mucho más rápido en tiempo de desarrollo. Aparte es un lenguaje mucho menos restrictivo que Java o C#. Por eso creo que la comunidad lo recibe mejor también en lo que se refiere a la parte del servidor.

» autor: Sr.Norte

#283 Programadores antiguos vs programadores de hoy

estoyausente — Wed, 27 May 2020 14:43:48 +0000

#262 Si, estoy de acuerdo en general con todo lo que dices. Al final... es nuestra profesión Para lo bueno y para lo malo.

Al menos yo tengo la suerte de estar en un sitio donde me obligan (no solo es que me dejen...) a hacer las cosas bien. Con test, bien documentadas... No es la panacea, tiene sus mierdas, como todo. Pero al menos ese gusto me doy

» autor: estoyausente

#282 Programadores antiguos vs programadores de hoy

Nathaniel.Maris — Wed, 27 May 2020 14:34:34 +0000

#268 Ya claro, que una aplicación tenga 750 librerías de mierda o que tenga embebido un chrome entero en vez de hacer una aplicación decente no tiene nada que ver ... verdad?

» autor: Nathaniel.Maris

#281 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 14:32:53 +0000

#249 Vaya, creí que nadie iba a encender esa mecha . Voy a tratar de ser breve, pero el tema da para mucho...

En primer lugar, todos más o menos hemos estado presentes en la evolución de la web. Cuando JS era el "lenguaje pegamento" para hacer las cuatro cosas que necesitaban programación dentro de una web estática. Pero con los años, la demanda de una web cada vez más reactiva y con una UX más completa fue desplazando más y más lógica de negocio al front end. Esto generó una época dorada del front end que dura hasta hoy.

Desde hace algunos años, el concepto de cliente servidor clásico, en el que un back end "compila" una web dados unos datos de entrada y genera un HTML "estático" de salida está muriendo. Ahora la web prácticamente se construye en tu navegador con JS (como en el caso de librerías como React o Vue y frameworks como AngularJS y Angular). La idea pasa por pedir al servidor la "receta" que viene en forma de scripts de JS, y ejecutar todo en front, de manera que las interacciones del usuario sean respondidas en el acto, y la información fluya entre servidor y cliente en segundo plano.

En paralelo a todo esto, la gente de google desarrolla chromium y junto con él, el motor v8 de JS dando resultados de rendimiento muy buenos. Como consecuencia de esto nace NodeJS, entorno de ejecución de JS en el lado del servidor y así se forja el ya famoso paradigma de "JS Everywhere".

Y aquí es donde entra mi opinión.

He trabajado con muchos lenguajes, arquitecturas y frameworks diferentes. Actualmente llevo casi 4 años como desarrollador fullstack JS. después de 3 años en ASP .Net Framework y ASP .Net Core. El hecho de tener el mismo lenguaje en cliente y servidor tiene una barbaridad de ventajas, como por ejemplo:
No tener que depender de librerías externas para el marshalling de JSON (ya que la notacion de objetos de javascript es reconocida directamente por el propio JS)

» autor: Sr.Norte

#280 Programadores antiguos vs programadores de hoy

Jeron — Wed, 27 May 2020 14:30:18 +0000

The Pokemon Company se está forrando con Pokemon Go y están centrando todos sus esfuerzos en esa división y han pasado del resto.

Creo que hicieron Pokémon Espada y Escudo un poco por poner algo de la saga en Switch (sin contar Let's go Eevee y Pikachu) y no se han matado mucho en los nuevos. Gráficos de ps2, pokedex capada cuando están todos los modelos hechos y sólo los han copiado de 3DS... A ver qué tal las expansiones pero espero que estén escuchando a los fans para mejorar sus juegos.

» autor: Jeron

#279 Programadores antiguos vs programadores de hoy

CidFapeador — Wed, 27 May 2020 14:29:52 +0000

Informáticos boomer: la película

» autor: CidFapeador

#278 Programadores antiguos vs programadores de hoy

--376281-- — Wed, 27 May 2020 14:28:13 +0000

os dejo aquí el cubito de bilis a los que no entendéis javascript

\ ________________________________________________/

» autor: --376281--

#277 Programadores antiguos vs programadores de hoy

Goomer — Wed, 27 May 2020 14:27:16 +0000

#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.

» autor: Goomer

#276 Programadores antiguos vs programadores de hoy

--164239-- — Wed, 27 May 2020 14:21:51 +0000

Yo sigo haciendo todo en c++, apps, backend, para todo tipo de dispositivos y sistemas operativos.
La unica excepcion es javascript por que obligan en el frontend, pero bueno, le tengo cariño.
Intenté flirtear un poco con golang para programacion asincrona, pero despues de ver lo que ocupa el hello world y la memoria que puede llegar a usar el garbage collector, volví al c++ también para la programación asincrona, al final va 4 veces más rápido y usa infinita memoria menos.
Creo que el futuro sigue siendo el C++

» autor: --164239--

#275 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 14:19:04 +0000

#274 Hola, eso ya existe desde el motor de Unreal y OpenAL, creo que tienen un modulo de sistesis de voz para narrativa. Al menos es asi en The Nameless Mod para DeusEX. Lo mismo con los efectos de sonido, mas viejo que el mear. LADSPA en Linux desde milenios, y cualquier cacharro multimedia desde los 80.

» autor: --625430--

#274 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Wed, 27 May 2020 14:16:52 +0000

#267 Cuando me refiera a esta época me refiero a la actualidad, o de hace ocho años a la actualidad. Si hay alguna edad de oro del software español es ahora.

Igual que si hay una era del sintetizador no son los 90, serán cuando los motores de sonido de los videojuegos sinteticen el audio en tiempo real en lugar de poner muchos samples que siempre suenan igual. Y las voces de los personajes no sean grabadas sino sinteticen la voz de cada personaje, cada uno con su voz. Y no suene igual cuando disparas y estás pegado a una pared que cuando disparas a campo abierto o desde dento de una habitación de dos por dos.

» autor: empanadilla.cosmica

#273 Programadores antiguos vs programadores de hoy

redscare — Wed, 27 May 2020 14:16:28 +0000

#266 Gracias por lo de jovencito, ojala! Lo de Oracle no lo decía porque sean los dueños actuales de java (que también) sino porque llevo muchos años currando con otros de sus productos

» autor: redscare

#272 Programadores antiguos vs programadores de hoy

NapalMe — Wed, 27 May 2020 14:15:32 +0000

UID de cualquier cosa que requiera un framework y requisitos mínimos de software por parte del cliente.

» autor: NapalMe

#271 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Wed, 27 May 2020 14:09:56 +0000

#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.

» autor: empanadilla.cosmica

#270 Programadores antiguos vs programadores de hoy

NapalMe — Wed, 27 May 2020 14:07:45 +0000

A quien le sorprenda como se hacian los juegos antes, es que realmente no sabe programar, sabe usar un framework sin entender que hay detrás. El la misma gente que odia los punteros en vez de dar gracias por tenes acceso a ellos.

» autor: NapalMe

#269 Programadores antiguos vs programadores de hoy

drnth — Wed, 27 May 2020 14:07:00 +0000

#117 ¿Con qué argumentos? Brevemente, si no quieres extenderte.

» autor: drnth

#268 Programadores antiguos vs programadores de hoy

omega7767 — Wed, 27 May 2020 13:57:29 +0000

#241 no mezclemos el tocino con la velocidad
rapidez del telefono es independiente de la bateria. Ahora mismo puedes hacer una aplicacion muy mal programada, con imagines enormes y el tlf va a funcionar igual, eso no era posible con los primeros tlf

» autor: omega7767

#267 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 13:57:06 +0000

#257 #265 Edad de oro poco, son juegos bastante mediocres comprados con los britanicos. Y los eslavos les daban mil vueltas.
Lo siento pero tenia que decirlo. La Abadia del Crimen no puede competir con Where Time Stood Still.
Y si nos vamos al port de Elite, la edad de oro no llega a ni a la edad de la quincalla.

» autor: --625430--

#266 Programadores antiguos vs programadores de hoy

drnth — Wed, 27 May 2020 13:55:00 +0000

#188 ¿Un jovencito por aquí? A mi me empezó a dar de comer Sun, no sabía mal. Oracle vino después y nos ha cambiado la receta.

» autor: drnth

#265 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Wed, 27 May 2020 13:51:56 +0000

#257 En esta época hay un buen montón de empresas españolas triunfando en el mundo, o integradas en grupos de estudios más grandes.

» autor: empanadilla.cosmica

#264 Programadores antiguos vs programadores de hoy

chavi — Wed, 27 May 2020 13:50:32 +0000

#263 Claro que tienen sus ventajas. Pero no para todo.

» autor: chavi

#263 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Wed, 27 May 2020 13:48:24 +0000

#213 Si, pero en ese caso no puedes aceptar proyectos nuevos que no se parezcan al proyecto antiguo a menos que el cliente acepte que los plazos serán mucho más grandes que tus otros proyectos.

Y por otra parte creo que elegir framework o lenguaje es un lujo que solo te puedes permitir cuando vas a iniciar un proyecto. Después le va a tocar a otra persona mantener aquello. O a tu yo del futuro y además no trabajas solo. Un framework obliga a todos los miembros del proyecto a trabajar de la misma manera.

Si no tuvieran sus ventajas no se usarían.

» autor: empanadilla.cosmica

#262 Programadores antiguos vs programadores de hoy

raistlinM — Wed, 27 May 2020 13:47:28 +0000

#201 Yo en realidad pienso que por lo general nadie es "realmente culpable", se junta un poco de todo, como dices... tema de costes, las empresas al final están para ganar dinero, y a nosotros (los que curramos en el sector, picando...) nos gusta que a fin de mes nos paguen.

Sobre todo a los que somos de vocación nos gusta hacer las cosas lo mejor que sabemos y aprender, y gastar el tiempo necesario en dejarlo bien, con tiempo, experiencia y la capacidad de cada uno esto va siendo menos costoso con el tiempo, pero visto globalmente desde arriba, en que lo que tienes es un mix de "capacidades" al final... lo que quieres es vender el producto o cobrar por lo que haces para tener beneficios y pagar a tu gente, así que muchas veces desde arriba lo que quieren es tenerlo pronto y "cumpliendo", si se puede hacer mejor, más rápido... pero el cliente no va a pagar más ni posiblemente se vaya a enterar... no interesa, es más coste, y en consecuencia la presión va a tenerlo rapidito y baratito.

A mi me han llegado a contar de alguna empresa, pequeña, en la que directamente eran sinceros con el asunto, básicamente lo que se decía a la plantilla es que esfuerzo cero en testing, facilidad de mantenimiento... que funcionase y a correr, pq por lo visto un altísimo porcentaje de lo que desarrollaban no estaba mucho tiempo en el mercado y según sus cuentas eso era dinero tirado.

Luego tampoco es que venga sólo a veces de arriba, quien no tiene un compi hipermotivado que tecnología nueva que aparece tecnología que quiere meter en el producto, dándose casos de productos en los que con el tiempo acabas teniendo 3 o 4 lenguajes, 5 frameworks, movidas de estas instaladoras de módulos, sistemas de compilación, virtualización diversa... lo que iba entrando por que iba a simplificar el mantenimiento o la gestión al final la acaba complicando, por que donde antes el personal tenía que dominar un sistema de compilación o un lenguaje ahora se encuentra con que hay partes en X, partes en Y, 2 sistemas de compilación por que fue imposible quitar del todo el anterior o por que versiones a las que aún hay que dar soporte usan el anterior...

» autor: raistlinM

#261 Programadores antiguos vs programadores de hoy

cosmonauta — Wed, 27 May 2020 13:45:26 +0000

#77 Es que no lo es. No hay comparación.

» autor: cosmonauta

#260 Programadores antiguos vs programadores de hoy

howareme — Wed, 27 May 2020 13:42:16 +0000

#194 Me dicen de gestionar de nuevo manualmente la memoria (en asm) y me tiro por la ventana

» autor: howareme

#259 Programadores antiguos vs programadores de hoy

cosmonauta — Wed, 27 May 2020 13:40:47 +0000

#125 He visto facturas de Amazon que permitirían montarte un data center enteró en 6 meses.

Pero no solo los servidores, no.. completito, con su aire acondicionado, los tecnicos, las batas blancas y todas las lucecitas habituales.

» autor: cosmonauta

#258 Programadores antiguos vs programadores de hoy

cristomc — Wed, 27 May 2020 13:34:45 +0000

#246 JS está diseñado para lo mismo que está diseñado python, php y ruby: para programar sin compilar. De ahí el uso que se le de depende proporcionalmente de tu funcionalidad (Y precisamente el enlace que apuntas va en esa direccion.)

» autor: cristomc

#257 Programadores antiguos vs programadores de hoy

Goomer — Wed, 27 May 2020 13:31:18 +0000

#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,...

es.wikipedia.org/wiki/Edad_de_oro_del_software_español

» autor: Goomer

#256 Programadores antiguos vs programadores de hoy

PacoJones — Wed, 27 May 2020 13:25:58 +0000

#254 Estás rizando el rizo, he dicho "cualquier cosa es más divertida que ensamblador", no me he puesto a comparar C con C++ pero supongo que has venido a hablar de tu libro sea como sea.

» autor: PacoJones

#255 Programadores antiguos vs programadores de hoy

casius_clavius — Wed, 27 May 2020 13:23:55 +0000

#250 Te agradezco mucho el comentario y que lo hayas elaborado tanto. Creo que con todo lo que me han recomendado en el hilo, echaré un vistazo a Rust. C++ lo usé hace muuuucho tiempo y me da que lo que aprendí me va a servir de poco ahora.

» autor: casius_clavius

#254 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 13:22:28 +0000

#251 Todos los que dicen "que mas da" no han entendido C en absoluto y son mayormente programadores de Windows.
Cuando usas C bajo Unix es cuando no quieres volver a tocar C++ ni con un palo.

» autor: --625430--

#253 Programadores antiguos vs programadores de hoy

wizcocho — Wed, 27 May 2020 13:21:13 +0000

#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...

» autor: wizcocho

#252 Programadores antiguos vs programadores de hoy

WifredoIII_ElGayu — Wed, 27 May 2020 13:20:20 +0000

La culpa la tienen los virtuosos del código, esos del Clean Code y de las librerías y los microservicios... Todo es muy bonito cuando pasan por ahí... ahora, el código compilado... da asquete...

Con picha grande bien se jode...

» autor: WifredoIII_ElGayu

#251 Programadores antiguos vs programadores de hoy

PacoJones — Wed, 27 May 2020 13:18:46 +0000

#248 Bueno pues C++ ¿qué más da? cualquier cosa es más fácil y divertida que ensamblador.

» autor: PacoJones

#250 Programadores antiguos vs programadores de hoy

pollo — Wed, 27 May 2020 13:17:15 +0000

#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 ( msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programmi ), 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++).

» autor: pollo

#249 Programadores antiguos vs programadores de hoy

scalvo — Wed, 27 May 2020 13:17:13 +0000

#198 "¿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."

Me interesa, y mucho....

» autor: scalvo

#248 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 13:17:08 +0000

#247 Aqui han dicho C++, no C. C++ es una bestia parda.

» autor: --625430--

#247 Programadores antiguos vs programadores de hoy

PacoJones — Wed, 27 May 2020 13:16:36 +0000

#76 ¿En serio lo dices? ¿Por qué crees que nacieron lenguajes como C?

» autor: PacoJones

#246 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 13:00:08 +0000

[Usuario deshabilitado]

» autor: --30529--

#245 Programadores antiguos vs programadores de hoy

elmike — Wed, 27 May 2020 12:45:24 +0000

#222 No todos los SX eran capados, citando a la propia Wikipedia: "Intel 80486-SX - un i486DX con la unidad de coma flotante deshabilitada por defecto de fabricación (más tarde sería deshabilitada aun sin defecto para cubrir la creciente demanda de modelos SX)."

En su dia en alguna revista lei que eran unidades defectuosas, que luego los caparan deliveradamente por questiones de marqueting, no me extraña practicas similares son habituales. Sea como sea el 486 esta soldado en placa(y digo esta por que todavia lo tengo) y la unica manera de ampliar era poner el 487 en un socket vacio, aunque claro en aquella epoca con un 486, 4Mb de ram y 130Mb de disco duro, cierto informatico me dijo: "pero para que quieres eso!!! ni que fueras la Nasa!!!".

es.wikipedia.org/wiki/Intel_80486#Variantes_del_i486

» autor: elmike

#244 Programadores antiguos vs programadores de hoy

Whitefox — Wed, 27 May 2020 12:30:16 +0000

Gamefreak no es precisamente el mejor ejemplo de programadores. Hacen cada chapuza...

» autor: Whitefox

#243 Programadores antiguos vs programadores de hoy

cristomc — Wed, 27 May 2020 12:23:22 +0000

#237 si con 25 años de experiencia no entiendes que las librerías/frameworks/paquetes como electron responde a una necesidad de mercado...

Te lo pongo de otra manera: Para un manager es mejor soltar pasta 1 sola vez por el desarrollo y tenerlo en pc/movil/web que pagar 3 veces por 3 aplicaciones bien diseñadas y optimizadas.

Que esté de acuerdo en que electron es una mierda (que lo es, no lo niego) no implica que JS para cualquier entorno sea malo. En resumen: no hay malos lenguajes ni malos programas, hay malos programadores y malos gestores de proyectos. Sino mira precisamente la queja de esta noticia en portada www.meneame.net/story/jefe-informatica-tc-renuncia-hostigamiento-invol

"Las persistentes órdenes contradictorias como la de ordenarme, primero, no poner los medios necesarios para la realización de teleconferencias durante el confinamiento, para obligarme, después, a ponerlos en 24 horas, y terminar acusándome de ser la causa del no uso de las mismas en las controvertidas deliberaciones que se han producido en las últimas semanas en su Sala (derecho de reunión y manifestación) y Pleno (decisión sobre reanudación de plazos procesales"

Dejando de lado el aspecto político que rodea a la noticia, la frase que cito refleja el sentir de miles de programadores a nivel mundial.

» autor: cristomc

#242 Programadores antiguos vs programadores de hoy

--618870-- — Wed, 27 May 2020 12:17:12 +0000

#5 el Doom lo vi yo la primera vez funcionar en un IBM PS1 y era un 386

» autor: --618870--

#241 Programadores antiguos vs programadores de hoy

Nathaniel.Maris — Wed, 27 May 2020 12:14:29 +0000

#180 Claro, por eso todos los teléfonos con 30000 mah de batería y 4 aplicaciones les dura la batería 3 meses. ¡Claro que si guapi!

» autor: Nathaniel.Maris

#240 Programadores antiguos vs programadores de hoy

traviesvs_maximvs — Wed, 27 May 2020 11:57:59 +0000

#237 En realidad has entrado como elefante en cacharrería riéndote de quienes programamos en js y poniendo en duda nuestra valía pero vaya, por mi puedes seguir desde tu atalaya lanzando heces a quienes consideras 'programadores'.

» autor: traviesvs_maximvs

#239 Programadores antiguos vs programadores de hoy

--642010-- — Wed, 27 May 2020 11:51:59 +0000

[Usuario deshabilitado]

» autor: --642010--

#238 Programadores antiguos vs programadores de hoy

harapo — Wed, 27 May 2020 11:34:48 +0000

#209 si, probablemente me faltan conocimientos.

» autor: harapo

#237 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 11:20:49 +0000

[Usuario deshabilitado]

» autor: --30529--

#236 Programadores antiguos vs programadores de hoy

cristomc — Wed, 27 May 2020 10:58:58 +0000

#232 No va a reducir el uso de JS. Precisamente WASM lo unico que va a hacer es "suavizar" librerías de JS en las que necesitas mucha carga de trabajo (WEBGL/Datasets y colecciones gigantestas, etc).

Es decir, para el 99,99% de las webs, no va a ser necesario implementar nada con WASM.

Aún asi, a los unicos que veo rajar de JS son precisamente a los que les cuesta usar correctamente la programacion funcional o la POO. Y a la larga, me recuerda a una gran lógica que interiorizé desde que empecé a trabajar en el mercado laboral estándar:

"Los gestores del proyecto no cierran la funcionalidad -> el desarrollador elije su herramienta favorita -> el producto no se ajusta la necesidad"

Y bajo esta frase se esconde el origen de todos los problemas de la programación moderna:

SI elijo JS y lo programo sin Frameworks: Cuando me pidan cambiar la funcionalidad, tendré que tirar trabajo a la basura
Si elijo C y lo programo sin librerias: Cuando se use el producto, mi programa fallará yu tendré que escribir mas código.
Si elijo Ruby/Python/PHP sin libreerias: Mas de lo mismo...

Al final, el problema de la programación moderna es que hemos dejado de hacer software simple, útil y con propósitos específicos, para hacer software capricho de gente que por regla general ni tiene puta idea de informática, ni le interesa fijar el objetivo del producto y quiere resultados ya.

Y asi es como nacen Angular, React, Vue (en JS), Rails (Ruby), Django (Python), etc, etc... Porque no puedes pararte a pensar como antaño en que finalidad tiene cada línea de código y te preocupas en que puedas mejorar y meter mas y mas funcionalidades (aunque muchas ni se vayan a utilizar) con el fin de obtener mas y más beneficios.

Y sino os reto a que hagais una librería/plugin/app para cualquier tarea que realizeis a diario y vereis que bien optimizada, sin frameworks y funcional obtendreis.

» autor: cristomc

#235 Programadores antiguos vs programadores de hoy

PortgasDAce — Wed, 27 May 2020 10:52:08 +0000

#227 claro, efectivamente, y si tenemos en cuenta que hoy en día C está desfasado en cuanto lo claro, (poco) verboso y conciso que puede ser un lenguaje...

» autor: PortgasDAce

#234 Programadores antiguos vs programadores de hoy

gambader — Wed, 27 May 2020 10:50:45 +0000

#13 Cierto

» autor: gambader

#233 Programadores antiguos vs programadores de hoy

Ka0 — Wed, 27 May 2020 10:44:45 +0000

#104 #121 Todos esos códigos se perderán en el tiempo, como disquetes de 5¼ en la nube.

» autor: Ka0

#232 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 10:42:29 +0000

[Usuario deshabilitado]

» autor: --30529--

#231 Programadores antiguos vs programadores de hoy

Ka0 — Wed, 27 May 2020 10:41:33 +0000

#220 El lenguaje de programación perfecto es el que tiene 0 líneas de código

» autor: Ka0

#230 Programadores antiguos vs programadores de hoy

cristomc — Wed, 27 May 2020 10:40:56 +0000

#68 Otro que se piensa que WASM es sustituto para programar en lugar de JS

» autor: cristomc

#229 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 10:39:09 +0000

[Usuario deshabilitado]

» autor: --30529--

#228 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 10:37:22 +0000

[Usuario deshabilitado]

» autor: --30529--

#227 Programadores antiguos vs programadores de hoy

hawgietonight — Wed, 27 May 2020 10:32:19 +0000

#206 Como dices, los modelos actuales se "documentan" de diversas maneras, pero siempre con una visión global. Es decir, tendrás un globo con "enviar email", pero se queda ahí, no se detalla el proceso interno completo... y eso sí hacía falta con ASM dado que es un lenguaje que no se sigue fácilmente. Dependías de diagramas adicionales para visualizar un método complejo. Por eso se hacía ANTES del código. Era una buena práctica aunque no era imprescindible ni mucho menos.

Hoy con lenguajes modernos y los IDEs es muy distinto. La expresividad y estructura de un código del estilo "C" con sus llaves, tabulaciones y expresiones humanas lo hace muy fácil de leer y seguir, y te evitas el engorro del diseño previo a bajo nivel.

» autor: hawgietonight

#226 Programadores antiguos vs programadores de hoy

JCarlesVilaseca — Wed, 27 May 2020 10:31:58 +0000

#220 Pienso que Haskell debería ese lenguaje que comentas. Pero por varias circunstancias lo aleja. El ecosistema que lo envuelve no facilita su uso e integración con otros sistemas, y es una pena.

» autor: JCarlesVilaseca

#225 Programadores antiguos vs programadores de hoy

--478314-- — Wed, 27 May 2020 10:23:40 +0000

#74 Eres todo lo que está mal en el mundo de la programación. Arrogancia, "trolleo" y falta de empatía todo junto. Menos mal que he salido de esto. Y parece que las cosas están cambiando pero quedan muchos como tú.

» autor: --478314--

#224 Programadores antiguos vs programadores de hoy

--478314-- — Wed, 27 May 2020 10:21:38 +0000

#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.

» autor: --478314--

#223 Programadores antiguos vs programadores de hoy

JCarlesVilaseca — Wed, 27 May 2020 10:20:53 +0000

#186 Un millón de gracias.

» autor: JCarlesVilaseca

#222 Programadores antiguos vs programadores de hoy

mat_ov — Wed, 27 May 2020 10:18:44 +0000

#146 En realidad el 486 SX era un 486 DX cuya unidad de coma flotante estaba mal, se le "capaba" y se vendía como un 486 SX sin coprocesador matemático.
El 487 - coprocesador matemático era un 486 "completo" que anulaba al otro y que no funcionaba si no estaba el otro presente.

en.wikipedia.org/wiki/X87#80487

» autor: mat_ov

#221 Programadores antiguos vs programadores de hoy

empanadilla.cosmica — Wed, 27 May 2020 10:13:28 +0000

#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.

» autor: empanadilla.cosmica

#220 Programadores antiguos vs programadores de hoy

Rydra — Wed, 27 May 2020 10:12:45 +0000

#103 Aquí un programador Python venido de 8 añitos de .NET. Parece una tontería, pero el cambio de .NET a python me hizo descubrir un concepto: Estrés cognitivo. Clarísimamente, la verbosidad y ecosistema de .NET comparado con python hace (almenos para mí) que tenga que centrarme en 30.000 cosas que me impiden focalizarme en lo que realmente se le debería dar bien a un programador, que es solucionar problemas. Python, en ese aspecto, me genera menos estrés cognitivo.

No obstante no creo que sea el lenguaje perfecto. Para mí un lenguaje perfecto sería un lenguaje de programación que, aparte de los clásicos constructs de la programación orientada a objetos, tenga la pureza de un lenguaje de programación funcional y, que además, haya montonazos de paquetes para los problemas comunes y sea fácil de integrar. En ese aspecto Elixir promete, pero no tiene la prevalencia del resto de lenguajes.

En definitiva, el lenguaje perfecto será, para mí, aquél que haga que me pueda centrar al máximo en resolver y plasmar un dominio de negocio fácilmente.

» autor: Rydra

#219 Programadores antiguos vs programadores de hoy

DeBoer — Wed, 27 May 2020 09:57:03 +0000

#76 Esto cada vez se parece mas a forocoches.

» autor: DeBoer

#218 Programadores antiguos vs programadores de hoy

JCarlesVilaseca — Wed, 27 May 2020 09:55:38 +0000

#158 Están en ello blog.golang.org/go2-here-we-come

» autor: JCarlesVilaseca

#217 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 09:53:30 +0000

#216 Claro, dicho así tiene más sentido, pero es que en tu comentario original lo que parecías querer decir es que hacer cualquier programa entero en ensamblador es más sencillo que en C++ y en procesadores actuales... lo que sería una burrada se mire por donde se mire

Luego, leyendo otros comentarios tuyos ya vi que te referías a sistemas con Z80. Ahí es obvio que sí, porque, por ejemplo, el sistema de paso de parámetros por pila de C y C++ no es muy eficiente porque la arquitectura del procesador no se adapta bien a ella. Además de que el juego de instrucciones es muy sencillo.

» autor: --8899--

#216 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 09:46:56 +0000

#215 Un office no, pero como concepto en segun qué dispositivos antiguos sí.
Y aun así existen cosas como WinASM con un huevo de macros que lo hacen mediopotable.

» autor: --625430--

#215 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 09:45:41 +0000

#214 Ya, pero seguimos en las mismas: que C++ sea una mierda (y en eso estamos de acuerdo, no te preocupes) no significa para nada que sea más sencillo hacer las cosas en ensamblador. Tareas puntuales sí pueden ser más sencillas, pero ni de coña te curras un libreoffice actual en ensamblador.

Otra cosa es que, como he leído por ahí abajo, te refirieses exclusivamente a sistemas pequeños (microcontroladores, ordenadores de 8 bits...) pero claro... programar eso en C++, según la cantidad de memoria que te den, es absurdo, pues sólo con un par de librerías ya desbordas la memoria.

» autor: --8899--

#214 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 09:43:25 +0000

#212 Pero en un entorno profesional te obliga practicamente a tragar con código ajeno. Por no hablar que he visto código de inicios del 2000 que para compilarlo hoy hay que hacer magia negra. Ni con GCC 4.2 he podido.

» autor: --625430--

#213 Programadores antiguos vs programadores de hoy

chavi — Wed, 27 May 2020 09:42:17 +0000

#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

» autor: chavi

#212 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 09:37:07 +0000

#208 Ya, pero es que C++ no te obliga a utilizar todas esas cosas

» autor: --8899--

#211 Programadores antiguos vs programadores de hoy

traviesvs_maximvs — Wed, 27 May 2020 09:36:27 +0000

#198 Buen aporte

» autor: traviesvs_maximvs

#210 Programadores antiguos vs programadores de hoy

barcelonauta — Wed, 27 May 2020 09:34:52 +0000

#186 "Como veo que sois de la vieja escuela..." Old school forever! (cosecha del 73, en mi caso. Un buen año, sino el mejor)

No conocía ese juego, pero tiene una pintaza retro bien guapa. Directo a mi lista. Mis dieses.

» autor: barcelonauta

#209 Programadores antiguos vs programadores de hoy

PortgasDAce — Wed, 27 May 2020 09:30:11 +0000

#110 O te explicas mal o tus conocimientos son bastante escasos.

Una cosa es eu corra sobre la JVM y otra que corra sobre Java. Java es un lenguage que permite operar sobre la JVM, Kotlin es lo mismo, un lenguaje que permite operar sobre la JVM pero con un enfoque más moderno y con ciertas orientaciones hacia la programación funcional.

Pero podemos decir lo mismo de Scala o Clojure...

» autor: PortgasDAce

#208 Programadores antiguos vs programadores de hoy

--625430-- — Wed, 27 May 2020 09:29:49 +0000

#194 Después de tocar ASM para la GB desde Forth para cosas que si no irian demasiado lentas y sufrir la locuacidad de C++ me quedo con el primero. He dicho C++, no C. Dejad de confundid ambos lenguajes, que no podrían ser más distintos en concepto. C está tirado.

Confundir C y C++ si que es no tener ni puta idea de nada. C bajo Unix es como juntar carne asada con salsa picante o queso de cabra. C++ es un aborto que no debió haber nacido jamás. Go es lo que encarna lo que pensaron los creadores de Unix como el sucesor natural de C, cogiendo la filosofía de plan9 y sus compiladores (y cosas como dial() ) en un lenguaje donde la compilación cruzada está tirada.

» autor: --625430--

#207 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 09:26:22 +0000

#199 Disculpa. Me refería al #76 todo el rato. Es que no sé leer . He ido a por lana y he vuelto esquilado...

» autor: Sr.Norte

#206 Programadores antiguos vs programadores de hoy

PortgasDAce — Wed, 27 May 2020 09:25:04 +0000

#164 Porque hoy en día los modelos son mucho más complejos y cambiantes. Tener las cosas en papel en forma de diagrama en lugar de en forma de código funcional es una perdida brutal de tiempo y esfuerzo, además de una forma fantástica de alejar las fechas de salida y asegurarte sacar un producto desfasado a mercado.

UML es una herramienta magnifica como complemento. ¿Para qué? Pues yo suelo usarlo en equipos para que se complementen commits o pull request especialmente complejas (un UML da una buena visión global), o para presentaciones entre diferentes equipos, etc.

Pero casi siempre como algo puntual y a posteriori, para describir lo que está hecho y no lo que se hará (que casi siempre tendrá cambios y terminará en un UML desfasado o esfuerzos extra que no aportan para actualizarlo).

» autor: PortgasDAce

#205 Programadores antiguos vs programadores de hoy

meneandro — Wed, 27 May 2020 09:21:50 +0000

#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...

» autor: meneandro

#204 Programadores antiguos vs programadores de hoy

aironman — Wed, 27 May 2020 09:20:04 +0000

#71 ni de broma, en mi opinión.

C y c++ es un paseo por el bosque del edén comparado con ensamblador.

» autor: aironman

#203 Programadores antiguos vs programadores de hoy

meneandro — Wed, 27 May 2020 09:18:26 +0000

#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.

» autor: meneandro

#202 Programadores antiguos vs programadores de hoy

paco_camps_2011 — Wed, 27 May 2020 09:15:02 +0000

Hay una competición anual de JS de hacer un programa en 1KB, yo participé un año porque me chifla la optimización y eficiencia.

js1k.com/

» autor: paco_camps_2011

#201 Programadores antiguos vs programadores de hoy

estoyausente — Wed, 27 May 2020 09:08:55 +0000

#196 Sí, entiendo esa visión. Es parte un problema de pasta también. Si tienes que hacer algo y no tienes tiempo suficiente para aprender otra tecnología, pues lo haces con lo que tienes (con lo que sabes).

Pero es un problema complejo. También los habrá que no quieren aprender. Otros que no tendrán la capacidad de comprender lo que hay bajo el framework (Javascript a pelo, por ejemplo, es muy duro) y otros mil motivos que no se me ocurren.

» autor: estoyausente

#200 Programadores antiguos vs programadores de hoy

Shotokax — Wed, 27 May 2020 09:08:54 +0000

#199 en ese comentario digo que hay semáforos implementados en C. ¿Eso es falso?

» autor: Shotokax

#199 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 09:07:58 +0000

#176 El comentario #75 que cito en mi respuesta.

» autor: Sr.Norte

#198 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 09:06:07 +0000

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.

» autor: Sr.Norte

#197 Programadores antiguos vs programadores de hoy

PortgasDAce — Wed, 27 May 2020 09:04:25 +0000

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.

» autor: PortgasDAce

#196 Programadores antiguos vs programadores de hoy

raistlinM — Wed, 27 May 2020 09:01:42 +0000

#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.

» autor: raistlinM

#195 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 09:01:08 +0000

#165 ¡¡Y yo aún digo más!! Programar en binario es más fácil que en código máquina hexadecimal

» autor: --8899--

#194 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 08:59:36 +0000

#76 Decir que ensamblador es más sencillo que C es no haber programado jamás en ensamblador. Ya sólo por la gestión automática de memoria en las llamadas a subrutina, te ahora una burrada de trabajo.

Y te lo dice alguien que ha programado ensamblador de 8086, 68000 y microcontroladores PIC.

» autor: --8899--

#193 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 08:57:24 +0000

#105 Yo di durante un par de años clases de programación, y un día, explicándoles la cola de eventos que hay por debajo de android y por qué, en general, no se tienen que preocupar de la concurrencia, me dio por dejarles caer lo que era un deadlock y una condición de carrera con un par de ejemplos... ¡¡¡menudas caras ponían!!! Y yo, con su edad, ya programaba ensamblador...

» autor: --8899--

#192 Programadores antiguos vs programadores de hoy

--8899-- — Wed, 27 May 2020 08:54:42 +0000

#101 ¿Ese no es un conjunto de artículos que habían salido en El tamiz, recopilados en forma de libro? Porque si es ese... ¡¡Me encanto!!

» autor: --8899--

#191 Programadores antiguos vs programadores de hoy

--636808-- — Wed, 27 May 2020 08:54:41 +0000

#4 tio, que chiste tan friki, estas muy metido en el tema no?

» autor: --636808--

#190 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Wed, 27 May 2020 08:53:21 +0000

#137: Es que ese es el problema: Si antes en un disquete entraba un intérprete y contenido multimedia... ¿Por qué hacen falta 50 mb solo para el intérprete? ¿Qué incluyen, un sistema operativo emulado para correr un intérprete que compile el código que un precompilador obtiene a partir de un metalenguaje? ¿Que muchas cosas iban por DirectX o la API de Windows? Vale. ¿No se supone que DirectX y la WinAPI son para eso?
en.wikipedia.org/wiki/DirectX#Version_history

» autor: mcfgdbbn3

#189 Programadores antiguos vs programadores de hoy

ytuqdizes — Wed, 27 May 2020 08:50:12 +0000

#186 He buscado un gameplay, ¡y me ha encantado! ¡muchas gracias!

» autor: ytuqdizes

#188 Programadores antiguos vs programadores de hoy

redscare — Wed, 27 May 2020 08:48:49 +0000

#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

» autor: redscare

#187 Programadores antiguos vs programadores de hoy

--84408-- — Wed, 27 May 2020 08:46:56 +0000

#109 Tampoco corre en una calculadora casio de 1990. Estamos hablando de máquinas de hace más 25 años en adelante.

» autor: --84408--

#186 Programadores antiguos vs programadores de hoy

impaler — Wed, 27 May 2020 08:46:13 +0000

#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.

» autor: impaler

#185 Programadores antiguos vs programadores de hoy

Mursopolis — Wed, 27 May 2020 08:35:25 +0000

#169 "En mis tiempos programábamos en tarjetas perforadas... Yo me programé una calculadora científica entera usando eso. ¡4k de memoria ocupaba! Y ahora los chavales hablan de Javascreen o Rubí o como le llamen a esas cosas nuevas, que se lo dan todo hecho y compilado, ¿y se creen programadores? ¡A programar en ensamblador los ponía yo a todos!"

» autor: Mursopolis

#184 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 08:33:07 +0000

[Usuario deshabilitado]

» autor: --30529--

#183 Programadores antiguos vs programadores de hoy

--30529-- — Wed, 27 May 2020 08:30:31 +0000

[Usuario deshabilitado]

» autor: --30529--

#182 Programadores antiguos vs programadores de hoy

inovercy — Wed, 27 May 2020 08:28:13 +0000

#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.

» autor: inovercy

#181 Programadores antiguos vs programadores de hoy

TontoElQueMenea — Wed, 27 May 2020 08:25:48 +0000

#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

» autor: TontoElQueMenea

#180 Programadores antiguos vs programadores de hoy

omega7767 — Wed, 27 May 2020 08:24:08 +0000

#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

» autor: omega7767

#179 Programadores antiguos vs programadores de hoy

TontoElQueMenea — Wed, 27 May 2020 08:23:13 +0000

Erronea en todos los sentidos

» autor: TontoElQueMenea

#178 Programadores antiguos vs programadores de hoy

elmike — Wed, 27 May 2020 08:21:51 +0000

#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.

» autor: elmike

#177 Programadores antiguos vs programadores de hoy

MetalAgm — Wed, 27 May 2020 08:20:30 +0000

#162 En C++11 y en adelante tienes la clausula "auto":
auto x = 4;
auto y = 3.37;
auto ptr = &x;

std::set<std::string> st;
st.insert({"geeks", "for", "geeks", "org"});

for(auto it = st.begin(); it != st.end(); ++it)
{
std::cout << *it << std::endl;
}
La verdad es que desde C++11 en adelante con C++ han incluido muchas características de alto nivel que nada tienen que envidiar a Java o C#, así que con C++ moderno tienes desde bajo nivel hasta alto nivel

#160 Qt es un buen framework para Interfaces Graficas en C++; si perdían trimestres de desarrollo porque quizás no controlaban del todo Qt, al principio cuesta adaptarse si, pero luego una vez que esta todo claro programar y compilar en diferentes plataformas no es complicado. Siempre que se haga uso de C++ estándar y de la parte de Qt común... si usas la librería de Qtwindows o qt Active X que son solo para windows, entonces tendrás que adaptar el código a otros sistemas....

» autor: MetalAgm

#176 Programadores antiguos vs programadores de hoy

Shotokax — Wed, 27 May 2020 08:12:41 +0000

#165 ¿el qué es falso?

» autor: Shotokax

#175 Programadores antiguos vs programadores de hoy

del_dan — Wed, 27 May 2020 08:11:44 +0000

Es más costoso programar, que comprar más disco duro.

Vamos yo programé en assembler, y ahora en javascript, con toda esa mierda de frameworks, que me ahorran horas y horas de trabajo. ahora mismo es más importante optimizar otras cosas como llamadas a base de datos, llamadas a la api, que lo que ocupe un programilla.

» autor: del_dan

#174 Programadores antiguos vs programadores de hoy

MDman — Wed, 27 May 2020 08:11:15 +0000

#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"

» autor: MDman

#173 Programadores antiguos vs programadores de hoy

--570830-- — Wed, 27 May 2020 08:10:19 +0000

También las aplicaciones de antes no tenían la lógica de negocio que tienen hoy día. Ni son la mitad de escalables, bueno ni de mantenibles. Hoy día priman otras cosas simplemente y no tanto que sea eficiente, computacionalmente, porque hay mas recursos. Además de que si tuvieras que picar todo desde 0 siempre en vez de usar frameworks, se tardaría más y sería una aplicación mucho más cara y más cara de mantener.

» autor: --570830--

#172 Programadores antiguos vs programadores de hoy

kaoD — Wed, 27 May 2020 08:08:51 +0000

#39 encontré al HNero.

» autor: kaoD

#171 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 08:07:19 +0000

#6 Este de que cueva ha salido? (Y cuanto lleva dentro...)

» autor: Sr.Norte

#170 Programadores antiguos vs programadores de hoy

xyria — Wed, 27 May 2020 08:04:21 +0000

#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.

» autor: xyria

#169 Programadores antiguos vs programadores de hoy

traviesvs_maximvs — Wed, 27 May 2020 08:01:52 +0000

#168 y cuñados palilleros denostando el oficio de los demás solo porque usan otra técnica. Siempre ha pasado y seguirá pasando

» autor: traviesvs_maximvs

#168 Programadores antiguos vs programadores de hoy

Mursopolis — Wed, 27 May 2020 07:58:44 +0000

Ha llegado un punto en el que la informática es suficientemente antigua como disciplina que ya, por fin, hay abuelos cebolleta programadores.

» autor: Mursopolis

#167 Programadores antiguos vs programadores de hoy

Imag0 — Wed, 27 May 2020 07:57:53 +0000

Yo he programado COBOL en un IBM AS400.

» autor: Imag0

#166 Programadores antiguos vs programadores de hoy

RaistlinMajere — Wed, 27 May 2020 07:53:32 +0000

#152
¿a qué te refieres con perfiles solo de producto?

» autor: RaistlinMajere

#165 Programadores antiguos vs programadores de hoy

Sr.Norte — Wed, 27 May 2020 07:52:51 +0000

#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...

» autor: Sr.Norte

#164 Programadores antiguos vs programadores de hoy

hawgietonight — Wed, 27 May 2020 07:48:04 +0000

#108 Es inviable no por grande, sino por la variabilidad de arquitecturas y modelos de procesadores. Cuando programas en ASM se hace conociendo la estructura interna, cuántos registros tienes y puertos tienes, etc. Ahora eso no es habitual y se depende 100% en un compilador y un lenguaje un nivel por encima que te lo gestione todo.

Y la forma de programar era distinta, recuerdo pegarme el 80% del tiempo de desarrollo era sobre papel. Diagramas y diagramas, tablas y bocetos. Luego un 10% pasarlo a código y otro 10% probando y depurando. El jefe siempre nos decía que si teníamos los diagramas bien, el código era un mero trámite. Y tenía razón. Hoy en día ya no se programa así.

» autor: hawgietonight

#163 Programadores antiguos vs programadores de hoy

--516070-- — Wed, 27 May 2020 07:44:25 +0000

#150 Bueno, las herramientas están para solucionar un problema. Luego, si no las tienes, puedes usar otras que hagan que tu código sea un poco peor, menos simple o legible

» autor: --516070--

#162 Programadores antiguos vs programadores de hoy

RaistlinMajere — Wed, 27 May 2020 07:43:43 +0000

#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

» autor: RaistlinMajere

#161 Programadores antiguos vs programadores de hoy

--569461-- — Wed, 27 May 2020 07:43:42 +0000

Positivo por mencionar al gran Jonathan Blow. Ese tío es un genio, y el tiempo le otorgará el lugar que merece.

» autor: --569461--

#160 Programadores antiguos vs programadores de hoy

--516070-- — Wed, 27 May 2020 07:43:23 +0000

#155 Bueno, si con c++ se termina el problema de la gestión de memoria, resuelve su problema sin salir de su zona de confort.

Lo que no haría nunca es usar Qt si no le aporta nada. Estar siempre escribiendo la Q antes de cada primitiva me ponía enfermo. Luego, las empresas que he visto que lo utilizaban para hacer multiplataforma se estaban tirando de los pelos, perdían trimestres de desarrollo sólo adaptándose a la "multiplataforma" de Qt

» autor: --516070--

#159 Programadores antiguos vs programadores de hoy

Varlak — Wed, 27 May 2020 07:41:54 +0000

#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.

» autor: Varlak

#158 Programadores antiguos vs programadores de hoy

--516070-- — Wed, 27 May 2020 07:40:11 +0000

#144 A Go le faltan una serie de funcionalidades que tienen muchos otros lenguajes. Es un caso extraño. Se hace raro no poder añadir genéricos o no tener parámetros por defecto en las funciones.

Obviamente, puedes adaptar tu código para no necesitarlo. Pero eso indica que es una peor herramienta.

» autor: --516070--

#157 Programadores antiguos vs programadores de hoy

redscare — Wed, 27 May 2020 07:38:39 +0000

#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

» autor: redscare

#156 Programadores antiguos vs programadores de hoy

traviesvs_maximvs — Wed, 27 May 2020 07:36:20 +0000

#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.

» autor: traviesvs_maximvs

#155 Programadores antiguos vs programadores de hoy

MetalAgm — Wed, 27 May 2020 07:32:09 +0000

#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...

es.m.wikipedia.org/wiki/C++11
es.m.wikipedia.org/wiki/C++14
es.m.wikipedia.org/wiki/C++17
es.m.wikipedia.org/wiki/Qt_(biblioteca)

» autor: MetalAgm

#154 Programadores antiguos vs programadores de hoy

mperdut — Wed, 27 May 2020 07:31:07 +0000

#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.

» autor: mperdut

#153 Programadores antiguos vs programadores de hoy

Peazo_galgo — Wed, 27 May 2020 07:29:13 +0000

#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í...

» autor: Peazo_galgo

#152 Programadores antiguos vs programadores de hoy

yoshi_fan — Wed, 27 May 2020 07:27:24 +0000

Aqui hace falta diferenciar unas pocas de cosas:

- La programacion ha pasado de un producto de ingenieria de alto nivel, una commodity, a soluciones a dedo a bajo coste. -> Esto implica que el programador medio es alguien que puede sacar algo, pero no razonarlo ni asegurar su calidad. Se prefiere al que se pelea que al que crea buen software. No se espera ni se piensa en el software como producto al que habra que dar soporte.

- Node. O cualquier framework, pero el ecosistema js es el peor. -> Ya se han dicho por arriba las virtudes de los frameworks. Pero seamos inteligentes: los frameworks se crean para solucionar un problema: necesidad de producir software mas rapido y sin pensar mucho. Los frameworks (o los nidos de librerias) tienen sus problemas y, aunque debemos poder abstraernos de ellos, muy pocas librerias son realmente diseñadas pensando en evitar acoplamientos

-Peor calidad del software y evolucion exponencial de mantenimiento vs produccion, con produccion siendo monopolizado por perfiles "seniors" que ya vienen desaprendidos de sus etapas como junior. Esto evita que puedan entrar ideas nuevas. Que los juniors puedan educarse en condiciones una vez salidos de la uni (donde pasan directamente a hacer todo lo contrario a lo enseñado, entrando en un ciclo de desenseñanza

Pero vamos que todo esto viene de la increibe clown fiesta que sin las carnicerias/xonsultorias en todos los paises, que no son mas que otro esquema de sacarse dineritos a base de sobres. Pero en fin, me enrollo. Falta decir quenesto se perpetua por que la cultura de carnica se retroalimenta: he visto como gente de carnica solo contrata a gente de carnics, xk saben que son gente que no les jodera sus planes. Es por lo que perfiles SOLO de producto son a la vez tan deseados y tan odiados por empresas del monton: por que saben que les van a sacar los colores

» autor: yoshi_fan

#151 Programadores antiguos vs programadores de hoy

--142584-- — Wed, 27 May 2020 07:26:59 +0000

[Usuario deshabilitado]

» autor: --142584--

#150 Programadores antiguos vs programadores de hoy

cosmonauta — Wed, 27 May 2020 07:26:25 +0000

#134 No hay genéricos. Pero muchas veces puedes solucionarlo usando interfaces,.o usando reflection,

Supongo que el problema está en como estamos acostumbrados a resolver los problemas.

Personalmente, pocas veces he echado a faltar los genéricos pero veo gente que lo considera fundamental.

» autor: cosmonauta

#149 Programadores antiguos vs programadores de hoy

redscare — Wed, 27 May 2020 07:25:46 +0000

#3 Y el problema es? Los discos duros van baratos y el tiempo es dinero.

» autor: redscare

#148 Programadores antiguos vs programadores de hoy

alephespoco — Wed, 27 May 2020 07:24:37 +0000

#134 ... y entonces cuando usas macros en C para usarlo como genéricos es cuando te encuentras a la madre de todos los problemas de compilación: errores de compilación del código expandido por el preprocesador. No sé, llámame loco, pero me parece una idea terrible. Hay otras maneras menos macarras de hacer esas cosas en C. O directamente usar C++.

» autor: alephespoco

#147 Programadores antiguos vs programadores de hoy

yemeth — Wed, 27 May 2020 07:14:08 +0000

#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

» autor: yemeth

#146 Programadores antiguos vs programadores de hoy

elmike — Wed, 27 May 2020 07:13:41 +0000

#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.

» autor: elmike

#145 Programadores antiguos vs programadores de hoy

Nathaniel.Maris — Wed, 27 May 2020 07:08:26 +0000

#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!

» autor: Nathaniel.Maris

#144 Programadores antiguos vs programadores de hoy

txeke — Wed, 27 May 2020 06:59:17 +0000

#134 no sé si te sigo... ¿a qué limitación te refieres?

» autor: txeke

#143 Programadores antiguos vs programadores de hoy

PatoVC — Wed, 27 May 2020 06:58:22 +0000

#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!

» autor: PatoVC

#142 Programadores antiguos vs programadores de hoy

--606024-- — Wed, 27 May 2020 06:57:38 +0000

#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

» autor: --606024--

#141 Programadores antiguos vs programadores de hoy

--519574-- — Wed, 27 May 2020 06:56:31 +0000

El tiempo del programador es mucho más caro que el hardware que se está usando. Ahí tenéis el problema.

» autor: --519574--

#140 Programadores antiguos vs programadores de hoy

asturvulpes — Wed, 27 May 2020 06:56:06 +0000

#10 tiraba el wolf en mi 286 a 16Mhz perfectamente

» autor: asturvulpes

#139 Programadores antiguos vs programadores de hoy

--519574-- — Wed, 27 May 2020 06:53:50 +0000

#50 para hacer scripts guarros. Se recomienda Python.

» autor: --519574--

#138 Programadores antiguos vs programadores de hoy

osiris — Wed, 27 May 2020 06:52:36 +0000

#71 hasta aquí he llegado.
Demasiado internet por hoy, ya.

» autor: osiris

#137 Programadores antiguos vs programadores de hoy

--606024-- — Wed, 27 May 2020 06:50:26 +0000

#91 Ostras, me has hecho recordar un montón de animaciones de El Rellano y Al Cachondeo que, como bien dices, eran en un fichero EXE y no un fichero SWF.

Debería de existir alguna forma de compilar, aunque fuera corriendo en una pequeña VM, todo ese código JS para que fuera más rápido.

» autor: --606024--

#136 Programadores antiguos vs programadores de hoy

box3d — Wed, 27 May 2020 06:48:21 +0000

#4 Terry Davis.
Descanse en Paz.

Y que los negros que brilan en la oscuridad no le persigan en el cielo.

» autor: box3d

#135 Programadores antiguos vs programadores de hoy

estoyausente — Wed, 27 May 2020 06:47:31 +0000

#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.

» autor: estoyausente

#134 Programadores antiguos vs programadores de hoy

--516070-- — Wed, 27 May 2020 06:44:44 +0000

#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.

» autor: --516070--

#133 Programadores antiguos vs programadores de hoy

Falk — Wed, 27 May 2020 06:44:04 +0000

#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.

» autor: Falk

#132 Programadores antiguos vs programadores de hoy

--38321-- — Wed, 27 May 2020 06:43:13 +0000

Absolutamente errónea.

Los programadores de 1996 eran una panda niños malcriados que tiraban de Java y de máquinas con 1GB de RAM para nada.

En 1991 me curré yo una aplicación que rulaba en un PSION organicer de 128 Kb donde te tenía que caber:
- El programa
- Los datos de los productos (que eran un huevo para esa capacidad)
- Los datos de los pedidos

El procesador creo que era un Zilog Z80 (el del Spectrum)

en.wikipedia.org/wiki/Psion_Organiser

También había que meter los datos de los en 64Kb de RAM (modelo medio del compilador, el large iba muy lento con los 286) ¡bendito modo 386 que quitaba toda esa mierda!

» autor: --38321--

#131 Programadores antiguos vs programadores de hoy

ttestt — Wed, 27 May 2020 06:42:49 +0000

#74 al ignore que vas pues.
no se como has aguantado tanto tiempo aquí con tantos comentarios vomitivos la verdad....

» autor: ttestt

#130 Programadores antiguos vs programadores de hoy

Yosemite — Wed, 27 May 2020 06:41:45 +0000

#8 La mejor definición que he leído

» autor: Yosemite

#129 Programadores antiguos vs programadores de hoy

tremolantepenacho — Wed, 27 May 2020 06:40:52 +0000

#23 Exacto. Yo tenía un 486 dx33 y recuerdo jugar al Wolfenstein pero no al Doom porque no tiraba bien.

» autor: tremolantepenacho

#128 Programadores antiguos vs programadores de hoy

Falk — Wed, 27 May 2020 06:37:34 +0000

Hoy día se premia el desarrollo ágil por encima del rendimiento. Sólo ahorrarte tener que compilar algo para probarlo es ahorrarte mucho tiempo. También es verdad que se utilizan frameworks para todo y al final tienes una motosierra para cortar el pan en muchos casos, lo que pasa que esto también tiene sus ventajas además de los inconvenientes.

Otra cosa que hay que tener en cuenta es la cantidad de imágenes, videos, documentos que se suelen integrar en un proyecto, eso hace que engorde bastante, a menudo pesan más que el código.

» autor: Falk

#127 Programadores antiguos vs programadores de hoy

YoryoBass. — Wed, 27 May 2020 06:32:10 +0000

#125 No puedo aplaudir mas. Soy programador, pero por mi puesto estoy cerca "de los que tienen la pasta". Al equipo se le defiende siempre, pero en ocasiones me toca defender cada mierda, que no se como consigo que traguen. Afortunadamente, y con el tiempo, prácticamente todo mi equipo esta formado por gente con ganas de aprender, independientemente del nivel que tengamos. Eso facilita mucho el tema de que aprendamos de las equivocaciones, que es lo importante.

» autor: YoryoBass.

#126 Programadores antiguos vs programadores de hoy

pakorrito — Wed, 27 May 2020 06:25:17 +0000

Como programador viejuno, lo que mas me sorprende de los lenguajes modernos es como se acepta el concepto de 'gestor de paquetes', sin comprobar nada. Y ademas se usan librerias de terceros para cualquier chorrada (isEven?!, isOdd?!)

La ultima vez que me puse a hacer una aplicación con node.js y electron me daba pánico la cantidad de mensajes de librerías que se estaba descargando. Y alguna de ellas en la descripción te mostraba: 'Esto lleva años sin mantener, no lo uses, puede tener problemas de seguridad'º o mensajes mas preocupantes.

Ya hemos tenido algún susto con esto, todavía nos falta darnos un buen golpe, pero llegará.

» autor: pakorrito

#125 Programadores antiguos vs programadores de hoy

elgranmago — Wed, 27 May 2020 06:22:23 +0000

#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.

» autor: elgranmago

#124 Programadores antiguos vs programadores de hoy

ccguy — Wed, 27 May 2020 06:14:14 +0000

#82 Yo usaba conio.h y en esa época los becarios para mí eran dioses, yo estaba en el instituto haciendo mis chorradas Me importaban dos cojones los UNIX, mi mundo era MS-DOS y mis aplicaciones bien de colorines que tenían.

» autor: ccguy

#123 Programadores antiguos vs programadores de hoy

YoryoBass. — Wed, 27 May 2020 06:12:23 +0000

Particularmente en mis desarrollos y los de mi equipo tratamos de usar las menos librerías de terceros posibles. Concretamente en movilidad, hemos conseguido reducir estas librerías a 2 (inyector de dependencias y promesas), que serán sustituidas por las nuestras en 2021. Seguimos la filosofía viejuna de "crea tus herramientas", que aprendí hace ya lo menos casi 30 años.
Somos un equipo pequeño y generamos mantenemos nuestras propias librerías. Es un proceso lento pero muy satisfactorio. Y por supuesto, nuestra velocidad de desarrollo se ha incrementado (concretamente en un 75% aproximadamente en un año), así como la calidad, documentación y comprensión del software.

(EDIT: y por supuesto todo nativo. Se puede trabajar en nativo sin romper presupuestos)

» autor: YoryoBass.

#122 Programadores antiguos vs programadores de hoy

txeke — Wed, 27 May 2020 06:11:19 +0000

#104 he visto servidores Tomcat en llamas más allá del cinturón de IECISA...

» autor: txeke

#121 Programadores antiguos vs programadores de hoy

Virtualcharly — Wed, 27 May 2020 06:10:28 +0000

#104 Todos esos momentos se perderán en el tiempo, como lágrimas en la lluvia

» autor: Virtualcharly

#120 Programadores antiguos vs programadores de hoy

ccguy — Wed, 27 May 2020 06:10:22 +0000

#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.

» autor: ccguy

#119 Programadores antiguos vs programadores de hoy

llorencs — Wed, 27 May 2020 06:05:19 +0000

#65 Yo sigo leyendo que la documentación de Python es mala. Pero yo sin ser programador me apaño con la documentación de la documentación de la biblioteca estándar. Eso sí, hay bibliotecas que están muy mal documentadas, pero eso ocurre en todos los lenguajes.

» autor: llorencs

#118 Programadores antiguos vs programadores de hoy

sotanez — Wed, 27 May 2020 06:04:28 +0000

#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 www.udacity.com/course/c-plus-plus-nanodegree--nd213

» autor: sotanez

#117 Programadores antiguos vs programadores de hoy

FooDev — Wed, 27 May 2020 06:01:28 +0000

#67 #50 Yo a todo el mundo que me pregunta por un nuevo lenguaje le digo lo mismo:

PYTHON.

» autor: FooDev

#116 Programadores antiguos vs programadores de hoy

sotanez — Wed, 27 May 2020 05:58:57 +0000

#50 Lo más directo es aprender C++ moderno, el estándar 11 o superior, con sus punteros inteligentes y demás facilidades.

» autor: sotanez

#115 Programadores antiguos vs programadores de hoy

FooDev — Wed, 27 May 2020 05:53:48 +0000

Sin ánimo de ofender, porque en cierto modo comparto vuestros perjuicios, algunos aún no entendéis que eficiencia no es hacer correr un programa con menos hierro. La eficiencia que importa, la que nos da de comer a nosotros y al empresario, es hacer correr el mayor número de programas en el menor tiempo posible (sin bugs, entiéndase). Y para eso se necesitan frameworks.

Además, la programación evoluciona: a día de hoy es más importante escribir codigo rápido, robusto y fácil de mantener. Si hace falta más hardware pues se compra. Eso es precisamente lo barato.

» autor: FooDev

#114 Programadores antiguos vs programadores de hoy

sotanez — Wed, 27 May 2020 05:41:07 +0000

#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.

» autor: sotanez

#113 Programadores antiguos vs programadores de hoy

--516070-- — Wed, 27 May 2020 05:40:47 +0000

#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#

» autor: --516070--

#112 Programadores antiguos vs programadores de hoy

fingulod — Wed, 27 May 2020 05:30:33 +0000

#14 el 386 tampoco tenía coprocesador. Los coprocesadores eran externos hasta el 486

» autor: fingulod

#111 Programadores antiguos vs programadores de hoy

fingulod — Wed, 27 May 2020 05:28:58 +0000

#5 El Doom usaba 32 bits, así que por debajo de un 386 no podía funcionar.

» autor: fingulod

#110 Programadores antiguos vs programadores de hoy

harapo — Wed, 27 May 2020 05:27:04 +0000

#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...

» autor: harapo

#109 Programadores antiguos vs programadores de hoy

Herrerii — Wed, 27 May 2020 05:14:00 +0000

#2 Mentira en mi 086 no iba, hasta que no tuve el 486dx4 no pude jugar

» autor: Herrerii

#108 Programadores antiguos vs programadores de hoy

Minos — Wed, 27 May 2020 05:06:59 +0000

#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.

» autor: Minos

#107 Programadores antiguos vs programadores de hoy

ktzar — Wed, 27 May 2020 05:01:15 +0000

JavaScript bien usado es un lenguaje comodísimo de usar, y si usas typescript aún más. Y si usas tree shaking aplicaciones grandes no ocupan más de 4-5 MB. Las aplicaciones que suelo hacer yo son de unas 30.000 líneas y bueno, es cómodo trabajar. Por fin parece que JS ha alcanzado un punto aceptable y estable.

» autor: ktzar

#106 Programadores antiguos vs programadores de hoy

ktzar — Wed, 27 May 2020 04:58:35 +0000

#50 golang. Sin dudarlo

» autor: ktzar

#105 Programadores antiguos vs programadores de hoy

harapo — Wed, 27 May 2020 04:56:41 +0000

#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.

» autor: harapo

#104 Programadores antiguos vs programadores de hoy

Rexor — Wed, 27 May 2020 04:44:56 +0000

#24 me has recordado al replicante de blade runner en su discurso final

» autor: Rexor

#103 Programadores antiguos vs programadores de hoy

--335641-- — Wed, 27 May 2020 04:28:50 +0000

#89 Python es de lo peor

» autor: --335641--

#102 Programadores antiguos vs programadores de hoy

--335641-- — Wed, 27 May 2020 04:27:17 +0000

Os lo resumo en una palabra: Overengineering

» autor: --335641--

#101 Programadores antiguos vs programadores de hoy

bitelchus74 — Wed, 27 May 2020 04:14:32 +0000

#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

» autor: bitelchus74

#100 Programadores antiguos vs programadores de hoy

bitman — Wed, 27 May 2020 03:14:42 +0000

#79 mierda! mis ojos!!!

» autor: bitman

#99 Programadores antiguos vs programadores de hoy

nosemeneame — Wed, 27 May 2020 01:47:10 +0000

#5 en mi 486 iba de lujo .......pero recuerdo amigos q no le iba muy bien ! (386 )

era un olivetti de este estilo :

hipertextual.com/files/2019/03/hipertextual-ordenadores-olivetti-busca

» autor: nosemeneame

#98 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 21:23:24 +0000

#97 tinyapps.org

» autor: --625430--

#97 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Tue, 26 May 2020 21:20:13 +0000

#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.

» autor: mcfgdbbn3

#96 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 21:17:09 +0000

#91 >. y eso, tenía sonido (o sea, iba ahí un reproductor)

No, llamaba a DirectX.

» autor: --625430--

#95 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 20:49:50 +0000

#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.

» autor: --625430--

#94 Programadores antiguos vs programadores de hoy

Mustela — Tue, 26 May 2020 20:36:05 +0000

#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).

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 @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?

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".

» autor: Mustela

#93 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Tue, 26 May 2020 20:11:43 +0000

#59: Con C++ puedes hacer eso, vectores donde la memoria va automáticamente según añades elementos a los vectores.

» autor: mcfgdbbn3

#92 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Tue, 26 May 2020 20:09:22 +0000

#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.

» autor: mcfgdbbn3

#91 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Tue, 26 May 2020 20:01:36 +0000

#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.

» autor: mcfgdbbn3

#90 Programadores antiguos vs programadores de hoy

mcfgdbbn3 — Tue, 26 May 2020 19:54:30 +0000

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.

» autor: mcfgdbbn3

#89 Programadores antiguos vs programadores de hoy

lectorcritico — Tue, 26 May 2020 19:37:35 +0000

#50 Si necesitas que sea de bajo nivel: Rust, esta diseñado para evitar errores.
www.meneame.net/story/hace-lenguaje-programacion-rust-especial
Si 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.

» autor: lectorcritico

#88 Programadores antiguos vs programadores de hoy

--606024-- — Tue, 26 May 2020 19:21:44 +0000

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#

» autor: --606024--

#87 Programadores antiguos vs programadores de hoy

--606024-- — Tue, 26 May 2020 19:15:42 +0000

#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.

» autor: --606024--

#86 Programadores antiguos vs programadores de hoy

barcelonauta — Tue, 26 May 2020 18:38:07 +0000

#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.

» autor: barcelonauta

#85 Programadores antiguos vs programadores de hoy

squanchy — Tue, 26 May 2020 15:34:37 +0000

#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.

» autor: squanchy

#84 Programadores antiguos vs programadores de hoy

casius_clavius — Tue, 26 May 2020 13:33:16 +0000

#72 Gracias por sacarme de la ignorancia. No lo sabía.

» autor: casius_clavius

#83 Programadores antiguos vs programadores de hoy

txeke — Tue, 26 May 2020 13:19:04 +0000

#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í

» autor: txeke

#82 Programadores antiguos vs programadores de hoy

txeke — Tue, 26 May 2020 13:16:03 +0000

#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.

» autor: txeke

#81 Programadores antiguos vs programadores de hoy

llorencs — Tue, 26 May 2020 13:05:58 +0000

#24 ¿Qué pasaba con la conio.h? Por qué no te gustaba?

» autor: llorencs

#80 Programadores antiguos vs programadores de hoy

txeke — Tue, 26 May 2020 12:49:15 +0000

#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".

» autor: txeke

#79 Programadores antiguos vs programadores de hoy

sillycon — Tue, 26 May 2020 12:48:39 +0000

#1 #3 Leeros esto:
tonsky.me/blog/disenchantment/es/

Al que me adhiero totalmente.

» autor: sillycon

#78 Programadores antiguos vs programadores de hoy

Mustela — Tue, 26 May 2020 12:45:45 +0000

#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.

» autor: Mustela

#77 Programadores antiguos vs programadores de hoy

Shotokax — Tue, 26 May 2020 12:29:27 +0000

#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.

» autor: Shotokax

#76 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 12:27:09 +0000

#75 que asm es mucho mas sencillo.

» autor: --625430--

#75 Programadores antiguos vs programadores de hoy

Shotokax — Tue, 26 May 2020 12:26:37 +0000

#71 mutex y semáforos hay en C. ¿A qué te refieres exactamente?

» autor: Shotokax

#74 Programadores antiguos vs programadores de hoy

--30529-- — Tue, 26 May 2020 12:23:56 +0000

[Usuario deshabilitado]

» autor: --30529--

#73 Programadores antiguos vs programadores de hoy

barcelonauta — Tue, 26 May 2020 12:17:04 +0000

#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.

» autor: barcelonauta

#72 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 12:04:37 +0000

#54 #51 Golang está hecho por los creadores de Unix y tiene un GC.

» autor: --625430--

#71 Programadores antiguos vs programadores de hoy

--625430-- — Tue, 26 May 2020 12:02:50 +0000

#62 Al contrario. Para programar en ASM es más facil que C++ con las templates y aprendiendo cosas como mutex y semáforos.

» autor: --625430--

#70 Programadores antiguos vs programadores de hoy

acidulante — Tue, 26 May 2020 11:39:38 +0000

#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.

» autor: acidulante

#69 Programadores antiguos vs programadores de hoy

Mustela — Tue, 26 May 2020 11:04:21 +0000

#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.

» autor: Mustela

#68 Programadores antiguos vs programadores de hoy

--30529-- — Tue, 26 May 2020 10:57:53 +0000

[Usuario deshabilitado]

» autor: --30529--

#67 Programadores antiguos vs programadores de hoy

acidulante — Tue, 26 May 2020 10:49:18 +0000

#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.

» autor: acidulante

#66 Programadores antiguos vs programadores de hoy

torkato — Tue, 26 May 2020 10:46:17 +0000

#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.

» autor: torkato

#65 Programadores antiguos vs programadores de hoy

KaborlllLLLONE — Tue, 26 May 2020 10:10:58 +0000

#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.

» autor: KaborlllLLLONE

#64 Programadores antiguos vs programadores de hoy

--547431-- — Tue, 26 May 2020 10:09:00 +0000

#58 Aghhh y ahora me entero

» autor: --547431--

#63 Programadores antiguos vs programadores de hoy

ytuqdizes — Tue, 26 May 2020 10:07:53 +0000

#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
Edit: ahora leo a #40, es cierto eso del rendimiento

» autor: ytuqdizes

#62 Programadores antiguos vs programadores de hoy

Shotokax — Tue, 26 May 2020 09:39:28 +0000

#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.

github.com/jmechner/Prince-of-Persia-Apple-II

» autor: Shotokax

#61 Programadores antiguos vs programadores de hoy

Shotokax — Tue, 26 May 2020 09:35:26 +0000

#2 al Wolfenstein 3D lo vi correr en un 386.

» autor: Shotokax

#60 Programadores antiguos vs programadores de hoy

Powertrip — Tue, 26 May 2020 09:03:46 +0000

#50 Si no quieres tener que reaprender nada te recomiendo Java, la sintaxis de Java es parecida a C++ pero sin punteros

» autor: Powertrip

#59 Programadores antiguos vs programadores de hoy

RaistlinMajere — Tue, 26 May 2020 09:02:31 +0000

#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)

» autor: RaistlinMajere

#58 Programadores antiguos vs programadores de hoy

kithal — Tue, 26 May 2020 08:34:23 +0000

#25 A mi el quake me tiraba decente cuando subí la velocidad del bus de 33mhz a 40mhz en mi 486dx2

» autor: kithal

#57 Programadores antiguos vs programadores de hoy

SpeakerBR — Tue, 26 May 2020 08:29:12 +0000

#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)

» autor: SpeakerBR

#56 Programadores antiguos vs programadores de hoy

--619630-- — Tue, 26 May 2020 08:20:58 +0000

#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.

» autor: --619630--

#55 Programadores antiguos vs programadores de hoy

--619630-- — Tue, 26 May 2020 08:18:26 +0000

#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

» autor: --619630--

#54 Programadores antiguos vs programadores de hoy

casius_clavius — Tue, 26 May 2020 08:11:30 +0000

#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.

» autor: casius_clavius

#53 Programadores antiguos vs programadores de hoy

cosmonauta — Tue, 26 May 2020 08:06:46 +0000

#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á.

» autor: cosmonauta

#52 Programadores antiguos vs programadores de hoy

txeke — Tue, 26 May 2020 07:58:21 +0000

#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...

» autor: txeke

#51 Programadores antiguos vs programadores de hoy

txeke — Tue, 26 May 2020 07:57:23 +0000

#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).

» autor: txeke

#50 Programadores antiguos vs programadores de hoy

casius_clavius — Tue, 26 May 2020 07:49:24 +0000

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?

» autor: casius_clavius

#49 Programadores antiguos vs programadores de hoy

casius_clavius — Tue, 26 May 2020 07:45:15 +0000

#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ú.

» autor: casius_clavius

#48 Programadores antiguos vs programadores de hoy

--629849-- — Tue, 26 May 2020 07:44:45 +0000

#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

www.youtube.com/watch?v=5f7gW5X24ao

» autor: --629849--

#47 Programadores antiguos vs programadores de hoy

--30529-- — Tue, 26 May 2020 07:44:24 +0000

[Usuario deshabilitado]

» autor: --30529--

#46 Programadores antiguos vs programadores de hoy

casius_clavius — Tue, 26 May 2020 07:40:04 +0000

#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).

» autor: casius_clavius

#45 Programadores antiguos vs programadores de hoy

MarkelNaiz — Tue, 26 May 2020 06:30:36 +0000

#14 Al Wolfenstein 3D jugué con un 8086 a 8 Mhz en CGA.

» autor: MarkelNaiz

#44 Programadores antiguos vs programadores de hoy

--547431-- — Tue, 26 May 2020 03:50:27 +0000

#27 Megas perdón.

» autor: --547431--

#43 Programadores antiguos vs programadores de hoy

dvdkrku — Mon, 25 May 2020 22:22:22 +0000

#18 Discrepo, el hermano buenorro de Java es Kotlin, aunque C# tiene su punto también

» autor: dvdkrku

#42 Programadores antiguos vs programadores de hoy

cosmonauta — Mon, 25 May 2020 22:05:21 +0000

#24 Yo he estado ahí.

Serás feliz en golang.

» autor: cosmonauta

#41 Programadores antiguos vs programadores de hoy

cosmonauta — Mon, 25 May 2020 22:04:13 +0000

#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.

» autor: cosmonauta

#40 Programadores antiguos vs programadores de hoy

barcelonauta — Mon, 25 May 2020 21:52:45 +0000

#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)

» autor: barcelonauta

#39 Programadores antiguos vs programadores de hoy

tomegatherion — Mon, 25 May 2020 21:06:47 +0000

#4 Terry Davis... un individuo curioso cuanto menos.

» autor: tomegatherion

#38 Programadores antiguos vs programadores de hoy

tomegatherion — Mon, 25 May 2020 21:05:46 +0000

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.

» autor: tomegatherion

#37 Programadores antiguos vs programadores de hoy

Mustela — Mon, 25 May 2020 20:51:59 +0000

#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...

» autor: Mustela

#36 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 20:18:34 +0000

#31 Perdon, era ifdb.tafs.org y

www.ifarchive.org/indexes/if-archiveXgamesXzcode.html

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.

» autor: --625430--

#35 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 20:12:36 +0000

#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: 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.

» autor: --625430--

#34 Programadores antiguos vs programadores de hoy

squanchy — Mon, 25 May 2020 19:57:29 +0000

#28 #25 #15 Bueno, lo he encontrado. Pinchad en la foto.

» autor: squanchy

#33 Programadores antiguos vs programadores de hoy

--30529-- — Mon, 25 May 2020 19:04:32 +0000

[Usuario deshabilitado]

» autor: --30529--

#32 Programadores antiguos vs programadores de hoy

txeke — Mon, 25 May 2020 18:56:14 +0000

#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.

» autor: txeke

#31 Programadores antiguos vs programadores de hoy

--84408-- — Mon, 25 May 2020 18:21:59 +0000

#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.

» autor: --84408--

#30 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 18:15:53 +0000

#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.

en.wikipedia.org/wiki/Zork

La maquina Z es un predecesor de Java y maquinas virtuales similares.

» autor: --625430--

#29 Programadores antiguos vs programadores de hoy

--84408-- — Mon, 25 May 2020 18:04:50 +0000

#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.

» autor: --84408--

#28 Programadores antiguos vs programadores de hoy

SpeakerBR — Mon, 25 May 2020 18:01:42 +0000

#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.

» autor: SpeakerBR

#27 Programadores antiguos vs programadores de hoy

squanchy — Mon, 25 May 2020 17:56:53 +0000

#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.

» autor: squanchy

#26 Programadores antiguos vs programadores de hoy

--640028-- — Mon, 25 May 2020 17:48:20 +0000

#24 ¿Qué frameworks usas? ¿O no usas nada? No sé si entiendo tu última frase.

La pregunta es en serio. Programo por afición.

» autor: --640028--

#25 Programadores antiguos vs programadores de hoy

--547431-- — Mon, 25 May 2020 17:42:17 +0000

#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.

» autor: --547431--

#24 Programadores antiguos vs programadores de hoy

txeke — Mon, 25 May 2020 17:41:21 +0000

#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.

» autor: txeke

#23 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 17:27:54 +0000

#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 ~~Z80~~ primo hermano del Z80, y lo puedo jugar perfectamente en cualquier portatil o maquina desde 1982. Como te quedas?

» autor: --625430--

#22 Programadores antiguos vs programadores de hoy

--84408-- — Mon, 25 May 2020 17:26:12 +0000

#21 www.reddit.com/r/itrunsdoom/

» autor: --84408--

#21 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 17:19:57 +0000

#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.

» autor: --625430--

#20 Programadores antiguos vs programadores de hoy

--84408-- — Mon, 25 May 2020 16:40:27 +0000

#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:

youtu.be/_Nxn2IBkgSQ

» autor: --84408--

#19 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 16:24:01 +0000

#17 www.jwz.org/doc/cadt.html

» autor: --625430--

#18 Programadores antiguos vs programadores de hoy

--30529-- — Mon, 25 May 2020 16:19:10 +0000

[Usuario deshabilitado]

» autor: --30529--

#17 Programadores antiguos vs programadores de hoy

Supercinexin — Mon, 25 May 2020 16:16:42 +0000

#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.

» autor: Supercinexin

#16 Programadores antiguos vs programadores de hoy

Sandevil — Mon, 25 May 2020 16:14:45 +0000

#6 Bien, hablemos de Java...

» autor: Sandevil

#15 Programadores antiguos vs programadores de hoy

Mustela — Mon, 25 May 2020 16:11:18 +0000

#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).

» autor: Mustela

#14 Programadores antiguos vs programadores de hoy

squanchy — Mon, 25 May 2020 16:05:15 +0000

#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.

» autor: squanchy

#13 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 16:04:47 +0000

#12 Creo que va sobre Lisp.

» autor: --625430--

#12 Programadores antiguos vs programadores de hoy

Mustela — Mon, 25 May 2020 16:03:10 +0000

#9 Abuse (que también es de disparos pero a alienígenas) funciona sobre TCL/TK

» autor: Mustela

#11 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 16:02:38 +0000

collapseos.org/

Recomiendo tambien este libro:

1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/20

» autor: --625430--

#10 Programadores antiguos vs programadores de hoy

Mustela — Mon, 25 May 2020 16:00:38 +0000

#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.

» autor: Mustela

#9 Programadores antiguos vs programadores de hoy

--625430-- — Mon, 25 May 2020 16:00:04 +0000

#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.

» autor: --625430--

#8 Programadores antiguos vs programadores de hoy

--30529-- — Mon, 25 May 2020 15:53:59 +0000

[Usuario deshabilitado]

» autor: --30529--

#7 Programadores antiguos vs programadores de hoy

Supercinexin — Mon, 25 May 2020 15:48:40 +0000

#6 Completamente de acuerdo. Hijos de puta.

» autor: Supercinexin

#6 Programadores antiguos vs programadores de hoy

--30529-- — Mon, 25 May 2020 15:47:08 +0000

[Usuario deshabilitado]

» autor: --30529--

#5 Programadores antiguos vs programadores de hoy

squanchy — Mon, 25 May 2020 15:33:13 +0000

#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.

» autor: squanchy

#4 Programadores antiguos vs programadores de hoy

Supercinexin — Mon, 25 May 2020 15:26:40 +0000

#0 Ésta también está guapa:

» autor: Supercinexin

#3 Programadores antiguos vs programadores de hoy

squanchy — Mon, 25 May 2020 15:26:02 +0000

#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.

» autor: squanchy

#2 Programadores antiguos vs programadores de hoy

--84408-- — Mon, 25 May 2020 14:48:41 +0000

O Doom, que corría en cualquier máquina.

» autor: --84408--

#1 Programadores antiguos vs programadores de hoy

Mustela — Mon, 25 May 2020 12:45:40 +0000

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.).

» autor: Mustela