[Edu-sig] Dreaming in Code by Scott Rosenberg (2007)

[Helene Martin]

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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>