Publicado hace 4 años por jjvelasco a retromaniacmagazine.blogspot.ie

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

m

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

J

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

daphoene

#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: col1, col2, col3 incluye:

col1
col1,col2
col1,col2,col3

Pero no col2,col3, por ejemplo, ni col2 aislado, ni col3.

"los indices son para columnas tipo integer o biginteger. Si hay un indice con una columna string o varchar muy mal"

Entonces de buscar por nombre o referencia nos vamos olvidando, ¿ no ? Una cosa es que un índice sobre un entero sea mil veces más rápida por motivos obvios, y otra que no se puedan o deban indexar campos varchar. Lo que sí es interesante es limitar el tamaño de ese índice. Por ejemplo, puedes tener un campo nombre de 255 caracteres, pero limitar el índice a 15, de modo que el índice descartará infinidad de resultados con la búsqueda y si tuviera que discriminar de forma secuencial lo haría sobre muchísimos menos resultados.

D
editado

#26 Eso lo di en ASIR. En ASIR, en bases de datos. Todo lo que sea de N:M, tabla extra.

D

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

D
editado

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

barni
editado

#23 Áltamente recomendado: use-the-index-luke.com . Es gratuíto, pero puedes comprarlo si quieres. Yo lo compré para mis developers.

dballester
editado

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

t

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

dballester
editado

Sin mala uva...

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



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 dice "Las BB.DD. no se tocan, caca ¿Eres del pleistoceno?" que como se ponga tonto no solo las va a tener que tocar, sino que las tocara tarde y a un precio muy alto, por la simple razon de no saber (ni querer saber) como funciona el motor de BD con el que esta trabajando.

albandy

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

x

#7 pues por eso hablan de ORMs, porque no saben lo que hay debajo...

Mister_Lala

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

dballester

#7 Cambia de curro, no te dejaran avanzar.

KimDeal

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

m

#8 también conocido como SODD

t
editado
estoyausente

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

estoyausente

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

m
editado

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

t

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

m

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

areska
editado

#1 Eres notario? O cura?

cosmonauta

#19 No. Cosmonauta.

cosmonauta

#29 Prueba con Go. Es C, pero en moderno. Yo estoy disfrutando como un loco.

x

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

D
editado

#32 Entonces te recomiendo disfrutar con Rust. Es como C, pero seguro. Y sin GC.

D

#46 ¿sin Guardia Civil?

garbage collector

D
editado

#94 Garbage Collector, que también es una profesión

freelancer

#46 Un ejemplo github.com
rust stdlib es una colección de unsafe blocks básicamente.
Cuenta los unsafe y hablamos de GC cuando quieras
¿seguro que es seguro?

D

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

ur_quan_master

#54 la eficiencia viene por las dos partes y C es ya uno de los lenguajes del proyecto.

D

#86 AHORA te entiendo.

t

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

ur_quan_master
editado

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

Corvillo

#1 Soy de la época que los hombres de verdad programaban sus propios drivers (lástima que yo.apenas supiera enchufar el ordenador)

t

#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

sonixx

#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

D

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

gonas

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

sauron34_1

#1 lo que ya huele un poco es la cantinela de "los mauores si que somos buenos, no como los jovenzuelos de ahora".

l

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

D

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

albandy

#6 yo empecé con el ensamblador del 8086.

D

#6 skilldrick.github.io SImulador online del 6502.

ElPerroDeLosCinco

#4 Puto pijo. Nosotros no teníamos unos, solo ceros.

Robus

#4 Pues yo si no tenía 0 usaba la 'O'.

r

#49 pero entonces se interpretaba como verdadero. A lo mejor es por eso que no llegabas a hacer funcionar nada

ronko

#4 El uno que te sobraba te acarreaba problemas.

D

#84 De hecho algunos de estos problemas me desbordaban

erbeni

#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

t

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

estoyausente

#3 el mundo de los dispositivos móviles (Y relojes y resto de gadget) sigue teniendo limitaciones en potencia, memoria y disco.

Lekuar

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

estoyausente

#40 los móviles hoy, seguro. Hace unos años no tanto. Ahora si quieres hilar fino tienes que programar relojes, tvs...

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

t

#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

D

#15 hasta que dejen de tenerlas ...

r

#14 A mí también se me quedaría cara rara si me dicen de tocar c#

rakinmez

Cuando lo evidente es noticia, algo no se está haciendo bien.

D

Un programador que nunca haya intentado programar en ensamblador, jamás será un programador completo.

D

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

cream

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

D

#28 sasto.

D

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

t

#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 diferente, y ser tremendamente más rápido que la versión C.

Si el programador no sabe muy bien cómo funcionan las tripas de la máquina, a lo mejor piensa que las dos formas de hacerlo son iguales (semántica y funcionalmente lo son), pero el que alguna vez ha tocado las cañerías probablemente tenga en cuenta este tipo de matices.

t

#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 rutina que, muy probablemente, daba igual que fuera un 20% más o menos rápida.

El rendimiento de un código es un factor, pero ni de lejos el más importante. Es mucho más importante la mantenibilidad, y eso a veces implica escribir en lenguajes no tan eficientes pero más legibles, y dedicar menos tiempo a optimizar y más a documentar.

m

#9 discrepo. Y que conste que yo lo he hecho.

D

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

LoboCobarde

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.

D

#27 no volveria a esos tiempos a no ser que hubiera un apocalipsis zombie

entonces tus aptitudes para la programación no son muchas.

LoboCobarde

#80 No me puedo comparar a los que disfrutaban perforando tarjetas, ciertamente.

t

#27 Justamente tener un saludable respeto por los recursos ya te convierte en mejor programador.

lestat

El Java es para diseñadores...
el C para medio machos...
y el Ensamblador es para hombres....

Por cierto, yo programo en microcódigo...

D

#56 jajajajaja...

D

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.

erbeni

#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

sauron34_1

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

a

#64 No eres el unico. Coincido contigo. Explico algo mas de mi opinion en #61

l

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

a

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

l

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

l

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

D

#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

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.

D1OX

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

lainDev

Conocer la base de la programación ayuda a entender lenguajes más complejos

t

#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 cuenta que los lenguajes modernos tipo Python, Ruby y compañía cada vez meten más cosas funcionales, no creo que saber ensamblador te ayude precisamente a entenderlos. Te ayudará a escribir buen código, pero no vas a aprender Ruby más rápido por saber ensamblador.

apetor

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.

alfema_fb

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.

Veelicus

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!

l

#13 ¿una profesora de ensamblador preciosa?, que afortunado.

D

#22 Depende de dónde vaya el listón

Corvillo

#36 A partir del tobillo ya se ve piel

D

#13 que la profesora fuera preciosa a mi me hubiera causado el efecto contrario

r

#13 ¿dónde estudiaste?

p

#13 Tu comentario sin foto no vale nada

formatc2puntos

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!

D

#41 Cuando con 9 años lo descubrí tras tener ya hartado al GOTO se me cayó una lagrimilla.

n

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.

t

#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

Kr0n0

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

D

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 algo que mejorar, que añadir, etc. El objetivo de las empresas es hacer dinero. Si queréis frikear hacedlo en Github en vuestro tiempo libre, pero si queréis que se os pague por vuestro trabajo y se os valore, sed eficientes. Entregad proyectos suficientemente buenos en tiempo y listo, que cumplan los requisitos.

No todo es técnica, conocimientos o desempeño. En el mercado lo importante es el "VALOR" que se le aporta al cliente y un programa chapucero con "gotos" puede aportar más valor que una obra de ingeniería con tests y documentación. Pensad en ello. De nada.