Czy konieczne jest zrozumienie, co dzieje się na poziomie sprzętowym, aby być dobrym programistą?

24

Jestem programistą-samoukiem, na wypadek, gdyby na to pytanie udzielono odpowiedzi w CS 101. Nauczyłem się i używałem wielu języków, głównie na własny użytek, ale czasami do rzeczy profesjonalnych.

Wygląda na to, że zawsze napotykam na tę samą ścianę, kiedy mam problemy z programowaniem. Na przykład właśnie zadałem pytanie na innym forum, w jaki sposób obsługiwać wskaźnik do tablicy zwrócony przez funkcję. Początkowo myślę, że po prostu nie znam właściwej techniki, którą projektanci C ++ ustawili, aby poradzić sobie z sytuacją. Ale z odpowiedzi i dyskusji, które następują, widzę, że tak naprawdę nie rozumiem, co się dzieje, gdy coś jest „zwracane”.

Jak głęboki poziom zrozumienia procesu programowania musi osiągnąć dobry programista?

bev
źródło
3
Moja rada: poznaj zestaw x86 (DOS lub inny). Następnie naucz się czytać niektóre dane wyjściowe asemblera niektórych małych fragmentów kodu C. Zadawaj pytania, jeśli nie rozumiesz wyników. Powtarzać. To zmusi cię do zrozumienia, co dzieje się na poziomie procesora
Earlz
Earlz - Czy masz na myśli, że powinienem nauczyć się programować przy użyciu zestawu instrukcji x86? Czy to „poziom procesora”?
Bev
Job - dzięki, było fajnie. Popełnił kilka błędów, po prostu FYI.
Bev

Odpowiedzi:

33

Nie. Nikt nie rozumie, co się dzieje na poziomie sprzętowym.

Systemy komputerowe są jak cebula - istnieje wiele warstw, a każda z nich zależy od warstwy pod nią do wsparcia. Jeśli jesteś facetem pracującym na jednej z zewnętrznych warstw, nie powinieneś zbytnio przejmować się tym, co dzieje się w środku cebuli. I to dobrze, ponieważ środek cebuli zawsze się zmienia. Tak długo, jak warstwa lub warstwy, które obsługują daną warstwę, nadal wyglądają tak samo i obsługują warstwę, jesteś dobry.

Ale potem znowu...

Tak. To znaczy, nie musisz rozumieć, co naprawdę dzieje się wewnątrz cebuli, ale bardzo pomaga mieć mentalny model tego, jak wygląda wnętrze typowej cebuli. Być może nie najgłębsza część, w której masz bramki złożone z tranzystorów i tak dalej, lub następna warstwa lub dwie, gdzie masz mikrokod, zegar, jednostki dekodujące instrukcje itp. Jednak kolejne warstwy są tam, gdzie Mam rejestry, stos i stos. Są to najgłębsze warstwy, na które masz duży wpływ na to, co się dzieje - kompilator tłumaczy Twój kod na instrukcje działające na tym poziomie, a jeśli chcesz, zwykle możesz przejść przez te instrukcje i dowiedzieć się, co się naprawdę dzieje.

Najbardziej doświadczeni programiści mają w głowie nieco bajkową wersję tych warstw. Pomagają zrozumieć, o czym mówi kompilator, gdy mówi, że wystąpił „wyjątek nieprawidłowego adresu” lub „błąd przepełnienia stosu” lub coś podobnego.

Jeśli jesteś zainteresowany, przeczytaj książkę o architekturze komputera. Nie musi to być nawet szczególnie nowa książka - komputery cyfrowe działają od dłuższego czasu w podobny sposób. Im więcej dowiesz się o wnętrzu cebuli, tym bardziej będziesz zdumiony, że którekolwiek z tych rzeczy w ogóle działa! Uczenie się (w przybliżeniu) tego, co dzieje się w niższych warstwach, sprawia, że ​​programowanie jest zarówno mniej tajemnicze, jak i bardziej magiczne. I naprawdę więcej zabawy.

Inną rzeczą, na którą możesz spojrzeć, jest osadzona cebula. Mam na myśli systemy wbudowane. Istnieje wiele wbudowanych platform, które są dość łatwe w użyciu: Arduino i BASIC Stamp to dwa przykłady. Są to w zasadzie małe mikroprocesory z wieloma wbudowanymi funkcjami. Możesz myśleć o nich jak o cebuli z mniejszą ilością warstw niż w typowym komputerze stacjonarnym, więc możesz dokładnie zrozumieć, co dzieje się w całym systemie, od sprzętu po oprogramowanie.

Caleb
źródło
2
Dzięki. To w zasadzie odpowiada na moje pytanie. Jestem EE, który zaprojektował rejestry, sumatory, multipleksery itp. Na poziomie układów (tj. Na poziomie tranzystorów), więc otrzymuję najniższy poziom (chyba że mówimy o mechanice kwantowej). Mogę również używać języków, które znam dość dobrze. Mam po prostu ogromną lukę na środkowym poziomie (stos, stos), gdzie, jak mówisz, kompilator wykonuje swoją pracę. Ponieważ, jak to ująłeś, chcę, aby moje doświadczenie w programowaniu było „mniej tajemnicze i ... bardziej magiczne”. wygląda na to, że powinienem przestudiować poziomy, które wciąż są mi nieznane.
Bev
@bev: W takim przypadku naprawdę powinieneś sprawdzić platformę taką jak Arduino.
Caleb
przepraszam, że jestem nudny, ale sprawdziłem Arduino i naprawdę nie widzę, jak użycie go pomogłoby mi zrozumieć, w jaki sposób kompilator traktuje wskaźniki i tablice inaczej. Czego nie widzę
Bev
@bev: Jeśli chcesz tylko dowiedzieć się, jak wywoływane są funkcje, prawdopodobnie możesz poświęcić 30 minut na przeczytanie o tym i gotowe. Jeśli chcesz lepiej zrozumieć, jak wszystko działa razem, będzie to najłatwiejsze z małym systemem. To najlepszy sposób, aby od razu włożyć całą cebulę do głowy. AVR, rodzina układów, na których opiera się Arduino, to przyjemny, ogólny, łatwy w użyciu system z zestawem instrukcji, który jest wystarczająco mały, aby uczyć się bez większych problemów.
Caleb
Ach, okej. Strona główna jest nieco mroczna w tym aspekcie swoich produktów. Spojrzę jeszcze raz.
Bev
10

Nie mówisz o poziomie sprzętu, mówisz o tym, co kompilator naprawdę robi z tym, co mu nakazujesz.

Z pewnością potrzebujesz takiego poziomu zrozumienia, aby dowiedzieć się, co poszło nie tak, gdy nie jest to oczywiste, szczególnie w przypadku sytuacji, w której następuje utrata pamięci.

Loren Pechtel
źródło
Loren - Tak! Dzięki za prostą prawdę. Teraz muszę znaleźć najlepszy sposób, aby dowiedzieć się, co kompilatory c ++ robią z ich typami danych. BTW, jako EE, wiem, że dosłownie nie jest to poziom sprzętowy. Po prostu nie wiedziałem, jak to nazywacie maniacy CS. (Nadal nie o to chodzi poziomu kompilatora.?)
Bev
BTW - stomp pamięci?
Bev
@Bev: Właśnie udowodniłeś mi, o co mi chodzi - jeśli nawet nie wiesz, co to jest depresja, będziesz miał okropny czas ze względu na błąd. Tąpnięcie w pamięć ma miejsce wtedy, gdy coś zapisuje w miejscu, którego nie powinno, i usuwa (tupie) wszystko, co się tam zdarzyło. Jeśli masz szczęście, to, co trafiłeś, było natychmiast niezbędne i przynajmniej wybuchło. Jeśli masz pecha, program po prostu ma pewne dziury w swoich danych.
Loren Pechtel
Dziękuję za wyjaśnienie. Pokazuje mi również, jak wiele nie wiem, ponieważ o ile wiem, po prostu piszę na stosie lub stosie, bez dokładniejszej kontroli.
Bev
@Bev: Problem pojawia się, gdy piszesz w miejscu, w którym myślisz, że nie piszesz. Masz coś na stosie i robisz do tego wskaźnik. Opuszczasz rutynę - przedmiot znika, wskaźnik nie. Co się stanie, gdy napiszesz do tego wskaźnika? A może masz tablicę 100 pozycji - co się stanie, gdy napiszesz do pozycji 200?
Loren Pechtel
6

Zrozumienie pamięci programu! = Zrozumienie sprzętu

Zrozumienie hierarchii pamięci == Zrozumienie sprzętu


Aby odpowiedzieć na ogólne pytanie: To zależy. Zrozumienie sprzętu nie zaszkodzi, ale zrozumienie go nie pomoże we wszystkich przypadkach.

Na podstawie Twojego przykładu, musisz tylko dowiedzieć się więcej o tym, jak pamięć jest dzielona i jak jest zorganizowana podczas uruchamiania programu. Zrozumienie sprzętu nie pomoże ci w tym zakresie, ponieważ pamięć (widoczna dla programu) nawet nie reprezentuje sprzętu dzięki magii pamięci wirtualnej.

Gdybyś był ciekawy problemów z wydajnością w oparciu o kolejność uzyskiwania dostępu do pamięci, TERAZ skorzystałbyś na zrozumieniu sprzętu, dziedziczności pamięci, brakach pamięci podręcznej, błędach strony i całej chwalebnej wspaniałości, która pochodzi ze sprzętu.

riwalk
źródło
Stargazer - Nie jestem jeszcze w punkcie, w którym mogę się martwić problemami z wydajnością. Mam nadzieję, że wkrótce. Dziękuję za komentarze.
Bev
5

Jeśli nie zdecydujesz się nauczyć trochę asemblerze, powinieneś nauczyć się czegoś podobnego asemblerze 6502 na Commodore 64 (emulowane, oczywiście), lub 68000 na Amidze.

Możesz dowiedzieć się więcej o Commodore 64 tutaj ...

http://thepiratebay.org/torrent/4609238/Tag3-Saal2-Slot16_00--ID2874-the_ultimate_commodore_64_talk-Main

Klasyczna książka, którą musisz znać, to ta opisana tutaj ...

http://reprog.wordpress.com/2010/03/12/programming-books-part-3-programming-the-commodore-64/

Prawdopodobnie możesz znaleźć skan PDF, jeśli się rozejrzysz.

IMO, 6502 jest łatwiejszy niż Z80, a 68000 jest łatwiejszy niż 8086 - bardziej regularne zestawy instrukcji itp.

Ale procesor jest tylko jednym aspektem sprzętu. Ponadto nowoczesny procesor jest ogromnie inną bestią i robi rzeczy, które są przezroczyste nawet z punktu widzenia kompilatorów - na przykład przedstawia wirtualną przestrzeń adresową.

Szczególną zaletą 6502 na C64 jest to, że procesor jest nie tylko prosty, ale także bardzo prosty do zhackowania ze sprzętem. Kiedyś świetnie się bawiłem, grając z chipem muzycznym SID.

Więc - prawdopodobnie jest to cenne ćwiczenie, jeśli nie spędzasz na nim zbyt wiele czasu. Nauczyłem się asemblera 6502 jako mojego drugiego języka, kiedy miałem około 14 lat, zaraz po Commodore Basic. Ale przede wszystkim uzyskuje się ten bardzo prosty działający model, dzięki czemu można dodawać do niego bardziej wyrafinowane pomysły przy minimalnym nieporozumieniu.

Kilka przydatnych rzeczy, których możesz nauczyć się pracując w asemblerze ...

  • Jak działają rejestry procesora.
  • Jak działa adresowanie pamięci, w tym pośrednie.
  • Jak działa stos procesora.
  • Jak działa logika bitowa.
  • Jak CPU kontroluje urządzenia I / O.
  • Jak działają zakłócenia.

Jednym szczególnym powodem, dla którego polecam, jest lepsze zrozumienie sposobu, w jaki proste kroki działają całkowicie deterministycznie, mechanicznie i całkowicie bez inteligencji i zdrowego rozsądku. Zasadniczo przyzwyczajanie się do imperatywnego modelu wykonania w jego najczystszej i najbardziej upartej niewiedzy.

Dokładne pytanie, jak przydatna jest wiedza o większości tych rzeczy, jest jednak trudnym pytaniem.

Jednej rzeczy nie nauczysz się, jak dobrze grać z dziedzicznością pamięci. Te stare maszyny miały w większości prosty model pamięci bez warstw pamięci podręcznej i pamięci wirtualnej. Nie dowiesz się też wiele na temat współbieżności - były to z pewnością sposoby, aby sobie z tym poradzić, ale w większości oznaczały to przerwy. Nie musiałeś się martwić muteksami itp.

Czasami mentalny model tego, jak kiedyś działały te rzeczy lub jak działa asembler, może nawet wprowadzić w błąd. Na przykład myślenie o wskaźniku C jako adresie może prowadzić do nieokreślonych problemów z zachowaniem. Wskaźnik AC jest zwykle implementowany jako liczba całkowita zawierająca adres, ale nie ma gwarancji, że jest to absolutnie prawda. Na przykład na niektórych dziwnych platformach różne wskaźniki mogą wskazywać na różne przestrzenie adresowe. Staje się to ważne, gdy chcesz wykonać arytmetykę lub logikę bitową za pomocą dwóch wskaźników.

Jeśli nie masz jednej z tych dziwacznych platform, możesz nie myśleć, że ci na tym zależy - ale w dzisiejszych czasach kompilatory coraz częściej wykorzystują do optymalizacji zachowanie niezdefiniowane przez standardy.

Tak więc mentalny model architektury systemu może być przydatny, ale nadal ważne jest, aby kodować zgodnie ze specyfikacją języka, a nie hipotetycznym modelem, którego język i platforma mogą nie respektować.

Wreszcie, wiele przydatnych rzeczy z modelu mentalnego pochodzi z poznania, w jaki sposób kompilatory generują kod - a generowanie kodu dla współczesnych języków różni się bardzo od dość trywialnych kompilatorów dostępnych wówczas.

To moja ulubiona książka do tego ...

http://dickgrune.com/Books/MCD_1st_Edition/

Oprócz zagadnień związanych z analizowaniem składni, AST itp., Obejmuje generowanie kodu dla szeregu paradygmatów językowych - imperatywny, OOP, funkcjonalny, logiczny, równoległy i rozproszony - a także do zarządzania pamięcią. Jeśli chcesz wiedzieć, jak działają metody polimorficzne bez zagłębiania się w szczegóły zestawu instrukcji procesora, książka taka jak ta jest twoją przyjaciółką - wkrótce pojawi się nowe wydanie.

Steve314
źródło
Steve - wow. Jestem prawie bez słowa z kompletnością i koncentracją twojej odpowiedzi na moje pytanie. Dziękuję bardzo za poświęcenie czasu na napisanie tego wszystkiego. Zdecydowanie wezmę twoje sugestie.
Bev
1
Sugerowałbym, że asembler PDP-11 jest nieco przyjemniejszy do nauki niż wszystkie inne wymienione. Wszystkie pozostałe uczą o ograniczeniach wymuszonych przez bardziej ograniczone zasoby sprzętowe i / lub przez bardziej ograniczony projekt i przemyślany sprzęt. Coś w rodzaju jednej ze zbyt powszechnej rodziny 8051 uczy, jak naprawdę dziwaczny może być model programowania na tak ograniczonym sprzęcie (w którym na przykład wspomina Steve o różnych przestrzeniach adresowych).
Greg A. Woods,
@Greg - Obawiam się, że nigdy nie grałem z PDP-11. Ani 8051 - Przez jakiś czas pracowałem z osadzonymi, ale korzystałem z układu z rodziny 8096. Po prostu rzuciłem okiem tutaj - ciekawe. Już wcześniej słyszałem o architekturze Harvardu, ale nie miałem pojęcia, że ​​istnieje coś takiego, co jest bardzo popularne i wciąż jest używane.
Steve314,
4

Dwadzieścia lat temu było to ważne, ale nie tak bardzo teraz - istnieje znacznie więcej warstw abstrakcji między oprogramowaniem a nowoczesnym sprzętem.

Warto wiedzieć, jak potrzeba wielu wątków, aby skorzystać z wielu rdzeni lub że użycie większej ilości pamięci niż w systemie jest złą rzeczą, ale poza tym tak naprawdę jej nie potrzebujesz, chyba że Twoim zadaniem jest napisanie tych abstrakcji warstwy.

Reszta twojego pytania sugeruje, że możesz być bardziej zainteresowany kompilatorem niż sprzętem, co jest nieco inne. Możesz natknąć się na przypadki, w których jest to ważne, ale zwykle są to albo trywialne (nieskończona rekurencja nie działa zbyt dobrze), albo rodzaj skrajnych przypadków, w których możesz czuć się dobrze, rozwiązując je, ale prawdopodobnie nigdy nie napotkasz tego samego problemu jeszcze raz.

Tom Clarkson
źródło
Tak, masz rację, bardziej interesuje mnie kompilator. Dziękujemy również za sugestie dotyczące wielu wątków, wielu rdzeni itp. Po prostu poszło do mojego pliku notatek toLearn.
Bev
Wielowątkowość @bev jest łatwa do nauczenia, po prostu nie rób tego, chyba że naprawdę musisz, a nawet nie rób tego. więcej kłopotów niż jest to warte z mojego doświadczenia.
Skeith,
@Skeith - dzięki za wskazówkę. Będę pamiętała.
Bev
4

Bardzo pomaga poznać i zrozumieć abstrakcję przedstawioną przez sprzęt, a trochę ogólnego pojęcia o tym, jak powstaje ta iluzja - ale próba prawdziwego zrozumienia, jak naprawdę działa nowoczesny sprzęt, to ogrom pracy, z której „ prawdopodobnie zobaczą tylko minimalny zwrot.

Jeśli wybaczysz drobną rozrywkę: przypomina mi to coś, co zauważyłem kilka lat temu. Kilkadziesiąt lat temu (do końca lat siedemdziesiątych) większość ludzi uważała, że ​​komputery były o krok od magii - prawie nie podlegały prawom fizyki, zdolne do wszelkiego rodzaju rzeczy, które nie miały większego sensu i tak dalej. W tym czasie spędziłem sporo czasu próbując (przeważnie bezskutecznie) przekonać ludzi, że nie, nie byli magią. Były to naprawdę dość zwyczajne maszyny, które wykonywały ograniczoną liczbę rzeczy bardzo szybko i niezawodnie, ale poza tym były wyjątkowo przyziemne.

W dzisiejszych czasach zmieniło się postrzeganie komputerów przez większość ludzi. Są teraz dość zwyczajni - do tego stopnia, że ​​całkiem sporo zwykłych ludzi ma ich praktyczną wiedzę. Na przykład, jakiś czas temu, kiedy jadłem kolację, widziałem / słyszałem kelnera i kelnerkę podczas ich przerwy, omawiających, co powinna dostać w swoim nowym komputerze. Porady, których udzielał, były całkowicie rozsądne i realistyczne.

Moje spojrzenie na komputery też się zmieniło. Poszedłem do Hot Chips, a wcześniej Forum Mikroprocesorów sięga około połowy lat 90-tych. I zapewne wie więcej na temat sprzętu mikroprocesora niż co najmniej 99% programistów - i wiedząc, co zrobić, powiem tak: oni nie już zwyczajne. Oni mają prawie łamać prawa fizyki. Przeprowadziłem wiele testów na niskim poziomie i mogę to powiedzieć na pewno: przekroczenie iluzji stworzonej przez procesor i przejście do poziomu pokazania, jak naprawdę działa sprzęt, jest często niezwykle trudne. Chciałbym móc zamieścić zdjęcie jednego z naszych ustawień z komputerem ukrytym pod kablami z co najmniej 4 analizatorów logicznych, aby właściwie zmierzyć jeden aspekt tego, jak buforowanie działa na nowoczesnym procesorze (nie wspominając o niektórych naprawdę wybrednych programach, aby upewnić się, że to, co zmierzyliśmy, było dokładnie tym, co robił procesor i nic więcej).

Jerry Coffin
źródło
Jerry - dziękuję za komentarze. Jako EE czuję się bardziej komfortowo z poziomem tranzystora niż z niektórymi wyższymi poziomami abstrakcji. Naprawdę zastanawiam się, co muszę wiedzieć, aby być dobrym programistą w C ++.
Bev
To zdjęcie brzmi interesująco. Dlaczego nie możesz tego opublikować?
Mason Wheeler
@Bev: Naprawdę nie musisz nic wiedzieć na poziomie tranzystora, aby być dobrym programistą. Te abstrakcje istnieją z jakiegoś powodu i prawie zawsze możesz uznać wszystko na poziomie abstrakcji poniżej poziomu kodu maszynowego / zespołu za całkowicie nieistotne i po prostu założyć, że działa.
Mason Wheeler
@MasonWheeler: Wziąłem go tam, gdzie kiedyś pracowałem, ale ponieważ już tam nie pracuję, uzyskanie dostępu do niego byłoby prawdopodobnie nieco trudniejsze (prawdopodobnie nie niemożliwe - rzuciłem na dobrych warunkach, ale mimo to. ..)
Jerry Coffin
1

Różne języki działają na różnych poziomach abstrakcji od sprzętu. C i C ++ są na bardzo niskim poziomie. Z drugiej strony języki skryptowe wymagają mniejszej wiedzy na temat podstawowych szczegółów.

Jednak nadal powiedziałbym, że we wszystkich przypadkach, im więcej wiesz, tym lepiej będziesz programistą. Część programowania polega na jednoczesnym żonglowaniu wieloma poziomami abstrakcji.

Jeśli programujesz w C ++, musisz całkiem dobrze zrozumieć, jak działa nowoczesny procesor, przynajmniej na poziomie abstrakcji, na którym działa kompilator. (Wewnątrz procesora dzieją się rzeczy, które są przezroczyste dla kompilatora).

Scott Whitlock
źródło
Scott - przez „całkiem dobre zrozumienie, jak działa współczesny procesor…” masz na myśli, jak działa logika cyfrowa (np. Jak działają mapy Karnaugh, tabele prawdy i bramki AND / OR / NOR / XOR)? czy masz na myśli, jakie zasoby kompilator wykorzystuje bezpośrednio (tj. rejestry)?
Bev
Wiedza więcej jest dobra. Prawdziwa sztuczka polega jednak na tym, by dowiedzieć się, jakie „więcej” da największy huk za swoje pieniądze. Na przykład znajomość czasów instrukcji nie będzie przydatna, gdy prawie niemożliwe jest przewidzenie, jakich instrukcji będzie używał twój kompilator. Nauczenie się korzystania z profilera prawdopodobnie zapewni znacznie lepszy stosunek kosztów do korzyści.
Steve314,
1
@bev - Nie, nie sądzę, że musisz zejść do poziomu bramy. Jeśli znasz podstawową architekturę (pamięć, magistralę, procesor), w jaki sposób ładuje instrukcję, wykonuje ją, przechowuje wynik itp., Prawdopodobnie nic ci nie jest. Musisz także zrozumieć, w jaki sposób kompilator określa przestrzeń pamięci programu, w tym sposób wykorzystania stosu i sterty.
Scott Whitlock,
@ScottWhitlock - Dzięki - to tylko konkretne rekomendacje, których szukałem.
Bev
0

Chciałbym dodać punkt o ogólnym projekcie języków wyższego poziomu, takich jak C.

Ogólnie rzecz biorąc, myślę, że można bezpiecznie powiedzieć, że takie języki można postrzegać jako implementację abstrakcyjnej maszyny, i tak właśnie sam Dennis Ritchie opisał, jak działa C i jak szczególny projekt abstrakcyjnej maszyny C uczynił z niej bardziej przenośny język. W związku z tym pewne zrozumienie architektury komputera i działania na poziomie maszyny może być niezwykle pomocne w zrozumieniu abstrakcyjnej maszyny języka.

Artykuł DMR Przenośność programów C i systemu UNIX jest pierwszym, jaki pamiętam, aby omówić (abstrakcyjny) model maszyny dla C.

Myślę, że artykuł DMR na temat historii i rozwoju języka C jest również niezwykle przydatny do pokazania, w jaki sposób rzeczywisty sprzęt wpływa na projektowanie języka, i być może jest również przykładem wczesnego projektowania języka programowania: Rozwój języka C

Greg A. Woods
źródło
Ponieważ jesteś tu nowy, wydaje Ci się, że to forum, ale z pewnością nie. Twoje odpowiedzi na pytanie nie powinny być punktem, który dodajesz, należy odesłać do komentarzy, a odpowiedź powinna próbować być wyczerpującą odpowiedzią bezpośrednio na pytanie. To powiedziawszy, że masz rację i jest to cenne w informacjach na temat tematu, być może gdybyś mógł wstawić kilka wierszy w tej odpowiedzi, pytanie bezpośrednio wraz z tym wyjaśnieniem byłoby świetne. Fajne informacje, które tutaj udostępniasz. Witamy w Programistach!
Jimmy Hoffa
komentarze nie są wersjonowane i nie są trwałe, a zatem są bezużyteczne do dodawania do zestawu odpowiedzi. Większość plakatów ma również tendencję do ignorowania użycia komentarzy do aktualizacji swoich odpowiedzi, a większość odpowiedzi nie jest oznaczona jako „wspólnotowa wiki”, dlatego też nie mogą być edytowane przez innych w taki sposób, aby zachować pewne przypisanie kolejnym autorom . Poza tym to konkretne pytanie zapoczątkowało prawdziwą dyskusję i to się podoba lub nie. Tak właśnie wyglądają niektóre z tych rzeczy. Próba zmuszenia każdego wkładu do jednej formy jest główną wadą koncepcji wymiany stosów.
Greg A. Woods,
a tak naprawdę odpowiedziałem, choć domyślnie, na jedno prawdziwe pytanie PO: trzeba mieć wystarczającą wiedzę na temat sprzętu, aby móc modelować maszynę abstrakcyjną jako rdzeń projektu języka.
Greg A. Woods,