Agreed that it's a very entertaining and informative read. I really enjoyed this one and have recommended it to students.
On Sat, Mar 27, 2010 at 6:27 PM, John Graves <john.gra...@aut.ac.nz> wrote: > This book is about the open source, python-based Chandler project ( > http://chandlerproject.org/ last mentioned on Edu-sig in 2006) and, more > broadly, about the art of creating software. > > Here is the website for the book: > http://www.dreamingincode.com/ > > And a Salon interview with the author: > http://www.salon.com/books/int/2007/02/03/leonard/ > > Surprisingly, this book has not been mentioned before on Edu-sig if a Google > search of the archives is to be believed. > > Here are excerpts [and comments on the excerpts] which suggest why it might > be useful to Python-using Educators: > > pg 41 > Torvalds, who is known as Benevolent Dictator for Life of the Linux operating > system, consistently exudes a calm optimism about the long-term prospects for > the movement he symbolizes. "In science," as he explained in a 2004 interview > in Business Week, "the whole system builds on people looking at other > people's results and building on top of them. In witchcraft, somebody had a > small secret and guarded it--but never allowed others to really understand it > and build on it. Traditional software is like witchcraft. In history, > witchcraft just died out. The same will happen in software. When problems get > serious enough, you can't have one person or one company guarding their > secrets. You have to have everybody share in knowledge." > > [Are the principles of open source and the reading of well written code parts > of your curriculum?] > > pg 43 > In the 1962 essay that laid out his plan of research into the augmentation of > human intelligence, Engelbart explained why computer programmers were the > most promising initial target group. ... [He] noted that "successful > achievements can be utilized within the augmentation-research program itself, > to improve the effectiveness of the computer programming activity involved in > studying and developing augmentation systems. The capability of designing, > implementing, and modifying computer programs will be very important to the > rate of research progress." In other words, if NLS [oNLine System] could > help his programmers program better, they'd be able to improve NLS faster. > You'd have a positive feedback loop. You'd be, in the term Engelbart favored, > bootstrapping. > To Engelbart, bootstrapping meant "an improving of the improvement > process." > > pg 98 > "If it takes the typical programmer more than two minutes and twenty-seven > seconds to find something," Constantine wrote, "they will conclude it does > not exist and therefore will reinvent it." > > [How do you teach code reuse and enhancement?] > > pg 127 > There is no reliable relationship between the volume of code produced and the > state of completion of a program, its quality, or its ultimate value to a > user. ... The week that he was asked to fill out the new management form for > the first time, Atkinson had just completed rewriting a portion of the > Quickdraw code, making it more efficient and faster. The new version was > 2000 lines of code shorter than the old one. What to report? He wrote in the > number -2000. > > [What do you teach students to produce -- code or value-to-the-user?] > > pg 149 > In 1990, at the PC Forum gathering of computer industry luminaries, Kapor > first delivered the text of his "Software Design Manifesto." > > No one is speaking for the poor user. ... Perhaps the most important > conceptual move to be taken is to recognize the critical role of design, as a > counterpart to programming, in the creation of computer artifacts. ... > > Reaching back to ancient Rome, Kapor proposed applying to software the > architecture theorist Vitruvius's principles of good design: > > firmness--sound structure, no bugs; > commodity--"A program should be suitable for the purposes for which it was > intended"; > delight--"The experience of using the program should be a pleasurable one." > > [What design principles do you teach? How do they compare?] > > pg 245 > [In "Methods" chapter, discussion of CMM:] > One Humphrey presentation offered these bluntly persuasive bullet points: > - We all work for organizations. > - These organizations require plans. > - Unless you are independently wealthy, you must work to a schedule. > - If you don't make your own schedules, somebody else will. > - Then that person will control your work. > > pg 252 > The meeting found a more virile name for the movement--Agile Software > Development--and produced a manifesto that reads in its entirety: > > We are uncovering better ways of developing software by doing it and > helping others do it. > Through this work we have come to value: > - Individuals and interactions over processes and tools > - Working software over comprehensive documentation > - Customer collaboration over contract negotiation > - Responding to change over following a plan > > [Do you expose students to these ideas?] > > pg 306 > Knuth's faith is distilled in the haiku-like poem by the Danish > poet/scientist/designer Piet Hein that adorns the entryway to his home: > > The road to wisdom?--Well, it's plain > and simple to express: > Err > and err > and err again > but less > and less > and less. > > Literate programming is intended as an antidote to the excruciating fact > that, as Joel Spolsky puts it, "it's harder to read code than to write it. > > Instead of imaging that our main task is to instruct a computer what to > do, let us concentrate rather on explaining to human beings what we want a > computer to do. > > [By implication, if you do not teach literate programming, you teach > "illiterate" programming! ;-) ] > > pg 268 > [Rosenberg's Law] > Software is easy to make, except when you want it to do something new. > [corollary] > The only software that's worth making is software that does something new. > > [see also discussion at http://www.wordyard.com/2007/01/15/rosenbergs-law/ ] > > pg 314 > After spending some time studying Chandler's code base, Eby posted to his > blog a lengthy entry titled "Python Is Not Java." > > ... So, the sad thing is that these poor folks worked much, much harder > than they needed to, in order to produce much more code than they needed to > write, that then performs much more slowly than the equivalent idiomatic > Python would. > > ... > > Pretend that Python is a magic wand that will miraculously do whatever you > want without you having to lift a finger. Ask, "how does Python already > solve my problem?" and "What Python language feature most resembles my > problem?" You will be absolutely astonished at how often it happens that > [the] thing you need is already there in some form. > > [ http://dirtsimple.org/2004/12/python-is-not-java.html ] > > ---- > > I found the book very informative and inspiring--especially in light of > another open source, Python-based project, Open Allure, a voice-and-vision > enabled educational software, which is part of my PhD study of open source > software development. If you are interested in following this project, check > out the short videos at > > http://bit.ly/openallure > > join the discussion list at > > http://bit.ly/openalluregg > > or get the source code at > > http://openallureds.org > > John Graves > Auckland > NEW ZEALAND > > > > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
