Non odio l'uso del linguaggio assembly, dal momento che ne ho scritto alcuni nel mio corso di os. Ma ovviamente, il linguaggio di assemblaggio manca di astrazione, devi prestare più attenzione ai dettagli.
Il linguaggio assembly è davvero essenziale per scrivere TAOCP?
Non usa solo MIXAL, il suo linguaggio assembly per MIX, ma anche MIX, un modello per un computer semplice (come quello usato negli anni sessanta). Questo è un modello per insegnare con il quale è, in una certa misura, indipendente dallo sviluppo nel campo.
Se avesse usato un altro linguaggio di programmazione (quale, a proposito, penseresti sarebbe stato adatto?), ad esempio NPL (linguaggio di programmazione elegante), avrebbe dovuto o abbandonare l'idea di usare MIX o per introdurre un compilatore di un certo linguaggio informatico di scelta (che è una cosa molto più complessa di quella con cui ha a che fare in Vol 1). In questo modo non sarebbe diventato TAOCP ma TAONPLP. Il primo è indipendente da tale scelta e, per questo motivo, senza tempo in un modo in cui pochi libri sulla programmazione saranno mai. Il secondo probabilmente verrebbe dimenticato ...
Inoltre, fintanto che i computer funzionano in linea di principio come fa il suo MIX, è una buona cosa tenerne conto se sei veramente interessato a imparare come lavorare con loro.
A volte i giovani whippersnapper mi stupiscono. Troppo spesso non hai idea che qualcosa sia successo prima di iniziare la scuola. (Ho lo stesso problema: mi ci è voluto molto tempo per capire che 15 anni erano in realtà un tempo molto breve, da un punto di vista adulto .Questo è all'incirca l'intervallo tra Hiroshima e la crisi dei missili a Cuba. Per me, la seconda guerra mondiale è solo storia, ma mio padre ha combattuto in esso, e mia madre era alle medie durante questo.)
TAOCP, vol. 1, "Fundamental Algorithms", 1a edizione, fu stampato per la prima volta nel 1968. Questo è 45 anni fa. Knuth ha iniziato a pianificare la serie molto prima di allora.
Per riferimento: Intel 8086 è apparso per la prima volta nel 1978, dieci anni dopo. Il linguaggio PASCAL apparve per la prima volta nel 1971; il Jensen & Il libro di Wirth, sulla seconda versione della lingua, uscì nel 1974. Lo sviluppo iniziale di C fu 1969-1973: K & R fu pubblicato nel 1978.
Knuth intendeva la serie per coprire il campo. Ha impostato lo stile, ALLORA, per essere utile ai praticanti POI. Non si è mai aspettato che quella serie diventasse letteralmente il lavoro della sua vita, o il suo modo di scrivere per comprendere quello che probabilmente sarà ben più di mezzo secolo quando finirà.
Il linguaggio dell'assemblaggio oggi non è così cruciale come lo era allora, ma è ancora molto più importante di quanto gli esperti di Java / C ++ / Javascript / Python / Perl vorrebbero che tutti credessero.
Ora RIMUOVI IL MIO PRATO!
Knuth discute il suo ragionamento nella prefazione. Citerò solo alcuni frammenti:
...I needed to decide whether to use an algebraic language such as ALGOL or FORTRAN, or to use a machine-oriented language for this purpose. Perhaps many of today's computer experts will disagree with my decision to use a machine-oriented language, but I have become convinced that it was definitely the correct choice, for the following reasons:
- Algebraic languages are more suited to numerical problems than the nonnumerical problems considered here. [ ... ]
- ...By writing in a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality.
- The programs we require are, with few exceptions, all rather short...
- A person who is more than casually interested in computers should be well schooled in machine language...
- Some machine language would be necessary anyway...
Sebbene non lo indichi direttamente, penso che la sua menzione di ALGOL e FORTRAN rimandi ad un altro problema che ha evitato potrebbe essere ancora più importante. Supponiamo che abbia scelto Algol (chiaramente più adatto ai programmi non numerici rispetto a Fortran). Direi che Algol sarebbe probabilmente più estraneo alla maggior parte dei programmatori di oggi rispetto al linguaggio assembly che ha scelto.
Per la terza edizione, ha ridisegnato il MIX per adattarsi meglio ai processori moderni e ha dovuto riscrivere il codice per esso. Comunque, direi che se avesse usato un linguaggio di livello superiore, la riscrittura sarebbe stata sostanzialmente maggiore - e tutte le ragioni che ha dato rimarrebbero pure.
Knuth ha aggiornato anche la sua motivazione :
Why have a machine language?
Many readers are no doubt thinking, ''Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.''
Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books. But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today:
- One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up.
- The programs needed in my books are generally so short that their main points can be grasped easily.
- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.
- Machine language is necessary in any case, as output of many of the software programs I describe.
- Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.) when comparing different schemes.
Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. My books focus on timeless truths.
Therefore I will continue to use English as the high-level language in TAOCP, and I will continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people's books.
The good news is that programming for RISC machines is pleasant and simple, when the RISC machine has a nice clean design. So I need not dwell on arcane, fiddly little details that distract from the main points. In this respect MMIX will be significantly better than MIX.