TECNOLOGíA, INTERNET, JUEGOS
311 meneos
2537 clics
¿Puede la retroinformática darnos mejores programadores en el futuro? Este estudio cree que sí

¿Puede la retroinformática darnos mejores programadores en el futuro? Este estudio cree que sí

Universidad de Alicante publica un estudio en el que considera que enseñar lenguajes de programación de bajo nivel y, por tanto, programar en sistemas "retro" permite que los desarrolladores generen mejor código cuando programan con lenguajes de alto nivel. A través de la creación de juegos retro para Amstrad CPC (procesador de 4 MHz y sus 64 KB de RAM) con sus limitaciones técnicas, el juego es reto técnico: cada byte de memoria y cada ciclo de reloj cuenta, cada instrucción superflua supone una losa en el resultado final del proyecto

| etiquetas: programación , desarrollo , software , estudios
138 173 6 K 229
138 173 6 K 229
Comentarios destacados:                                  
#1 Doy fe. Veo programadores que han salido de la carrera pasados los 2000 que apenas saben intuir la complejidad de un algoritmo, ni diferencian un paso por valor de uno por referencia, ni saben picar un SQL básico.

Pero te hablan de ORMs, Big data o lenguajes funcionales aunqie muchas veces ni huelan de que va la película.
Doy fe. Veo programadores que han salido de la carrera pasados los 2000 que apenas saben intuir la complejidad de un algoritmo, ni diferencian un paso por valor de uno por referencia, ni saben picar un SQL básico.

Pero te hablan de ORMs, Big data o lenguajes funcionales aunqie muchas veces ni huelan de que va la película.
#1 ¿Y qué opinas de las vistas o los procedimientos? Porque la última vez que me dió por sugerir algo así me miraron raro como diciendo "Las BB.DD. no se tocan, caca ¿Eres del pleistoceno?"
#7 Pues el otro le explicaba a un compañero que "hubo un tiempo en que el modelo se hacía en bases de datos y los servicios más importantes en stored procedures" ...y nadie sabía lo que era Rabbit.

Y nose lo creía...para el, eso es ser un chapuzas.
#10 #7 Pues ahí si le veo una laguna a la formación, tiré por la rama de bases de datos... y algo que nunca me explicaron bien fue el tema de los índices... si, sé que es, para que valen... pero nunca conseguí una explicación clara de los pasos a seguir para dar con el índice adecuado, optimización, vaya...
#23 Pues mira un consejo de oro: Si tienes una tabla muy extensa y accedes con muchas consultas recurrentes tipo 'where CAMPO_1 y CAMPO_2' asegúrate de tener un índice de ambos campos, con el mismo orden, siempre y cuando la cardinalidad sea alta.

La diferencia entre tenerlo, o no, es enorme en cuanto a rendimiento.
#26 #23 Consejo platinum para bases de datos relacionales: Si haces un indice multicolumna no necesitaras hacer otro indice para cualquiera de las columnas independientemente. Usease, si tienes indice de (col1,col2) no necesitas hacer otro indice de (col1) porque el rendimiento es el mismo.
Crea un indice, si y solo si:
- Las queries buscan entre un 5 y un 10% del total de los records, si es mas la busqueda secuencial puede ser mejor (de hecho muchas bases de datos pasan del indice…   » ver todo el comentario
#67 Un par de matices:

"Si haces un indice multicolumna no necesitaras hacer otro indice para cualquiera de las columnas independientemente"

Esto así tal cual lo dices, es falso, lo explico más adelante:

"si tienes indice de (col1,col2) no necesitas hacer otro indice de (col1) porque el rendimiento es el mismo"

Eso es correcto para col1, pero no si quieres buscar por col2 de forma aislada.

Mientras se mantenga el orden de los índices, estos están autocontenidos:

ej:…   » ver todo el comentario
#26 Eso lo di en ASIR. En ASIR, en bases de datos. Todo lo que sea de N:M, tabla extra.
#23 Programate un arbol B+ que guarde los indices de las entradas de otro fichero...
Estuvimos un trimestre solo con eso.

Te queda clarito, clarito...
#23 Siempre puedes ejecutarlo con un cliente que te muestre en plan de ejecución de la sql para ver que partes son mas costosas y asi saber donde debes optimizar. (El famoso botoncito de la ambulancia del TOAD si no recuerdo mal, por ejemplo)
#23 Áltamente recomendado: use-the-index-luke.com/es . Es gratuíto, pero puedes comprarlo si quieres. Yo lo compré para mis developers.
#7 Pues a ese cantamañanas le dices que en una transacción, de las cosas más caras en tiempo y CPU es la preparación de la ejecución y que si todo el código posible está en una package dentro de la Bd, desde la primera ejecución quedará en caché y se optimizará la ejecución para el resto de veces que se llame a ese código. Que si no lo entiende y no lo hace, dentro de un tiempo, cuando el acceso a BD se degrade, tendrán que llamar a un consultor externo en tuning de BD ( à 400/500€ jornada) que después de echar un vistazo propondrá meter todo ese código llamado 1000 veces dentro de la BD.
#71 Y de paso te ata para toda la vida a esa base de datos (normalmente una que empieza por O y acaba por E) y que, haciendo honor a su nombre leído al revés, en posteriores actualizaciones te van a subir sin pudor el coste de las licencias hasta donde a ellos les apetezca.

A veces es mejor pagar un día 500 eur la hora, a cambio de no vender tu alma a nadie y potencialmente ahorrarte decenas de miles de euros en el futuro cuando puedas cambiar de producto sin temor de a ver quién es el guapo que migra todos esos procedimientos almacenados.
Sin mala uva...

#96 otia... que tu comentario me ha hecho saltar el proceso por out-of-context... pera que lo arreglo :

:calzador:

ouf...

Y puedes decir el nombre Oracle. Oracle... que no pasa nada por decirlo, ni que lo hagas tres veces seguidas, de verdad
.

Ahora en serio. Aqui el proveedor del motor de BD es irrelevante, ya sea packages, porcedures, functions, units... o como se quiera llamar. Lo que queria resaltar es lo siguiente :

Hay que hacer ver al tontolaba de turno que…   » ver todo el comentario
#7 Sin vistas ni procedures, expones la BD a una posible inyección de SQL si el código del cliente no está bien filtrado.

Toda la información expuesta al público debe ser obtenida a través de vistas y procedimientos con usuarios limitados a la ejecución de los mismos.

Nunca y repito nunca se debe ejecutar un select o un insert sobre la BD obteniendo los datos a consultar a través del usuario.

Para eso están las vistas y los procedimientos.
#7 pues por eso hablan de ORMs, porque no saben lo que hay debajo...
#7 Mi empresa ha pasado por varias aplicaciones, pero todas con la misma base de datos, hecha por gente que no sabe que es un diagrama entidad - relación y mucho menos una normalización. Así nos va, que rara es la tabla que no tiene PKs compuestas. Luego se quejan de que las consultas tardan mucho por los joins.
#7 Cambia de curro, no te dejaran avanzar.
#1 #7 alabado sea el señor, pensaba que me estaba quedando solo. El otro día le sugerí a un programador hacer una join de sql para un temilla, y me dice "join? Eso que es?"
#1 Ahora lo que se lleva es el lenguaje Copy&paste.
#1 salí bastante después de los 2000 y todo eso lo si en la carrera y lo tengo bastante dominado... No sé, habrás tenido mala suerte.
#12 Obviamente no todo el mundo es tan tocho. Siempre hay gente buena. Pero un poquito de ensamblador y C te ayudan a entender muchos conceptos en lenguajes que están ocultos en lenguajes de alto nivel.
#30 no sé... Nosotros somos C y C++. Gestión de memoria, etc. En cuanto a ensamblador tocamos varios, desde 8086 a mips r2000.

Mi hermano está ahora empezando y dan algo menos pero siguen con bajo nivel también en algunas asignaturas.

Supongo que dependerá de la uni. Yo veo necesario darlo, desde luego.
#1 Pues no sé de que "carreras" hablas...
en la UPM, el plan 96 se iniciaba en la programación con Haskell y Ada95, vale que Ada95 era como una evolución de C, pero con haskell, o pensabas... o pensabas... y luego tenías compiladores... que o valías... o valías...
#18 ¿Ada una evolución de C? Si se parecen como un huevo a una castaña... Si aún me dijeses de Pascal, que la sintaxis se parece...
#97 Ten en cuenta las diferentes versiones de Ada, Ada si estaba más influido por Pascal, pero Ada95 tomó inspiración de C/C++

Te hablo de memoria... era el año 1999, que en 18 años no he olvidado programar... pero no recuerdo nada de Ada... en mi primer curro de veradad (tráfico aéreo en indra) si lo usé... pero por un año nada más...

si recuerdo que había muchas librerías que por debajo eran C/C++
#1 Eres notario? O cura?
#19 No. Cosmonauta.
#1 lo siento, pero vengo a llorar un poco.
La pasada semana propuse en mi empresa un algoritmo que reducia x60 el tiempo de un proceso crítico.
Se decidió dejarlo correr porque el nuevo algoritmo está programado en C y claro, los chavales no van a poder mantenerlo.
Ya me voy. :foreveralone:
#29 Prueba con Go. Es C, pero en moderno. Yo estoy disfrutando como un loco.
#32 Gracias, pero lo que debería probar es a cambiar de curro. xD
#32 Yo estuve viendo Go (un poco), tiene muy buena pinta. Aunque no entiendo muy bien por qué no tiene herencia (en el sentido tradicional).
#32 Entonces te recomiendo disfrutar con Rust. Es como C, pero seguro. Y sin GC.
#46 ¿sin Guardia Civil? :shit:

garbage collector
#94 Garbage Collector, que también es una profesión xD
#46 Un ejemplo github.com/rust-lang/rust/blob/master/src/liballoc/allocator.rs
rust stdlib es una colección de unsafe blocks básicamente.
Cuenta los unsafe y hablamos de GC cuando quieras :-)
¿seguro que es seguro?
#29 Coño, y no lo puedes traducir al lenguage del proyecto?Si la eficiencia es pq cambias de un lenguage compilado a uno interpretado, o con maquina virtual, es pq el nuevo algoritmo en realidad no es una mejora.
#54 la eficiencia viene por las dos partes y C es ya uno de los lenguajes del proyecto.
#86 AHORA te entiendo.
#29 Pues probablemente hicieron bien.

Habría que ver lo crítico que era ese proceso y cómo afectaba en realidad a todo el tinglado que ese aspecto en concreto fuera 60 veces más rápido, pero en muchos casos es muchísimo más importante que el código sea mantenible que no tener algo súper eficiente hoy, pero que va a ser lento igualmente mañana y no va a haber quién le meta mano "porque fue una hackeada que hizo Fulano y nadie sabe cómo va". Por no hablar de que si metes un lenguaje…   » ver todo el comentario
#99 Te lo cuento de primera mano: 10 minutos para subir 11000 facturas en formato XML a una base de datos nosql.

Eso es una mierda aquí y en Lima. Encima bloqueando por momentos toda la base de datos con transacciones eteeeeeernaaaaas.
Implementar el parser bien, acceder a la base de datos en nativo en lugar de con bindings y usar correctamente las transacciones. Total 8 funciones en un fichero de 200 líneas.

No pretende puedo pasar el código pero te aseguro que si tienes que mantener el mamotreto actual te vas de varetas.
#1 Mimimimitodo antes era mejormimimi :professor:
#1 Soy de la época que los hombres de verdad programaban sus propios drivers (lástima que yo.apenas supiera enchufar el ordenador) :roll:
#1 Gente buena y gente mala hay en todas las épocas, al igual que gente buena con dias malos y gente mala con dias brillantes.

Yo acabé una carrera que no es informática bastante tiempo después del 2000 pero llevo programando de forma autodidacta como frikazo de mierda desde principios de los 80, el articulo en cuestion que habla de que la falta de recursos explota el ingenio y la optimización puede tener lógica, de ahí a decir que antes la gente programaba mejor... gran parte de mis garbanzos…   » ver todo el comentario
#50 La ingeniería del software no tiene tanto que ver con resolver el problema, como con hacerlo de forma que se pueda trabajar en equipo, que se optimicen los recursos del equipo de trabajo, y que el día de mañana el software se pueda seguir manteniendo independientemente de quién lleve el tema. Vamos, que se trata más de planificar y documentar que de programar. Por eso no le gusta a nadie, aunque es necesaria :-)
#1 hombre la noticia no habla más de lenguaje ensamblador, donde más que un algoritmo hay sangre y sudor, yo hice un proyecto fin de carrera en un PIC y fue el infierno (realmente los problemas fueron más de índole hardware
#1 comoor? Yo acabé la carrera en 2005 y obviamente conozco todos esos detalles de bajo nivel. De hecho programamos en assembler 8 bits y luego en x86. Mi proyecto final fue un driver/wrapper para Linux que emulaba iscsi.
#1 La programación es una actividad complicada, requiere dedicación y está muy mal valorada. A partir de aquí hablamos de lo que queráis, el resto son pamplinas.
#1 lo que ya huele un poco es la cantinela de "los mauores si que somos buenos, no como los jovenzuelos de ahora".
#1 Ojo, pollavieja a la vista.
#132 Ojo, invent a la vista. Eso se da en todas las carreras de antes y de ahora. Es más, eso se da con mucha insistencia en los módulos de grado superior (al menos el que yo hice, DAI).
#1 ¿Y qué tiene de malo la programación funcional? Primero, que es tan antigua como la programación imperativa, véase el Cálculo Lamba y LISP. Segundo, que bien usada permite escribir código mucho más claro y potencialmente eficiente.
Ya claro, porque el problema es de cómo programa el desarrollador... No que tengas que hacer uso de varías librerías mastodónticas de terceros o que tengas que refactorizar decenas de líneas de código para añadir un simple efectito animado de mierda que nada aporta a la UX y funcionalidad, pero que queda 'muy chulo' para las presentaciones con los inversores.

El 80% del código basura va destinado a evitar que el usuario haga cosas que no debe hacer o a efectos que no aportan nada,…   » ver todo el comentario
#2 toda programación que sea wysiwyg,añade gran cantidad de código que no es necesario,solo hace falta abrir una web por ejemplo con un bloc de notas y ver la diferencia entre el código necesario y l gran cantidad que mete un IDE de programación de este tipo
#2 Esos también son problemas. Pero hay aspectos de prácticas de programación que se entienden mucho mejor cuando tienes una idea de cómo funciona el software por debajo.

Con tanta capa de abstracción, a veces olvidamos que, por ejemplo, cuando queremos aplicar una operación a todos los elementos de un array, hacerlo con un bucle que lo recorra obliga al código a recorrerlo explícitamente, mientras que si lo hacemos con algo tipo map() estamos dando la opción al compilador para que paralelice el código y funcione la cosa órdenes de magnitud más rápido.
Que tiempos! Eso era programar y no lo de ahora que parece que hay cpus infinitas y memoria infinita.
#3 el mundo de los dispositivos móviles (Y relojes y resto de gadget) sigue teniendo limitaciones en potencia, memoria y disco.
#15 Los dispositivos móviles son infinitamente más potentes que el primer PC en el que programe algo, y ya no digamos que en el primer ordenador que programe algo.
#40 los móviles hoy, seguro. Hace unos años no tanto. Ahora si quieres hilar fino tienes que programar relojes, tvs... :-P

Aún así los móviles agradecerían que se aligerasen las apps, a día de hoy veo «calculadoras» que pesan 100mb y tiran de la hostia...
#40 Ponte a programar para Arduino, volverás a los "maravillosos" tiempos en que las memorias eran de 4 KB, y el código a veces es tan grande que no cabe en memoria y tienes que comprarte una placa más gorda :-)
#15 hasta que dejen de tenerlas ...
Yo programaba con unos y ceros. Y a veces me sobraba el uno.
Yo empecé así:

LDX #0 ;Registro de índice a 0 (inmediato)
LDA #4 ;Carga el acumulador con valor inmediato 0x4
STA $4400,X ; Guarda el valor del acumulador en la posición de memoria absoluta 0x4400 (+ índice)
INX ;Incrementa el contador X

Etc, etc...

Nota:
Procesador 6502
www.6502.org/tutorials/6502opcodes.html
#6 yo empecé con el ensamblador del 8086.
#6 skilldrick.github.io/easy6502/ SImulador online del 6502.
#4 Puto pijo. Nosotros no teníamos unos, solo ceros.
#4 Pues yo si no tenía 0 usaba la 'O'.
#49 pero entonces se interpretaba como verdadero. A lo mejor es por eso que no llegabas a hacer funcionar nada :-P
#4 El uno que te sobraba te acarreaba problemas.
#84 De hecho algunos de estos problemas me desbordaban
Cuando lo evidente es noticia, algo no se está haciendo bien.
Un programador que nunca haya intentado programar en ensamblador, jamás será un programador completo.
#9 Nada como construir y programar tu propia Máquina de Turing.
Ahora en serio. Sí, programar en ensamblador te hará mejor programador, pero tampoco es ni garantía ni necesario para ser un buen programador. El programador completo no existe.
#16 Para mí, no hay nada como optimizar el código para hacer una aplicación mejor. Programar en ensamblador mejor programador, pero te dará la visión de cómo pensar un algoritmo para que corra más rápido.
#25 Ninguna duda en ello. Pero también es cierto que hay areas en las que será más importante saber ensamblador que en otras. Para muchas aplicaciones Android o webs, por decir un ejemplo, quizá te será más útil conocer patrones de diseño o conocer a fondo un framework o una librería que saber optimizar algoritmos. Aunque todo ayuda, claro.
#25 Depende... el for de C no tiene nada que ver con el for de python. El compilador tiene mucho que decir. Si te piensas que todos los for son como la instruccion que cuando el registro llega a cero, salta a una zona de memoria... vas listo.
#58 Pues depende. Si haces un for explícito en Python, funciona igual que el de C. El compilador (intérprete más bien) hará lo que le dices: desde 1 hasta 10, hacer esta operación sobre el elemento i.

Ahora bien, si lo que quieres hacer en realidad es aplicar una misma operación a todos los elementos de un array, puedes hacer directamente un map(), indicando el array y la operación que quieres hacer, y así el intérprete es libre de, si le parece, enviar cada una de las 10 operaciones a una CPU…   » ver todo el comentario
#25 Sólo que la velocidad no lo es todo en la vida. Si empiezas, por ejemplo, a reescribir partes de tu código en ensamblador para que vaya más rápido, pues sí, irá más rápido. Ahora bien, si en 6 meses hay que hacer una modificación al código y tú ya no estás, el que le toque probablemente no entienda un pimiento y no sepa por dónde meterle mano. Incluso te puede pasar a ti mismo, es muy típico coger código propio no muy bien documentado y no saber qué coño hiciste. Y todo para optimizar una…   » ver todo el comentario
#9 discrepo. Y que conste que yo lo he hecho.
#9 Depende... pq muchos programadores tambien fallan en modelizar. Yo primero creo un modelo que funciona, cuando lo acabo, empiezo a verle mejoras. Pq primero me obsesiona verlo funcionar.

Hay varias habilidades, cada uno es fuerte en la suya. Los lenguages de alto nivel te permiten crear modelos muchisimo mas fácil.

Lo que antes consumia monton de tiempo, la usabilidad, cada vez esta mas automatizada. Las partes del background, tambien.

Si se adoptaron fue por algo. Aunque es cierto que no…   » ver todo el comentario
O él o yo... uno de los dos se ha hecho la picha un lío con lo de "alto nivel" y "bajo nivel"
La unica asignatura donde saque un 10 en la carrera fue precisamente en las practicas de ensamblador, no se si tendria algo que ver que la profersora era preciosa... ay!!!, que cosas estas de la motivacion!
#13 ¿una profesora de ensamblador preciosa?, que afortunado.
#22 Depende de dónde vaya el listón
#36 A partir del tobillo ya se ve piel :-D
#13 que la profesora fuera preciosa a mi me hubiera causado el efecto contrario
#13 ¿dónde estudiaste?
#13 Tu comentario sin foto no vale nada
Me dedico a la optimizacion de codi numerico, y de vez en cuando cogemos graduados. La cara que se les queda a los que salen de la carrera con sus practicas en C# y hablamos de alineamientos de memoria, de directorios de tags, de protocolos de cache... Es un poema.
#14 A mí también se me quedaría cara rara si me dicen de tocar c# :-P
No todo en la vida es frontend/backend. Cualquiera que haya programado microcontroladores sin MMU (y se siguen usando a día de hoy) sigue pegándose con esto a diario...
Cuidado con lo que pedís. Cuando empecé la carrera salieron los listos reclamando que querían aprender a programar juegos, los profesores respondieron ok y el primer trabajo que entregamos fue un buscaminas en Pascal. xD xD xD
#21 Yo iba también de ese palo, y con el primer juego que hice me di cuenta de que, cuando acabé de escribir mi juego, lo odiaba profundamente por las horas que había dedicado en programarlo y depurar fallos.

Yo los juegos prefiero jugarlos, que los programen otros :-)
Pff... yo hice mis cositas en ensamblador en la noche de los tiempos , y si , vale que con programas minusculos conseguias hacer cosas, y te enterabas de lo que costaba un byte. Pero no volveria a esos tiempos a no ser que hubiera un apocalipsis zombie y me quedase a solas con un z-80...
No se si te hara mejor programador, pero si te da un saludable respeto a los recursos.
#27 no volveria a esos tiempos a no ser que hubiera un apocalipsis zombie

entonces tus aptitudes para la programación no son muchas.
#80 No me puedo comparar a los que disfrutaban perforando tarjetas, ciertamente.
#27 Justamente tener un saludable respeto por los recursos ya te convierte en mejor programador.
Lo mejor es dominar ensambladores y compiladores.
que tiempos los de turbopascual
Conocer la base de la programación ayuda a entender lenguajes más complejos
#38 No sé qué decirte, porque cuanto más complejo es un lenguaje generalmente más abstracto es, y más lejos queda el hardware.

De hecho los lenguajes procedurales normales, tipo C, Java o Pascal no se van muy lejos del ensamblador en el sentido de que, en el fondo, siguen siendo instrucciones que se ejecutan una detrás de otra. Pero cógete un lenguaje funcional, y ahí no hay secuencia alguna, el modelo es totalmente diferente y la traducción código->ensamblador no es trivial. Teniendo en…   » ver todo el comentario
Solo diré un comando GOSUB.

Una lagrimita por los viejos tiempos y mis primeras becerradas.

Como adoro mi profesión. Una cerveza por todos los del gremio!
#41 Cuando con 9 años lo descubrí tras tener ya hartado al GOTO se me cayó una lagrimilla. xD
Hace miles de años que ya no programo, pero todavía recuerdo lo que tenías que optimizar el código máquina del Spectrum para poder usar una zona de memoria que se encontraba, creo, entre la ROM y la memoria de vídeo y así realizar rutinas de carga específicas para los juegos, tenías incluso que eliminar las cabeceras del fichero de pantalla y del juego para no tener que usar espacio adicional.
Si a mi me ponen ahora a programar en lenguaje de bajo nivel, me voy a un almacén a cargar cajas xD
Claro, porque no se puede retroprogramar en Java.
Llevo años diciendo a compañeros de curro y otros que dominar el ensamblador sirve muy poco para hacer cosas en ensamblador pero es imprescindible para ser un buen profesional y programar bien ( o, mejor dicho, desarrollar bien: que incluye depurar ).

Podría extenderme mucho pero, de primeras, paso.
El Java es para diseñadores...
el C para medio machos...
y el Ensamblador es para hombres....

Por cierto, yo programo en microcódigo... xD
#56 jajajajaja...
La cosa no es que nosotros tengamos que ser mejores programadores, el secreto del éxito es que los programadores que contestan y dan las respuestas buenas en StackOverflow sean los que de verdad saben. Con eso llega.
Retroprogramar es util para aprender a gestionar eficientemente recursos y optimizar ciclos de reloj. Pero la optimizacion es solo una parte del trabajo y, desde mi punto de vista, no es la mas importante.

Pongamos por ejemplo un proceso que refresca una cache cada pocos minutos, me importa muy poco si el proceso tarda 2 o 4 segundos, y seguro que se puede optimizar y arañar algo de tiempo y dejarlo en menos de 1 segundo, pero para que?

Para mi es mas importante que el codigo sea legible, que…   » ver todo el comentario
#64 No eres el unico. Coincido contigo. Explico algo mas de mi opinion en #61
#73 El artículo científico que Retromaniac reseña no habla de optimización. Habla de estructuración mental del conocimiento en los estudiantes desde el punto de vista psicólógico. Habla también del problema de la conceptualización errónea por falta de conocimiento. El punto importante es el aprendizaje de unas bases sólidas que permitan entender y dominar el conocimiento de la programación. La optimización no es relevante en lo que comentan.
#75 Creo que la retroprogramacion no es necesaria para ello, que se puede conseguir lo mismo con otras tecnicas. Pero bueno, programar juegos para el Spectrum, el Amstrad CPC o el Commodore 64 siempre es entretenido y puede mantener la atencion del estudiante para que aprenda mas motivado, asi que no me opongo en absoluto a que se utilice como metodo para enseñar esas aptitudes basicas.
Lo que queria expresar en mi mensaje es que el benficio de "aprender a optimizar recursos" que otros comentaban, no es un beneficio tan grande y que a veces centrarse en eso cuando no es necesario es contraproducente.
#88 En el artículo también explican porqué la retroprogramación. Usar una máquina más sencilla permite un aprendizaje en menos tiempo y centrarse en conceptos importantes. No es tan relevante el sistema para el que se programa, sino los conceptos que se manejan. Por eso usan máquinas retro: por simplicidad y concentración en el concepto.

La optimización, personalmente me parece un ejercicio muy interesante para desarrollar habilidades propias de un ingeniero. La labor de un ingeniero es…   » ver todo el comentario
Soy el único que no está de acuerdo con el artículo?.

La informática avanza y cambia, y también la programación. No tiene sentido volver a la programación antigua por muy bien que se hiciera porque, sencillamente, no hace falta.

Luego otra cosa es lo que estoy viendo de moda y tendencias al programar, ya hay tanto postureo en la programación y tantos nuevos lenguajes que lo van a petar, que me extraña que no se haga una pasarela cibeles con ellos. No se si me entendeis.
#64 pero el que aprende debería de aprender la base,para saber que en realidad todo lo que haces añadiendo funciones es un montón de líneas de código,que si es necesario está bien, pero si sabes optimizarlo pues mejor todavia
#68 en un lenguaje moderno puedes aprender la base y luego ir añadiendo cosas. Me parece suficiente volver a C, no hace falta nada mas antiguo.
#64 Se puede no estar de acuerdo con el artículo o con lo que quieras, pero quizá estaría bien que argumentaras algo sobre el contenido del artículo. Me refiero al artículo científico. El artículo de Retromaniac es una reseña del auténtico artículo científico, al que enlazan al final. En el se muestra un estudio de 5 años en el que se explican los motivos psicológicos y los cambios en las capacidades de los estudiantes según el tipo de nivel al que programan.

Puedes seguir en desacuerdo tras leerlo, pero estar en desacuerdo no aporta nada en sí mismo. Las razones lógicas quizá sí.
#74 Hombre, claro, lo más normal del mundo.... responder al desacuerdo de un artículo científico escribiendo otro de igual calidad y además en un foro de opinion xD

Espero que no seas de esos de recursos humanos que piden informáticos recién licenciados con 10 o más años de experiencia laboral demostrable en el sector. xD
#64 A mi juicio, no es un problema del lenguaje como tal.

Los equipos son más potentes y se permiten auténticas burradas. Muy poca gente usa herencia, o la usa bien y en Java es esencial.

Al final la gente acaba duplicando, porque funciona igual, el rendimiento no se penaliza y acabas antes.

Trabajar con aplicaciones móviles, supone un dolor para mucha gente, precisamente por eso.
Conocimientos (de la mayoría) de los "programadores" de hoy: www.gitbook.com/book/tra38/essential-copying-and-pasting-from-stack-ov
mov ah,09h ;
mov dx,hola ;
int 21h ; Ejecuta: Imprime hola
int 20h ; Fin
Doy fe que si. Para que no se me oxide el lóbulo de la programación, ando metido en varios proyectos retro consoleros. Se aprende un monton.
Estos articulos me descojonan de risa:

-El 90% de las ofertas de empleo requieren gente que se ponga a programar rapido y baratito porque el cliente lo quiere rapido y paga poco

Estamos en españa, se prima lo rapido y fuera, no hacerlo bien, es mas, si lo haces bien y te sales del presupuesto como mucho te llevaras una galleta. Vale mas que funcione la chapuza, lo metemos debajo de la alfombra y el problema sera de otro. Es triste, pero es asi.
#81 Quizá has leído un artículo distinto. Este artículo va de sentar conocimientos sólidos en estudiantes para que puedan ser mejores ingenieros futuros. Que yo sepa, en ningún sitio afirman que la gente deba pasarse a programar en ensamblador y dejar el alto nivel.
#82 Pues eso, en españa, sirve para nada. Es a lo que me refiero.
Yo también creo que es importante el aprender el bajo nivel, no se si llegar al emsamblador, pero si al menos a C.

No es por la optimización del código. A fin de cuentas, en muy pocos caso necesitas escribir un código que se ejecute a la velocidad del rayo, porque además tampoco sabes si es conveniente esa optimización.

Sin embargo, creo que saber cómo funciona un programa a bajo nivel es más importante para poder diseñar buenos programas. Más importante que la velocidad es que el programa…   » ver todo el comentario
Lo que es importante no es hacerlo bien o mal, lo importante es hacerlo lo "suficientemente bien".

Hay frikis en empresas que se tiran horas y horas mejorando el código, los algoritmos, para crear programas "perfectos" a costa de dilapidar horas de programación y no creando un "VALOR" para el cliente y reduciendo por amor al arte el beneficio de su empresa. En definitiva, son malos profesionales.

Los programas de ordenador pueden no acabarse nunca, siempre hay…   » ver todo el comentario
#93 Para qué hacer tests, total, cuando pete en producción ya se quejarán los usuarios.

Luego, un programa chapucero cuesta muchísimo de mantener. Sabes cuando pides un cambio mínimo y lo que puede llevar unas horas lleva días y al final ni funciona del todo?

Si en tu empresa hay engendros informáticos cosas que cada vez que se tocan deja de funcionar todo, tu aplicación está llena de chapuzas.
La mejor manera de conseguir que los programadores metan chapuzadas es que todo tenga que estar para ayer.

Las chapuzas tienen un nombre más guay que puedes buscar por Internet: "Technical debt". De nada.
#93 He leido todo tus argumentos, y me suena muchísimo a lo que le he escuchado en varias ocasiones a los comerciales y jefes de proyectos ineptos que no entienden como llevar un proyecto software. Esas personas que venden humo, te llevan a ti el marrón (perdón, el "VALOR") y después se desentienden porque al cliente le presupuestó algo que no era acorde con la realidad, pero el marrón (perdón, el "VALOR"), sigues comiéndotelo tu aunque hayas avisado por activa y por pasiva…   » ver todo el comentario
«12

menéame