Portada
mis comunidades
otras secciones
#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.
Pero te hablan de ORMs, Big data o lenguajes funcionales aunqie muchas veces ni huelan de que va la película.
#2:
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, 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.
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.
#26:
#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.
La diferencia entre tenerlo, o no, es enorme en cuanto a rendimiento.
#50:
#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 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...
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...
#4:
Yo programaba con unos y ceros. Y a veces me sobraba el uno.
#3:
Que tiempos! Eso era programar y no lo de ahora que parece que hay cpus infinitas y memoria infinita.
#6:
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
http://www.6502.org/tutorials/6502opcodes.html
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
http://www.6502.org/tutorials/6502opcodes.html
Comentarios
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 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.
#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.
#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: http://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 :
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.
#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.
#8 también conocido como SODD
#8 https://emilschutte.com/stackoverflow-autocomplete/
#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.
#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.
#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?
garbage collector
#94 Garbage Collector, que también es una profesión
#46 Un ejemplo https://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 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.
#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
#1 Soy de la época que los hombres de verdad programaban sus propios drivers (lástima que yo.apenas supiera enchufar el ordenador)
#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 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...
#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.
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
http://www.6502.org/tutorials/6502opcodes.html
#6 yo empecé con el ensamblador del 8086.
#6 https://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
#4 El uno que te sobraba te acarreaba problemas.
#84 De hecho algunos de estos problemas me desbordaban
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, 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.
#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...
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 ...
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.
#c-14" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2825770/order/14">#14 A mí también se me quedaría cara rara si me dicen de tocar c#
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.
#28 sasto.
#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 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.
#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.
#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 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.
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.
El Java es para diseñadores...
el C para medio machos...
y el Ensamblador es para hombres....
Por cierto, yo programo en microcódigo...
#56 jajajajaja...
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 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 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á.
#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
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.
#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.
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 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.
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.
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.
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
#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
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.
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.
#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
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...
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.
#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áticoscosas 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 que es inviable hacerlo medianamente bien.
Luego te obligas a ti mismo a hacerlo deprisa corriendo para llegar a objetivos. Y cuando el cliente comienza a pedir cambios, a ver como le justificas que son complejos porque el proyecto era un despropósito en gestión y presupuesto. Y ya si pides realizar pruebas te dicen "pero eso tenías que hacerlo mientras programabas".
En mi caso, soy de esos "frikis" que me paso un buen rato optimizando y revisando código, porque realmente es lo que le dará "VALOR" al proyecto. Que funcione, sea rápido y fácil de mantener y evolucionar. Y eso lleva trabajo y horas y me quita a mis compañeros y a mi mucho trabajo y que vivamos todos más cómodos, no solo los comerciales y los de "arriba" que se lo llevan calentito. Pero claro, en el país del pelotazo eso no se entiende.
Si a mi me ponen ahora a programar en lenguaje de bajo nivel, me voy a un almacén a cargar cajas
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 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.
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.
Conocimientos (de la mayoría) de los "programadores" de hoy: https://www.gitbook.com/book/tra38/essential-copying-and-pasting-from-stack-overflow/details
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.
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 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.
mov ah,09h ;
mov dx,hola ;
int 21h ; Ejecuta: Imprime hola
int 20h ; Fin
Lo mejor es dominar ensambladores y compiladores.
que tiempos los de turbopascual
Claro, porque no se puede retroprogramar en Java.
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 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.