Barrapunto

Los 10 problemas venideros:

1. Me compro 10 Xbox360 basados en PPC970 (PowerPC de 64 bits) para hacerme un cluster pero el precio verá multiplicado por 10.

2. Con 10 Xbox360 tendré 30 cores, 5120 MiB de RAM y 32 GHz pero consumirán uno o dos kilowatios para un niño linuxero de casa.

3. Microsoft a través de sus Xbox360 ha impedido la ejecución de código linux porque los sectores de arranque están encriptados. Así que los 10 Xbox360 no valdrán para nada si quieres Scene Linux.

4. No hay OS de Cluster de Linux para Xbox360, y en caso de haberlo es que está muy obsoleto que corre en tecnología obsoleta.

5. Esto permite reducir a la décima parte pico del tiempo de compilación de proyectos opensource a la gentoo, pero claro, no hay aplicaciones paralelas diseñadas para Xbox360.

6. Hay demasiada especulación del futuro de Xbox360. Hay mucho futuro incierto y con llenos de temores de malas prácticas.

7. Los 3 luces rojas de alguna Xbox360 hará caer todo el sistema clusterizado.

8. Hay muchos cuellos de botella en las comunicaciones entre los Xbox360, sobre todo en los de 10/100 Ethernet cuando hay 1/10 GigaEthernet en los PCs.

9. Su elevado precio el Xbox360 que vende no me compensa con respecto a un decente PC con 3.5 GiB de RAM frente a una Xbox360 de 0.5 GiB de RAM.

10. Las garantías de Xbox360 ya no me sirven, tú lo pagas los defectos, gastos, transportes y perjuicios causados por tu Xbox360-escenado.

10+1. En tu basura ya irás acumulando 25 o 30 Xbox360es defectuosos a la fuerza por parte de la fábrica de Microsost.

Cuando los hombres eran hombres, ajua!

Porque casi todos tus puntos se resumen en la optimizacion de recursos?
Y el tiempo de desarrollo?,
Y el costo beneficio de utilizar frameworks de desarrollo rapido y estandarizado contra tener que revivir a los dinosaurios cada vez que haya que hacer un cambio?
Las malas practicas de programacion las ha habido desde el jurasico, no hay que confundir novatos con lenguajes de moda.
Muchos de tus puntos de malas practicas son muy ciertos, pero no veo porque al final tenias que derramar tanta nostalgia senil con eso de que se consumen muchos recursos con las APIS y las herramientas que ahorran tiempo en el desarrollo.

Pedíamos páginas XMS o reservábamos marcos de EMS. Después incluso poníamos la máquina en modo protegido y accediamos linealmente a la memoria.

Se deben usar punteros o iteradores pero en fin.

Tú eres de los que usan campos de bits para definir booleanos porque ocupan menos memoria que los int, ¿verdad? :-)

Las variables char ocupan en el código 4 bytes (o el tamaño de int) en el 99.999% de las plataformas por una cosa misteriosa llamada "alineamiento" :-). Algunos micros no leen direcciones que no estén alineadas al tamaño de int (que coincide con el ancho de registro) o del bus de datos. Otros, como x86, son lentos si no se hace.

Lo del mantenimiento y la reglilla de que el cuerpo de las funciones debe caber tabulado a 80 columnas en una pantalla también te es desconocido, igual que otra cosa que se llama inlining y que todos* los compiladores hacen.

Sobre todo en cpus con ventanas de registros :-P

El coste de mantener algo que es "poderoso", "flexible" y "escalable" pero lento es algo así como cien veces menor (en sueldos y horas de trabajo), con lo que te ahorras tienes de sobra para comprar más máquinas. Además algo "poderoso", "flexible" y "escalable" siempre se puede optimizar a posteriori mucho más fácil y barato que convertir algo "rápido" en "poderoso", "flexible" y "escalable". Otra regla que supongo que no te enseñaron es que las optimizaciones tempranas son malignas :-)

¿Conoces Ada?, ¿dejarías el control de una planta nuclear a un sistema que no tuviera esas salvaguardas?

Un problema real es que personas como tú creen que saben de lo que hablan y a lo mejor están incluso escribiendo código que se usa ahí fuera. No deseo a nadie que tenga que trabajar en algo escrito por ti.

¿Llamas hacer maravillas a meter un programa en 640 KiB? Entonces meterlos en menos de 64 KiB, por ejemplo en las máquinas con sistema operativo CP/M o en los Apple II debe de ser por lo menos un milagro o dos. Y no hablo ya de meterlos en un PIC de un puñadito de KiB, por limitar el tema a máquinas que se usaran para aplicaciones de gestión.

Tío, te has quedado obsoleto. Tanto al programador como al cliente lo que le interesa es la rapidez del desarrollo. Si un programa de gestión en .NET me ocupa, pongamos 80 MB de RAM y lo he hecho con cuatro clics en Visual Studio, ¿qué gano con hacerlo en C++ optimizando código y depurando si tardo 4 veces más para que ocupe sólo 10 MB de RAM? La industria mató a la artesanía hace mucho tiempo..

claro abuelo claro, anda toma tu medicina. ^_^

...que el que hizo la lista de la noticia.

El problema se llama estrechez de miras.

Ni todas las aplicaciones tienen que lidiar con bases de datos y conversiones de monedas o similares (como parece creer el autor de la lista original) ni todas las aplicaciones tienen como prioridad la optimización de la velocidad de ejecución (como su excelencia el Experto Experimentado sugiere).

Hay aplicaciones donde el tamaño del programa puede ser más importante que su velocidad (no siempre relacionados), o donde el tiempo de desarrollo es crítico, o donde la portabilidad es esencial...

Es más, incluso en campos donde la velocidad es muy importante, puede merecer la pena ir a más alto nivel. Un ejemplo: trabajo haciendo aplicaciones de cálculo científico. Las hacía en C siguiendo las reglas básicas de optimización como las que has mencionado. Ahora, en cambio, las escribo en Python y, aunque sigo optimizando de forma razonable, no pierdo mucho tiempo. Al final, son aplicaciones que se ejecutan menos de 10 veces antes de tener que modificarlas para incluir cosas nuevas... así que el tiempo de desarrollo es mucho más importante que el de ejecución.

¿Soy un inepto por hacerlo así? No. Conozco las alternativas y escojo la que mejor se adapta a cada situación concreta.

Anda, vete a programar un buscaminas en ensamblador, que mientras yo lo haré con PyQT.

5. Funciones recursivas: el pecado original de la programación... ¿no saben que este tipo de programación consume demasiados recursos y es lenta?

¿Sabes lo que es la recursividad terminal? Es cuando la llamada recursiva se encuentra en el último lugar de la función. Cualquier compilador para un lenguaje funcional es capaz de convertirlo en una iteración. Que los compiladores para lenguajes imperativos no le den importancia a la recursividad, y no sean capaces de aplicar una optimización tan vieja, no significa que la recursividad sea mala.