Hi John, I was just criticizing the book in general, and not from the standpoint of the STEPS project (for one thing, I think STEPS itself has too many goals and details and sophistications to really serve relatively early in a learner's pathway to understanding computing).
And, as I said, I really like the idea of starting with "atoms" and working up to "life" -- for all of us, and not just students -- and it's a good exercise to think about how to do this without (a) having too much material, or (b) weakening deep ideas. The times I've thought about it previously involved choosing a language target carefully and then working backwards to the minimal understandable architecture that would support this. I think this is the big flaw in the organization of TECS. They could just as easily gone for a much higher level, more powerful, more realistic language, and more easily implemented it both from below and from "aside". I'm guessing the authors are more versed in HW than in SW or in programming languages. For example, the simplest better thing they could have done is to implement a Lisp, and then write a compiler and assembler in Lisp (just as the original MIT folks did in the phases from Lisp 1 to 1.5). They could have gone a step further to ISWIM, or the mythical Lisp 2, or the real M-Lisp, or the more interesting Lisp 70. They could have made their basis Meta II, and generated everything from there. Etc. Some previous candidates in the times I've thought about this have been Wirth's (1960's) Euler with a better parsing and microcode scheme, ISWIM (ditto), a somewhat different version of Smalltalk-72, etc. Today, some of Ian's and Alex's minimal bootstraps suggest themselves, not just for STEPS, but also for a very simple atoms-to-life model. The Alto did not have a lot of transistors in it, but was a very fine meta-machine, so one might think about how to posit an even simpler Alto, but that would still have its meta-capabilities. The Mead-Conway "regular architectures" (also developed at PARC) hint strongly about how easy it is to make HW and how best to abstract it. The first RISC chip is also quite nice in this regard (and real, but not nearly as well thought out as the Alto was). So, my criticisms of TECS are mild -- but there's no doubt that it could be done a lot better, and for the sake of the students it should be done a lot better. That being said, I've read at least one other book with similar aims, and all I remember about it was that it was quite a bit worse. Cheers, Alan ________________________________ From: John Zabroski <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Mon, January 3, 2011 8:34:01 AM Subject: Re: [fonc] The Elements of Computing Systems Alan, So if I understand your criticism correctly, Would I be putting words in your mouth to say that what you really don't like about the book is that it isn't what FONC is trying to set out to accomplish? In other words, you don't like it as much as you could because you think you can do better. (Which is fine, I am the same way with a lot of things I read, but when I am learning something for the first time, I don't have such high standards, since I don't have enough material to compare to.) I had not heard of Carver Mead's book before. I just picked it up via an online used books store. Thanks. On Mon, Jan 3, 2011 at 11:05 AM, Alan Kay <[email protected]> wrote: Hi Eric (and all) > >I read this a few years ago and I really wanted to like this book much more >than >I did. > > >I love the basic idea behind it. And I think a really good rendering of the >"from atoms to life" chain of meaning in computing would help many people, >especially students. > >However, it was the way they decided to cut corners (with both HW and SW) that >was really bothersome (and not necessary). For example, their target language >is >really quite weak and also unreliable in many ways, but there was no need for >them to go in a kind of "weak C" direction. With less word and better >techniques >they could get a very strong very high level language directly supported by >the >HW. Similarly, I don't think they had looked at the Mead-Conway book from the >late 70s to get a handle on simple ways to think of hardware organization, or >at Chuck Thacker's Alto architecture from PARC in the 70s to see how a few >thousand gates can really be organized into a powerful computation engine for >emulation, etc. > >Cheers, > >Alan > > > > ________________________________ From: Erik Terpstra <[email protected]> >To: [email protected] >Sent: Mon, January 3, 2011 7:51:02 AM >Subject: [fonc] The Elements of Computing Systems > > >A book called 'The Elements of Computing Systems' [1] describes the >construction >of a very simple computing system including its hardware and software. >You start with a NAND gate and while gradually working through the chapters >you >implement memory, a CPU and later on an assembler, compiler, VM and a very >basic >shell. >All this is implemented in an emulator that is provided on the book's website >[2]. > >I was wondering if there are people (who are familiar with the FONC/STEPS >project) that know this book, and what their ideas are on where the >implementation strategy taken in this book would differ from the >implementation >(of a VERY basic) STEPS like system. >I'd imagine the hardware implementation would not differ very much, but that >the >software would take an entirely different route early on (probably focusing on >an OMeta like implementation as early as possible). > >Any opinions on this would be greatly appreciated. I am quite curious if a >STEPS like strategy would be more efficient, easier or more succinct. > >--Erik > >[1] >http://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/026214087X > >[2] http://www1.idc.ac.il/tecs/ > >P.S.: There is also a video that demonstrates some aspects of TECS: >http://www.youtube.com/watch?v=JtXvUoPx4Qs >P.S.2: You can find some sample chapters from the book here: >http://www1.idc.ac.il/tecs/plan.html > >_______________________________________________ >fonc mailing list >[email protected] >http://vpri.org/mailman/listinfo/fonc > > >_______________________________________________ >fonc mailing list >[email protected] >http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
