Estoy basando esto principalmente en los ensambladores que he usado, principalmente MASM, NASM y (en menor medida) TASM. Algunas de las versiones posteriores de TASM tenían (¿tienen?) Algunas características para admitir OO, pero no las he usado mucho y no estoy tratando de comentarlas.
Primero: la mayoría de los lenguajes se han movido hacia una estructura que es al menos algo similar a un árbol. Ya sea orientado a objetos, o basado en objetos, o exactamente qué, hay un poco definido sobre las relaciones entre las diferentes partes de un sistema. También hay bastante para "proteger" una parte de un sistema de "intromisiones" accidentales, pero otras partes (aunque la protección generalmente se puede omitir si lo desea). Por el contrario, el lenguaje ensamblador es relativamente "plano": la mayoría de las relaciones entre el código (y los datos) en diferentes partes del sistema se establecen principalmente por documentación y, en menor medida, por convenciones de nombres.
El resultado de esto es que a menudo es mucho más fácil acoplar el código mucho más estrictamente de lo que sería ideal. Los requisitos que impulsaron la elección del lenguaje ensamblador para comenzar (mayor rendimiento, menor tamaño, etc.) a menudo también recompensan esto: al pasar por alto las interfaces aprobadas, puede obtener un código más pequeño y más rápido (aunque generalmente no mucho). mejor en cualquier dimensión). El lenguaje y las herramientas en sí hacen mucho menos para restringir lo que haces (bueno o malo), lo que supone una carga mucho mayor para los gerentes para evitar problemas. No diría que es cualitativamente diferente, pero cuantitativamente lo es, es decir, la administración tiene que trabajar para evitar problemas de cualquier manera, pero en el caso del lenguaje ensamblador, generalmente se necesitan más (y a menudo más estrictas) pautas sobre lo que es o no es t aceptable.
Mitigar esto es en gran medida una cuestión de pautas más cuidadosas, más orientación de personal más experimentado y convenciones de nomenclatura más específicas y cuidadosamente aplicadas.
La dotación de personal es un problema. Sin embargo, los problemas que he encontrado no eran principalmente los que esperaba. Encontrar muchachos con un poco de personalidad de "deportista de combate" que estaban felices de saltar al código del lenguaje ensamblador fue bastante fácil. La mayoría hizo un trabajo bastante razonable, a pesar de una falta casi total de experiencia previa en el uso del lenguaje ensamblador.
La dificultad que encontré fue encontrar más personal de alto nivel: personas que pudieran mantener el proyecto bajo al menos una apariencia de control y que no estuvieran completamente acostumbrados a los idiomas que proporcionarían (y en gran medida impondrían) las pautas necesarias para mantener el código razonablemente Mantenible y comprensible.
Mirando hacia atrás, es posible que haya sido / causado el mayor problema a ese respecto. Puedo ver dos fuentes de problemas de mi parte. Primero, para el momento del proyecto en el que estoy pensando, había estado codificando principalmente en lenguajes de nivel superior durante bastante tiempo, y usando solo lenguaje ensambladorcomo último recurso. Como tal, cuando lo usé, casi todos los trucos posibles para ganar rendimiento no solo fueron un juego justo, sino que se esperaban. En segundo lugar, cuando había trabajado en algunos sistemas escritos completamente (o principalmente) en lenguaje ensamblador, estaba bajo algunos gerentes de proyecto bastante forzados. En ese momento yo era relativamente joven y, francamente, me molestaba la forma en que manejaban las cosas, por lo que tendía a hacer lo contrario. En retrospectiva, lo que estaban haciendo realmente era importante, y no solo porque eran viejos e inflexibles (lo cual, estoy bastante seguro, fue cómo vi las cosas en ese momento).