Dreaming in Code by Scott Rosenberg (2007)
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
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.graves@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
join the discussion list at
or get the source code at
John Graves Auckland NEW ZEALAND
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Surprisingly, this book has not been mentioned before on Edu-sig if a Google search of the archives is to be believed.
I believe you're correct.
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."
I'd not seen this quote before. I understand his point of course. However, having someone proclaimed a dictator in Business Week saying negative stuff about witchcraft might not be the best PR imaginable. The guy lives in Portland, you'd think he'd know better? Note that wizards seem to get off, i.e. Unix culture embraced the wizard meme (Google for hits), but not witch (hardly any). I tried introducing "FOSS witch" on Diversity (python.org) and appeared to get no takers. Hacker, pirate, wizard, geek, dictator... but not witch. I realize there are male witches (technically) but thought some "subversive word" (like pirate) with a clear slant towards women, might actually be a positive contribution. Just about all the hits on Google are my own uses of this term ("FOSS coven" was another). I think the history here is that both alchemy and witchcraft were proto-sciences and didn't so much die out as transform. They became actual sciences with the spread of literacy and less persecution by religious authorities. Witches were herbalists, practitioners of medicinal arts. Alchemists were metallurgists and chemists. The culture witches lived in believed in curses and spells (as many do today), so countering spells against a client would count as psychotherapy by today's standards. Witches were proto-psychologists. Witchcraft waned in proportion to people no longer taking it seriously, meaning you could no longer be put on trial for its practice, any more than for practicing magic or voodoo -- unless animals were harmed in the process, or you happened to be an economist. :) I'd rather cast the Spanish Inquisition as cathedralist and anti-FOSS, secretive and control freaky: a priesthood (mostly male and hierarchical), looking appropriately klannish in those identity-masking pointy hoods. Witches and wizards, good people of the forest, are more egalitarian and self-organizing, are the open sourcery types trading goods and skills in the free-wheeling bazaar. They're like faculty at Hogwarts, more liberal artsy, more collegial. Just my own bias. OK, back to regularly scheduled programming... Kirby
On 28.03.2010, at 07:54, kirby urner wrote:
I tried introducing "FOSS witch" on Diversity (python.org) and appeared to get no takers.
Hacker, pirate, wizard, geek, dictator... but not witch.
Google for "haecksen". The German word for witch is "Hexe", plural "Hexen". The German pronunciation of "Haeckse" is almost identical to "Hexe". It was created as a play on the word "Hacker" which is masculine in German, the canonical femininum would be "Hackerin" (i.e., 'hacktress'). But "Haeckse" is much more playful and creative so this is how some women in the CCC started to call themselves. Also it sounds decidedly unixy, some old-school hackers still insist the plural of "unix" is "unixen" and the boxes running them are "boxen". Since "witch" nowadays has a generally positive connotation (not the least because of J.K.Rowling's and other's books) it at least elicits a giggle when telling girls about this. In Germany anyway. - Bert -
On Sun, Mar 28, 2010 at 5:36 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
On 28.03.2010, at 07:54, kirby urner wrote:
I tried introducing "FOSS witch" on Diversity (python.org) and appeared to get no takers.
Hacker, pirate, wizard, geek, dictator... but not witch.
Google for "haecksen".
The German word for witch is "Hexe", plural "Hexen". The German pronunciation of "Haeckse" is almost identical to "Hexe". It was created as a play on the word "Hacker" which is masculine in German, the canonical femininum would be "Hackerin" (i.e., 'hacktress'). But "Haeckse" is much more playful and creative so this is how some women in the CCC started to call themselves. Also it sounds decidedly unixy, some old-school hackers still insist the plural of "unix" is "unixen" and the boxes running them are "boxen".
Since "witch" nowadays has a generally positive connotation (not the least because of J.K.Rowling's and other's books) it at least elicits a giggle when telling girls about this. In Germany anyway.
- Bert -
Very cool Bert, and also encouraging. Thx! I'll share with other members of the coven. :) Kirby
participants (4)
-
Bert Freudenberg -
Helene Martin -
John Graves -
kirby urner