Sto basando questo principalmente sugli assemblatori che ho usato - principalmente MASM, NASM e (in misura minore) TASM. Alcune delle versioni successive di TASM avevano (hanno?) Alcune funzionalità per supportare OO, ma non le ho usate molto e non sto cercando di commentarle.
Primo: la maggior parte delle lingue si è spostata verso una struttura che è almeno in qualche modo simile ad un albero. Sia orientato agli oggetti, o basato sugli oggetti, o esattamente cosa, c'è un po 'definito sulle relazioni tra le diverse parti di un sistema. C'è anche un bel po 'di "proteggere" una parte di un sistema da "interferenze" accidentali, ma altre parti (anche se la protezione può di solito essere aggirata se si desidera). Al contrario, il linguaggio assembly è relativamente "piatto" - la maggior parte delle relazioni tra il codice (e i dati) in diverse parti del sistema sono stabilite principalmente dalla documentazione e, in misura minore, dalle convenzioni di denominazione.
Il risultato di ciò è che spesso è molto più facile accoppiare il codice molto più strettamente di quanto sarebbe l'ideale. I requisiti che hanno guidato la scelta del linguaggio di assemblaggio con cui iniziare (prestazioni più elevate, dimensioni più ridotte, ecc.) Spesso premiano anche questo, bypassando le interfacce approvate e in tal modo è spesso possibile ottenere codice più piccolo e più veloce (anche se di solito non molto meglio in qualsiasi dimensione). Il linguaggio e gli strumenti stessi fanno molto meno per limitare ciò che fai (bene o male), il che comporta un onere molto maggiore per i manager per prevenire problemi. Non direi che è qualitativamente diverso, ma quantitativamente lo è - vale a dire, la direzione deve lavorare per prevenire i problemi in entrambi i modi, ma nel caso del linguaggio assembly generalmente richiede più linee guida (e spesso più rigide) su ciò che è o non è t accettabile.
La mitigazione è in gran parte una questione di linee guida più attente, più guida da parte di personale più esperto e convenzioni di denominazione più specifiche e attentamente applicate.
Il personale è un problema. I problemi che ho riscontrato, tuttavia, non erano principalmente quelli che mi aspettavo. Trovare ragazzi con un po 'di personalità "combattente" che erano felici di saltare nel codice del linguaggio assembly è stato abbastanza facile. La maggior parte ha svolto un lavoro abbastanza ragionevole, nonostante una mancanza quasi totale di esperienza precedente nell'uso del linguaggio assembly.
La difficoltà che ho incontrato è stata quella di trovare più personale senior - persone che potevano mantenere il progetto sotto almeno una parvenza di controllo e non erano completamente abituate a linguaggi che avrebbero fornito (e in gran parte applicato) le linee guida necessarie per mantenere il codice ragionevolmente mantenibile e comprensibile.
Guardando indietro, potrei essere stato / aver causato alcuni dei maggiori problemi al riguardo. Vedo due fonti di problemi da parte mia. Innanzitutto, al momento del progetto a cui sto pensando, avevo programmato per un po 'di tempo principalmente in linguaggi di livello superiore e usando solo il linguaggio assemblycome ultima opzione. In quanto tale, quando l'ho usato, quasi ogni possibile trucco per ottenere prestazioni non era solo un gioco equo, ma previsto. In secondo luogo, quando avevo lavorato su alcuni sistemi scritti interamente (o principalmente) in linguaggio assembly, era sotto alcuni gestori di progetto piuttosto a pugni. All'epoca ero relativamente giovane, e francamente mi risentivo per il modo in cui gestivano le cose, quindi tendevo a fare il contrario. In retrospettiva, quello che stavano facendo era davvero importante, e non fatto solo perché erano vecchi e poco flessibili (il che, sono abbastanza sicuro di come vedevo le cose in quel momento).