Je base cela principalement sur les assembleurs que j'ai utilisés - principalement MASM, NASM et (dans une moindre mesure) TASM. Certaines des versions ultérieures de TASM avaient (ont?) Des fonctionnalités pour prendre en charge OO, mais je ne les ai pas beaucoup utilisées et je n'essaie pas de les commenter.
Premièrement: la plupart des langues ont évolué vers une structure qui est au moins un peu comme un arbre. Qu'il soit orienté objet, ou basé sur un objet, ou exactement quoi, il y a beaucoup de choses définies sur les relations entre les différentes parties d'un système. Il y a aussi beaucoup de choses à "protéger" une partie d'un système contre les "interférences" accidentelles, mais d'autres parties (même si la protection peut généralement être contournée si vous le souhaitez). En revanche, le langage d'assemblage est relativement "plat" - la plupart des relations entre le code (et les données) dans différentes parties du système sont établies principalement par la documentation et, dans une moindre mesure, par les conventions de dénomination.
Le résultat de cela est qu'il est souvent beaucoup plus facile de coupler le code beaucoup plus étroitement que ce ne serait idéal. Les exigences qui ont motivé le choix du langage d'assemblage pour commencer (performances plus élevées, taille plus petite, etc.) récompensent souvent cela également - en contournant les interfaces approuvées et ainsi vous pouvez souvent obtenir du code plus petit et plus rapide (mais généralement pas beaucoup) mieux dans toutes les dimensions). Le langage et les outils eux-mêmes font beaucoup moins pour restreindre ce que vous faites (bon ou mauvais), ce qui impose une charge beaucoup plus lourde aux gestionnaires pour éviter les problèmes. Je ne dirais pas que c'est qualitativement différent, mais quantitativement - c'est-à-dire que la direction doit travailler pour éviter les problèmes de toute façon, mais dans le cas du langage d'assemblage, il faut généralement des directives plus (et souvent plus strictes) sur ce qui est ou ce qui ne l'est pas '' t acceptable.
L'atténuation de ces problèmes est en grande partie une question de directives plus rigoureuses, davantage de conseils de la part d'un personnel plus expérimenté et de conventions de dénomination plus spécifiques et soigneusement appliquées.
La dotation est un problème. Les problèmes que j'ai rencontrés, cependant, n'étaient pas principalement ceux auxquels je m'attendais. Trouver des gars avec un peu de personnalité "fighter jock" qui étaient heureux de sauter dans le code du langage d'assemblage était assez facile. La plupart ont fait un travail assez raisonnable, malgré un manque presque total d'expérience préalable dans l'utilisation du langage d'assemblage.
La difficulté que j'ai rencontrée a été de trouver plus de cadres supérieurs - des gens qui pouvaient garder le projet sous au moins un semblant de contrôle, et n'étaient pas complètement habitués aux langues qui fourniraient (et appliqueraient en grande partie) les directives nécessaires pour garder le code raisonnablement maintenable et compréhensible.
Avec le recul, j'ai peut-être été / causé certains des plus gros problèmes à cet égard. Je peux voir deux sources de problèmes de ma part. Tout d'abord, au moment du projet auquel je pense, j'avais codé principalement dans des langages de niveau supérieur pendant un bon moment, et en utilisant uniquement le langage d'assemblageen dernier recours. En tant que tel, lorsque je l'ai utilisé, presque toutes les astuces possibles pour gagner en performance n'étaient pas seulement un jeu équitable, mais attendu. Deuxièmement, à l'époque où j'avais travaillé sur certains systèmes écrits entièrement (ou principalement) en langage assembleur, c'était sous la direction de chefs de projet plutôt ironiques. À l'époque, j'étais relativement jeune et je regrettais franchement la façon dont ils géraient les choses, alors j'avais tendance à faire le contraire. Rétrospectivement, ce qu'ils faisaient était vraiment important, et pas seulement parce qu'ils étaient vieux et inflexibles (ce qui, je suis à peu près sûr, c'était comment je voyais les choses à l'époque).