Barrapunto

Primero, C no es un lenguaje de alto nivel si tenemos en cuenta la cantidad de nuevos lenguajes mucho más orientados al problema que a la máquina que existen ahora.

Y ni mucho menos eres capaz de solucionar un error tras 20 segundos de revisar código a menos que sea muy evidente. Y aquí te hablan 10 años de intensa experiencia en C: hay que haberse curtido mucho para saber qué y cómo encontrar los problemas sin morirte en el intento (y no sólo hablo de bugs inherentes a un fallo o desconocimiento del lenguaje, también de conceptos y procesos de sistemas varios y plataformas sobre las que haya que programar).

Y segundo, es posible entender una aplicación de cualquier tamaño a base de ensamblador, incluso siendo la salida de un desensamblador. El problema es que es muy laborioso (ése es tu punto, pero POSIBLE es), muy probablemente la naturaleza del código te lleve a asumir cosas erróneas o a malinterpretar otras si no te cuidas mucho de ello, y es un infierno infernal. Pero posible es, y capacidad humana la hay, lo único es que es un enorme trabajo que no te llevará a muchos sitios que digamos.

Por ejemplo, cuando uno no tiene ni idea y quiere crackear una aplicación, debe meterse en algo similar. Si uno tiene idea de la arquitectura y sistema operativo en el que trabaja dicha aplicación, puede usar técnicas conocidas por su propia experiencia o la de otros para acortar el trabajo. Como de hecho es lo que se hace conmúnmente para estas cosas y con bastante rapidez.

Y ya que estamos voy a aprovechar para contestar a otro que dijo por ahí algo así como que necesitó de 100.000 líneas de ensamblador en sus tiempos con OO y optimización agresiva. A ese señor lo primero que me gustaría preguntarle es: ¿de qué tiempos habla?

Porque 100k lineas de ensamblador son muchas. Y memoria para eso no habia mucha hasta hace poco más de decada y media. Y potencia tampoco sobraba. Y menos para andar con OO y a la vez optimizaciones agresivas. Y pensándolo bien, ¿qué programa podría requerir en "aquellos" tiempos 100k lineas de ensamblador, optimización agresiva (en las 100k lineas también?) y -quizás?- OO?

Dada mi experiencia y conocimiento de lo que estamos hablando solo me queda decirle esto a ese señor: si debiste(is) usar 100k líneas de ensamblador en tus "tiempos", solo puede ser porque eres (sois) un(os) inepto(s) del quince, porque no tienes (teneis) mucha idea ni has (habéis) tocado muchos lenguajes ensamblador y porque básicamente estás mintiendo como un condenado: ningún programador de ensamblador que sea digno de serlo presumiría de haber necesitado 100k lineas para una "aplicacion", optimizada agresivamente y con OO, y menos "en sus tiempos". Eso se cae por su propio peso.

Podría ser que en estos ultimos años se hayan hecho aplicaciones de 100k lineas y optimizadas (¿cuantas tiene el zsnes?). Si quieres, incluso con OO apurando, dándole un uso mínimo, sacando optimizaciones de cada rincón, usando sólo aquellos aspectos de OO que no interfieren demasiado en el rendimiento, etc, etc. Pero vamos, que nos estás metiendo una bola colosal, y has meado fuera del tiesto.