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.
Yo programaba con unos y ceros. Y a veces me sobraba el uno.
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.
#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.
#1 Ahora lo que se lleva es el lenguaje Copy&paste.
#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.
Que tiempos! Eso era programar y no lo de ahora que parece que hay cpus infinitas y memoria infinita.
#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...
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.
#32 Gracias, pero lo que debería probar es a cambiar de curro.
#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.
Cuando lo evidente es noticia, algo no se está haciendo bien.
#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.
#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?"
Un programador que nunca haya intentado programar en ensamblador, jamás será un programador completo.
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
#1 Mimimimitodo antes era mejormimimi
#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.
#22 Depende de dónde vaya el listón
#3 el mundo de los dispositivos móviles (Y relojes y resto de gadget) sigue teniendo limitaciones en potencia, memoria y disco.
#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.
#13 ¿una profesora de ensamblador preciosa?, que afortunado.
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.
#9 discrepo. Y que conste que yo lo he hecho.
#4 Puto pijo. Nosotros no teníamos unos, solo ceros.
Conocer la base de la programación ayuda a entender lenguajes más complejos
El Java es para diseñadores...
el C para medio machos...
y el Ensamblador es para hombres....
Por cierto, yo programo en microcódigo...
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.
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.
#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.
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!
#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.
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!
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.
#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...
#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?"
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.
#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í.
#94 Garbage Collector, que también es una profesión
#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...
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...
#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...
#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...
#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.
#29 Prueba con Go. Es C, pero en moderno. Yo estoy disfrutando como un loco.
#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.
#4 El uno que te sobraba te acarreaba problemas.
#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.
#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.
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.
#8 también conocido como SODD
#19 No. Cosmonauta.
#1 Soy de la época que los hombres de verdad programaban sus propios drivers (lástima que yo.apenas supiera enchufar el ordenador)
Si a mi me ponen ahora a programar en lenguaje de bajo nivel, me voy a un almacén a cargar cajas
#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.
#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
#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.
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.
#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á.
#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.
#148 El tema es que para hacer funcionar Rust donde C funciona hay que olvidarse de la guía de buenas prácticas o modificar el compilador. El manejo de excepciones de C me parece más "de este mundo", a través de las excepciones aislas el código inseguro. Para mí Rust es una especie de C+++ Me explico. Hay escenarios donde tienes que bajar un escalón y moverte a C++, o dos y picar en C. De todas maneras es un buen lenguaje, sólo que no nos olvidemos que no es la panacea.
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.
#49 pero entonces se interpretaba como verdadero. A lo mejor es por eso que no llegabas a hacer funcionar nada
#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#
#46 ¿sin Guardia Civil?
garbage collector
Ya ya dejen de discutir y contrasten sus "competencias" con esto:
http://sijinjoseph.com/programmer-competency-matrix/
#84 De hecho algunos de estos problemas me desbordaban
#6 https://skilldrick.github.io/easy6502/ SImulador online del 6502.
#36 A partir del tobillo ya se ve piel
#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
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.
#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.
#54 la eficiencia viene por las dos partes y C es ya uno de los lenguajes del proyecto.
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.
#23 Áltamente recomendado: http://use-the-index-luke.com/es . Es gratuíto, pero puedes comprarlo si quieres. Yo lo compré para mis developers.
#86 AHORA te entiendo.
#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
#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.
#117 Lo primero es exactamente lo que queria decir pero con mas ejemplos, mis 10.
Si tienes que hacer un indice en una columna tipo string o varchar el problema no es el indice, el problema es el modelo de datos. El coste y mantenimiento de ese indice es enorme (hablamos de tablas grandes). Se aplica el modelo Kimball, campos string o similares a una tabla de dimension y el id a la fact table. Ahorras espacio y tiene mejor rendimiento, win-win
#158 estoy de acuerdo. Cada caso es cada caso y hay que analizarlo individualmente.
En la medida de mi capacidad, la experiencia y los golpes recibidos me han enseñado a ser minimalista.
#4 Pues yo si no tenía 0 usaba la 'O'.
#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 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.
#56 jajajajaja...
#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.
mov ah,09h ;
mov dx,hola ;
int 21h ; Ejecuta: Imprime hola
int 20h ; Fin
#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.
#7 Cambia de curro, no te dejaran avanzar.
#32 Entonces te recomiendo disfrutar con Rust. Es como C, pero seguro. Y sin GC.
#1 lo que ya huele un poco es la cantinela de "los mauores si que somos buenos, no como los jovenzuelos de ahora".
#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.
#131 Es que a los mayores también nos mosquea un poquito que venga un zagal y nos llame dinosaurios.
Por suerte, por ahora somos nosotros los que contratamos.
#125 Amén.
#105 Ese supuesto procesamiento en paralelo podría ser más perjudicial que otra cosa porque lo ganado en paralelismo puedes perderlo con fallos de caché.
#1 Eres notario? O cura?
#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.