Los simtomas principales de un mal programador y como superarlos. Muy buen articulo para conocer las principales debilidades que tenemos algunos programadores en la forma de abordar los problemas..
Executing idempotent functions multiple times (eg: calling the save() function multiple times "just to be sure") ... eso no tienes que superarlo, tienes que dejar el oficio.
#5#7 Menudo coñazo el ensamblador. Para hacer cualquier tontería te pasas dos semanas.
El ensamblador está para aprender como funcionan las cosas y para arreglar detallitos que no haga bien el compilador ( en sistemas empotrados, pq en un PC ni eso).
Quien no entiende la lógica en un tiempo prudencial, no creo que la entienda por más que lo machaques.
La programación es como la química. Podés saber que este gas se combina con aquél otro para formar una molécula de tal otra cosa y ya con eso decís que sabés química, pero en realidad podés no saber porqué el gas aquel se combina con este otro. En programación podés saber que si un parámetro se pasa por referencia, la variable del invocador se verá modificada al modificar el parámetro, pero si no sabés que hay un apuntador detrás de ello ¿sabés programación?
¿Qué es la Pila? ¿Qué son los registros del procesador? ¿Qué es el estándar IEEE 754? ¿Qué es el Heap? ¿Qué es una página de memoria? ¿Y un segmento? ¿Porqué conviene alinear los datos en memoria a múltiplos del tamaño del dato? ¿Qué es un arbol binario? ¿y un Montículo? ¿Y un arbol de decisión? ¿Sabía que el Mouse mide las distancias en unidades llamadas "Mickeys"? (Esta última es totalmente irrelevante )
Si el cometario #3 es para mi.. Se muy bien todo eso... He programado tanto en lenguajes de alto nivel (java, Vb, ...) mediano nivel(c++) bajo nivel (assembler) y comprendo muy bien como funciona todo ... Este articulo es para conocer algunas debilidades que tienen muchos programadores y que tambien uno puede tener (porque existen varios paradigmas de programacion, por ejemplo, y a veces es dificil cambiarde un paradigma de programacion a otro, por ejemplo de oop a funcional, si me entiendes).. Pero si quieres que te lo explique entonces me avisas a ver si te lo ayudo a comprender mejor... ah por cierto mi especialidad es en "embedded systems" asi que conozco mucho de como funciona todo en un procesador....
#4 emm... no, no necesito que me expliques nada... yo ya sé todo eso. Me refería a que no creo que un programador que conozca todo superficialmente sea un "verdadero" programador.
Es mucho más fácil programar sabiendo exactamente qué es lo que hace el procesador. Un programador de alto nivel ve una instrucción como "IF (BanderasEstado AND YaCurrado) 0 THEN" de Basic y no sabe que para el procesador eso es:
TEST DB[BanderasEstado], YaCurrado
JZ I01
¿Es necesario saberlo? No, para nada. Pero ayuda mucho comprender lo que sucede "entre bambalinas", como dicen. En este caso la instrucción de assambler es más clara que la de Basic, porque es más directa sobre que lo que se hace es testear una o mas banderas. ¿Me explico ahora?
Es decir... ¿cómo puede un programador trabajar con variables si no sabe lo que es la Pila o el Heap? Si no tenés idea sobre eso obviamente que no podrás entender bien que es un apuntador y porqué es necesario. Menos aún se pueden comprender las clases sin saber lo que es la Pila y el Heap. Las variables en la Pila son destruídas automáticamente, las en el Heap no. Algunos lenguajes pueden hacer aparentar que no hay diferencia entre objetos alojados en la pila y objetos alojados en el Heap y destruir automáticamente, pero si no es el caso, los datos se pierden en lugar de destruirse.
Si yo enseñase programación, los tendría sufriendo primero con assambler. Luego los haría sufrir con ANSI C, Luego con C++ y, finalmente, con Java. Una tortura continua #6, a perdon... me tenté y seguí escribiendo
Comentarios
Executing idempotent functions multiple times (eg: calling the save() function multiple times "just to be sure") ... eso no tienes que superarlo, tienes que dejar el oficio.
Por dios, eso hace llorar al niño esús.
#5 #7 Menudo coñazo el ensamblador. Para hacer cualquier tontería te pasas dos semanas.
El ensamblador está para aprender como funcionan las cosas y para arreglar detallitos que no haga bien el compilador ( en sistemas empotrados, pq en un PC ni eso).
Quien no entiende la lógica en un tiempo prudencial, no creo que la entienda por más que lo machaques.
Como dijo un profesor que tuve: Programar es un arte, no todo el mundo sabe hacerlo bien.
La programación es como la química. Podés saber que este gas se combina con aquél otro para formar una molécula de tal otra cosa y ya con eso decís que sabés química, pero en realidad podés no saber porqué el gas aquel se combina con este otro. En programación podés saber que si un parámetro se pasa por referencia, la variable del invocador se verá modificada al modificar el parámetro, pero si no sabés que hay un apuntador detrás de ello ¿sabés programación?
¿Qué es la Pila? ¿Qué son los registros del procesador? ¿Qué es el estándar IEEE 754? ¿Qué es el Heap? ¿Qué es una página de memoria? ¿Y un segmento? ¿Porqué conviene alinear los datos en memoria a múltiplos del tamaño del dato? ¿Qué es un arbol binario? ¿y un Montículo? ¿Y un arbol de decisión? ¿Sabía que el Mouse mide las distancias en unidades llamadas "Mickeys"? (Esta última es totalmente irrelevante )
Si el cometario #3 es para mi.. Se muy bien todo eso... He programado tanto en lenguajes de alto nivel (java, Vb, ...) mediano nivel(c++) bajo nivel (assembler) y comprendo muy bien como funciona todo ... Este articulo es para conocer algunas debilidades que tienen muchos programadores y que tambien uno puede tener (porque existen varios paradigmas de programacion, por ejemplo, y a veces es dificil cambiarde un paradigma de programacion a otro, por ejemplo de oop a funcional, si me entiendes).. Pero si quieres que te lo explique entonces me avisas a ver si te lo ayudo a comprender mejor... ah por cierto mi especialidad es en "embedded systems" asi que conozco mucho de como funciona todo en un procesador....
#4 emm... no, no necesito que me expliques nada... yo ya sé todo eso. Me refería a que no creo que un programador que conozca todo superficialmente sea un "verdadero" programador.
Es mucho más fácil programar sabiendo exactamente qué es lo que hace el procesador. Un programador de alto nivel ve una instrucción como "IF (BanderasEstado AND YaCurrado) 0 THEN" de Basic y no sabe que para el procesador eso es:
TEST DB[BanderasEstado], YaCurrado
JZ I01
¿Es necesario saberlo? No, para nada. Pero ayuda mucho comprender lo que sucede "entre bambalinas", como dicen. En este caso la instrucción de assambler es más clara que la de Basic, porque es más directa sobre que lo que se hace es testear una o mas banderas. ¿Me explico ahora?
ok, esta bien.. parece que te malinterprete...
Es decir... ¿cómo puede un programador trabajar con variables si no sabe lo que es la Pila o el Heap? Si no tenés idea sobre eso obviamente que no podrás entender bien que es un apuntador y porqué es necesario. Menos aún se pueden comprender las clases sin saber lo que es la Pila y el Heap. Las variables en la Pila son destruídas automáticamente, las en el Heap no. Algunos lenguajes pueden hacer aparentar que no hay diferencia entre objetos alojados en la pila y objetos alojados en el Heap y destruir automáticamente, pero si no es el caso, los datos se pierden en lugar de destruirse.
Si yo enseñase programación, los tendría sufriendo primero con assambler. Luego los haría sufrir con ANSI C, Luego con C++ y, finalmente, con Java. Una tortura continua
#6, a perdon... me tenté y seguí escribiendo