Opieram to przede wszystkim na asemblerze, z którego korzystałem - przede wszystkim na MASM, NASM i (w mniejszym stopniu) TASM. Niektóre z późniejszych wersji TASM miały (mają?) Pewne funkcje do obsługi OO, ale nie używałem ich zbyt często i nie próbuję ich komentować.
Po pierwsze: większość języków przesunęła się w kierunku struktury, która przynajmniej przypomina drzewo. Niezależnie od tego, czy jest obiektowa, czy obiektowa, czy dokładnie to, co jest dość zdefiniowane w relacjach między różnymi częściami systemu. Jest też sporo do „ochrony” jednej części systemu przed przypadkowym „wtrąceniem się”, ale innych części (nawet jeśli ochrona może być zwykle ominięta, jeśli chcesz). Natomiast język asemblera jest stosunkowo „płaski” - większość relacji między kodem (i danymi) w różnych częściach systemu jest ustalana przede wszystkim na podstawie dokumentacji oraz, w mniejszym stopniu, konwencji nazewnictwa.
Powoduje to, że często łatwiej jest połączyć kod znacznie ściślej niż byłoby to idealne. Wymagania, które doprowadziły do wyboru języka asemblera na początek (wyższa wydajność, mniejszy rozmiar itp.) Często również to wynagradzają - omijając zatwierdzone interfejsy i często można uzyskać kod, który jest mniejszy i szybszy (choć zwykle nie za dużo lepiej w dowolnym wymiarze). Język i narzędzia same w sobie robią znacznie mniej, aby ograniczyć to, co robisz (dobre lub złe), co znacznie obciąża menedżerów, aby zapobiegali problemom. Nie powiedziałbym, że jest jakościowo różny, ale pod względem ilościowym jest - tzn. Zarząd musi pracować, aby zapobiec problemom w obu kierunkach, ale w przypadku języka asemblera zwykle przyjmuje więcej (i często ściślejsze) wytyczne na temat tego, co jest lub nie jest dopuszczalne.
Łagodzenie tego jest w dużej mierze kwestią bardziej uważnych wytycznych, więcej wskazówek od bardziej doświadczonego personelu oraz bardziej szczegółowych, dokładnie egzekwowanych konwencji nazewnictwa.
Personel stanowi problem. Problemy, które napotkałem, nie były jednak tymi, których się spodziewałem. Znalezienie facetów z odrobiną „wojownika”, którzy chętnie wskoczyli do kodu języka asemblera, było dość łatwe. Większość wykonała całkiem rozsądną robotę, pomimo prawie całkowitego braku wcześniejszego doświadczenia w posługiwaniu się językiem asemblera.
Trudność, jaką napotkałem, polegała na znalezieniu większej liczby pracowników wyższego szczebla - ludzi, którzy mogliby utrzymać projekt przynajmniej pod pozorem kontroli i nie byli w pełni przyzwyczajeni do języków, które zapewniałyby (i w dużej mierze egzekwowały) wytyczne niezbędne do racjonalnego utrzymania kodu łatwe do utrzymania i zrozumiałe.
Patrząc wstecz, mogłem / spowodowałem jakiś największy problem w tym zakresie. Z mojej strony widzę dwa źródła problemów. Po pierwsze, do czasu projektu, o którym myślę, pisałem głównie w językach wyższego poziomu i używałem tylko języka asembleraw ostateczności. Jako taki, kiedy go użyłem, prawie każda możliwa sztuczka w celu zwiększenia wydajności była nie tylko uczciwą grą, ale się spodziewała. Po drugie, kiedy pracowałem nad niektórymi systemami napisanymi w całości (lub przede wszystkim) w języku asemblera, było to pod kierownictwem niektórych kierowników projektów o żelaznych rękach. W tym czasie byłem stosunkowo młody i szczerze nie podobało mi się to, że prowadzili różne rzeczy, więc zwykle robiłem coś przeciwnego. Z perspektywy czasu to, co robili, było naprawdę ważne, a nie zrobione tylko dlatego, że były stare i nieelastyczne (co, jestem prawie pewien, jak to wtedy widziałem).