Barrapunto

> Se deben usar punteros o iteradores pero en fin. for (i=1; i!=100; i++) { } ¿Necesito un iterador? ¿Necesito un puntero?

>igual que otra cosa que se llama inlining y que todos* los compiladores hacen.
Conozco el inline. ¿Pero hay garantía absoluta que el compilador lo implementa igual a que estuviesen las líneas en el código? ¿Vistes el ensamblado?

>Sobre todo en cpus con ventanas de registros :-P
Claro!! como estas ventanas NO tienen límites en la caché... oh wait!.. hay que usar RAM después de un límite.

>El coste de mantener algo que es "poderoso", "flexible" y "escalable" pero lento es algo así como cien veces menor.
¿Que es "mantener" para ti? ¿Corregir montones de errores en el código o que no se entendió los requerimientos del usuario y hay que reprogramarlo? Porque si es para ampliar funcionalidad entonces ese día la tecnología ha cambiado y debes empezar de cero.

> Otra regla que supongo que no te enseñaron es que las optimizaciones tempranas son malignas :-)
Lo se, primero haz el algoritmo que funcione y pase todas las pruebas y lo optimizas poco a poco mateniendo una generosa pila de pruebas entre el anterior bueno y el nuevo algoritmo optimizado para comparar y detectar fallas debido a la optimización.

>¿Conoces Ada?, ¿dejarías el control de una planta nuclear a un sistema que no tuviera esas salvaguardas?
No conozco ADA pero si se me dibuja una sonrisa pensando que otros programadores humanos como yo han creado salvaguardas infalibles, jajajaja, me recuerda cuando salió Java que teoricamente era inmune a las fallas de memoria y que el aislamiento del programa hacia imposible hacer código malicioso... ahhhh!!! la teoría.... supongo que te has informado como son las cosas en la práctica.

>No deseo a nadie que tenga que trabajar en algo escrito por ti.
Por que? Por diferir en tu opinión? Vaya tolerancia la tuya... pero si, tengo mucho código allá afuera usado por mucha gente actualmente y mi casilla de correo de quejas esta vacía... por algo será.