One other thought: "guard-rail programming." I share his skepticism about tests as a panacea, BUT, automated tests are useful, and I have been able to use them to make changes that would have been much harder to make without good tests. One thing that he does not acknowledge is the source of some of the best test cases/methods one can write: newly discovered defects. Tests do not prove that software in correct, but they can help us avoid repeating mistakes.
________________________________________ From: [email protected] [[email protected]] on behalf of Schwab,Wilhelm K [[email protected]] Sent: Thursday, November 03, 2011 6:36 PM To: [email protected] Subject: Re: [Pharo-project] Simple vs. Easy It is a good talk - thanks for mentioning it here! At several points, I was reminded of Beck's "Lots of little pieces," which is great advice. I have mixed feelings on (what I think he meant??) using undifferentiated collections for holding data. I use dictionaries a lot, and some things really are naturally arrays - no argument there. However, there are times when "points" in some weird cross product space could be represented as arrays, but there are huge benefits from having a class that "understands" the problem-specifics (and proves it via #printOn:). Put another way, one can explore and array of arrays, or an array of objects with named aspects and helpful string representations. The resulting classes then provide natural places to add behavior. Stef, I like your list. I might tweak it just a bit: let's be easy in C integration and simple in UI building. Maybe we can layer an easy tool on top of a simple framework for the latter?? Bill ________________________________________ From: [email protected] [[email protected]] on behalf of Stéphane Ducasse [[email protected]] Sent: Thursday, November 03, 2011 4:39 PM To: [email protected] Subject: Re: [Pharo-project] Simple vs. Easy We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef > Hello, > > I watched a video presentation by Rich Hickey, the creator of Clojure, on > Simple Made Easy. > www.infoq.com/presentations/Simple-Made-Easy > > It is a very interesting video. I don't necessarily agree with everything he > says. But I believe he makes some valuable distinctions between simple and > easy. > > Where are we in Pharo simple? > Where are we easy? > > What can we do to move things from easy to simple? > > I am not qualified to answer his challenge to object oriented languages. But > I feel that Smalltalk is the most functional OO language I've seen. And I > don't necessarily mean functional in the programming methodology sense, but I > don't rule it out either. I don't believe that C++ and Java will provide the > best OO or programming experience. > > Watch the video. > I would love to hear some opinions from the community. > > How can we move Pharo to be a better answer to Simple vs. Easy? > > Thanks. > > Jimmie >
