313 meneos
2586 clics
¿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
|
comentarios cerrados
Pero te hablan de ORMs, Big data o lenguajes funcionales aunqie muchas veces ni huelan de que va la película.
Pero te hablan de ORMs, Big data o lenguajes funcionales aunqie muchas veces ni huelan de que va la película.
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, aspectos que cambian muy alegremente de una versión a otra. El 20% restante es de tareas de la funcionalidad como tal del programa, y normalmente son las que se revisan para que rindan, dejando la otra morralla.
Y el 99% de las estadísticas suelen ser inventadas. Pero es lo que hay.
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
Y nose lo creía...para el, eso es ser un chapuzas.
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.
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...
La diferencia entre tenerlo, o no, es enorme en cuanto a rendimiento.
No se si te hara mejor programador, pero si te da un saludable respeto a los recursos.
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.
que tiempos los de turbopascual
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.
Una lagrimita por los viejos tiempos y mis primeras becerradas.
Como adoro mi profesión. Una cerveza por todos los del gremio!
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...
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 se pagan a base de coger programas viejos picados con el orto y mejorar su rendimiento.
La ingeniería de software, al menos desde mi punto de vista, una vez dominados los conceptos básicos se trata más de entender el problema y razonar la solución óptima con el minimo consumo de tiempo de proceso bajo unas condiciones de entrega (yo te apaño las cosas como buenamente pueda para el tiempo que me das para ello, no, la solucion no siempre es la más óptima, es la mejor obtenible para la urgencia del desarrollo, en un mundo ideal la óptima y la asumible serían la misma, pero en ingenieria de verdad hay restricciones de costes) y cuando aunas todos estos factores, todos, por buenos que creamos que somos, cometemos errores y hacemos el idiota, la diferencia entre un buen y un mal desarrolladore es que el bueno es consciente de estos peligros avisa, pide ayuda, solicita plazos razonables, diseña un plan de pruebas acorde a los puntos débiles, documenta mejoras no llevadas a cabo pero realizables... etc.
Además de lo tremendamente injusto que es comparar a un tipo con 20 años de experiencia con uno de 10, pues claro que habrá diferencias entre ambos, a veces mucha o a veces poca, pero se da. Y no seamos hipócritas, el peso de la experiencia bastante más fuerte que los conocimientos teóricos que tengas...
Estuvimos un trimestre solo con eso.
Te queda clarito, clarito...
Podría extenderme mucho pero, de primeras, paso.
el C para medio machos...
y el Ensamblador es para hombres....
Por cierto, yo programo en microcódigo...
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 saber cosas de la gestión de memoria, provoca delitos.
Yo diria que si no sabes diseñar una pequeña cpu, no eres un programador completo. Si no sabes como gestiona el SO tu codigo, no eres un programador completo.
Una herramienta que no se puede usar es una herramienta inútil. Si no sabes ponerle la vida facil a tus usuarios, no eres un programador completo.
Si no sabes algunas tecnicas ninjas famosas sobre grafos y problemas famosos... idem.
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 este bien estructurado, que no le sobre ni le falte nada, que tenga buenos tests unitarios que tambien sean limpios y faciles de seguir, que no este sobreingenierizado sino que haga justo lo que tiene que hacer. Esto es lo que a mi me demuestra que un desarrollador tiene buena habilidad. El optimizarlo medio segundo a costa de que sea complicado y dificil de mantener no tiene ningun sentido. En la actualidad, en muchas ocasiones la optimizacion de recursos y tiempo no son necesarias.
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.
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 automaticamente).
- La tabla no se actualiza mucho, si se actualiza la tabla tambien se actualiza el indice y eso puede tener un coste muy alto. Si esto pasa las particiones son tus amigos.
- Si te hace una busqueda secuencial y necesitas que vaya mas rapido en algunas bd como oracle y postgres desde la 9.6 (igual en alguna mas) tienen queries en paralelo, usan los cores del servidor para hacer varias queries simultaneas, con eso vuela pero dependes de la maquina que tengas pero mola un web.
- Ultima y mas importante, los indices son para columnas tipo integer o biginteger. Si hay un indice con una columna string o varchar muy mal.
mov dx,hola ;
int 21h ; Ejecuta: Imprime hola
int 20h ; Fin
Puedes seguir en desacuerdo tras leerlo, pero estar en desacuerdo no aporta nada en sí mismo. Las razones lógicas quizá sí.
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.
entonces tus aptitudes para la programación no son muchas.
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.
La optimización, personalmente me parece un ejercicio muy interesante para desarrollar habilidades propias de un ingeniero. La labor de un ingeniero es analizar los recursos y restricciones de que dispone y dar la mejor solución en ese contexto. A fin de cuentas, eso es optimizar. Como ejercicio, creo que es muy útil, aunque no sea de lo que va este artículo.
Eso sí, ningún ejercicio por sí solo es una panacea. Como es lógico, todo tiene pros y contras. Tampoco hay que volverse loco en una dirección ni en otra, claro está.
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 sea mantenible. Para que sea mantenible, quien escribe el programa debe de saber que es lo que le está haciendo a la máquina cuando le ordena que ejecute determinadas instrucciones.
Me ha pasado un par de veces, cuando algún amigo me ha pedido que le eche una mano con sus clases de programación. No se enteraban de nada del curso, por lo abstracto que era. Al explicarles lo que era la memoria, y que hacían al declarar un vector, se iluminaron como Buda.
garbage collector
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.
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 diferente en el proyecto estás aumentando un montón la complejidad. Si el día de mañana cambia la versión del compilador, el dialecto del lenguaje o lo que sea, puede petar por mil sitios diferentes que nadie se espera.
Vamos, que el rendimiento es un factor, de entre muchos. Y la mayoría de veces no es ni de lejos el más importante.