[Edu-sig] Design patterns
I guess. Though I can't say I find there to be much consensus out there about what language features truly make for robust software development from group or community efforts. There's a long history of coders seeking consensus, but not arriving at any set in stone answers (no carved tablets at the Smithsonian), in part because the backdrop is always shifting, in terms of languages and technologies. Interesting to read Paul Graham's article The Hundred-Year Language which - as noted in the article heading - was derived from his keynote at PyCon 2003. http://www.paulgraham.com/hundred.html Languages evolve slowly because they're not really technologies. Languages are notation. In his mind, (and I think in yours as well) computer languages are more like mathematical notation than a form of technology. And as such, evolution is slower - not at the pace of the changes in the underlying technology. Though certainly not uninfluenced by those developments. The most important technological development he seems to point to is the increasing raw power and speed of processors, which allow languages to design away from a preoccupation with performance issues. He thinks - though without great confidence in his intuition here - that Java is an example of a language headed down a dead-end evolutionary path. Than so must too be C#. Despite having some understanding that it must be annoying to hear high-fallutin theory from someone at my level in this domain, I persist. And it seems to me that the evolutionary successful language will include in its approach clear and concise constraints on its ambitions. If I am understanding properties mostly correctly, and in fact their reason for being is to allow for a fundamental midstream redesign of a program without alteration of that program's API, I am thinking something to the effect that it is only possible to do the impossible in half-measures, and half-measures are only half-measures and who wants to work in an environment of half-measures. I don't think mathematical notation, for example, includes the concept of the half-measure. Whatever. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Chuck Allison wrote: Since this discussion has swerved a little, I'd like to pose a query. I've been using patterns since 1995 and am teaching a course starting Wednesday (a full semester course) on Design Patterns using the Heads First book. My query: do you have any ideas you might proffer for programming assignments? I'd like to give a handful of programming assignments throughout the semester that aren't as short and cutesy as what's in the book. Any ideas would be greatly appreciated! What subject and to whom? If programming and/or CS, I'd be tempted to give a chain of assignments where the requirements swerve, showing the value of malleability in code design. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
- Original Message - From: Scott David Daniels [EMAIL PROTECTED] If I wait until I have actual users, I can get real statistics on how the use the API. We decouple our work this way. But in my look of it, properties are a solution to one of a nearly infinite set of these kinds of possibilites. And in that sense a half-measure. Certainly many areas will remain where our API and our design are irretrievably coupled. All I can try to do is offer the perspective of of a mid-brow developer, who tries. Again, in the case of the development of PyGeo - and willing to refactor until the cows come home - the solutions to problems seemed to be mostly a process of discovery. When I found a better way to do something than I had before, I knew it was better and I knew why it was better. And Python as a languagfe and as as disclipline seemed more than cooperative as a partner, and guide in the process. Properties being a rare distraction. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
-Original Message- From: Chuck Allison [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:43 PM To: Kirby Urner Cc: 'Arthur'; 'Scott David Daniels'; edu-sig@python.org Subject: Re[2]: [Edu-sig] Design patterns Hello Kirby, Since this discussion has swerved a little, I'd like to pose a query. I've been using patterns since 1995 and am teaching a course starting Wednesday (a full semester course) on Design Patterns using the Heads First book. My query: do you have any ideas you might proffer for programming assignments? I'd like to give a handful of programming assignments throughout the semester that aren't as short and cutesy as what's in the book. Any ideas would be greatly appreciated! Hi Chuck -- You could throw out ideas for big projects that Python has gotten used for: a) air traffic control and b) languages training for the military c) some other example only you know about (like El Fish) (or are you teaching this as a Java class and just lurk with snake charmers for ideas -- like I might do in a Ruby conference full of gem smiths). In case 'a)' there's a backend database to consult, and a Tk canvas object for showing airplanes along their vectors, converging/diverging from airport termini. In case 'b)', Python was glue around the game engine, knitting to a speech recognizer that'd give feedback as to how a soldier/player was doing using Arabic in Iraq (e.g. 'game over' if things were going badly -- like if a cuss word was said). I draw both of these examples from Pycon in March 2005, though I could have chosen other examples from EuroPython or OSCON, also events on my calendar this year. Probably an important design pattern common to both of these applications is MVC (model-view-controller). A key design pattern ideal is loose coupling without losing coupling i.e. you want to stay connected, but you don't want to overdo it, in case you want to recombine the various components down the road. MVC would let us swap in a different database on the back, and only have to teach the model about it, while the controllers and outputted views would go against the same API and use the same markup (or whatever). That being said, I think cutesy, short (even sexy) programs *are* what's needed in an intro design patterns course, since it's the *patterns* that matter, not industrial strength vertical market source code, crufted with 10,001 years of specific knowledge domain content (like the stuff I do for RHDS/MDRC -- clinical data around heart procedures, and tons more pattern language where that came from (not being an MD, I never had to learn much of it)). But I haven't seen your syllabus and don't know where in the curriculum your particular course fits in. I'm simply extrapolating from my own position, and our circumstances may not match (e.g. you probably didn't spend most of the day mixing wood stains and applying them to wood products -- like, welcome to Oregon/SiliconForest). Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
In his mind, (and I think in yours as well) computer languages are more like mathematical notation than a form of technology. And as such, evolution is slower - not at the pace of the changes in the underlying technology. However I'm sometimes in the mood to not draw this line between notation and technology, looking at language as technology, as tools. And yes, different technologies evolve at different rates. Bucky kept saying the lead time from prototype to mainstream was a key variable, and in electronics might be about 3 years, whereas in housing it might be at least 10 if not more. So he figured housing prototypes in the 1940s might pan out in the 1960s, and to some extent they did (and didn't). Plus he kept making prototypes, as did his students (J. Baldwin and Joe Clinton come to mind). Though certainly not uninfluenced by those developments. The most important technological development he seems to point to is the increasing raw power and speed of processors, which allow languages to design away from a preoccupation with performance issues. However it's also important that, given this opportunity for faster physical cycling, per the silicon chip computer, software engineers were able to rise to the occasion and give us VHLLs like Python, i.e. were able to take advantage of those extra fast cycles and yet still make the language parsable and machine friendly enough for a CPU (which is ultimately nothing more than a fast arithmetical/logical unit, no matter how fast it goes). He thinks - though without great confidence in his intuition here - that Java is an example of a language headed down a dead-end evolutionary path. Than so must too be C#. A language has a half life. Big expensive systems that aren't broken don't need to be replaced, only tinkered with, so you have this long aftermarket for language skills, even when the language itself is officially dead. FORTRAN is a good example. At the OSCON/Stonehenge party this year, Jeff Zucker (a Perl saint) and I met up with a FORTRAN guy who to this day works on optimizing FORTRAN compilers, to run more effectively against today's chips. Because lots of big fancy computer models still perform useful service and make heavy use of FORTRAN. Despite having some understanding that it must be annoying to hear high-fallutin theory from someone at my level in this domain, I persist. And it seems to me that the evolutionary successful language will include in its approach clear and concise constraints on its ambitions. So far you haven't said anything I disagree with. Just adding emphasis: software had to meet the integrated chip designers at least half way, and computer languages aim for a layer in a long term archeology that could include working bits for centuries, if not millennia -- just as centuries old math notation still expresses algorithms in useful form today (your original point). If I am understanding properties mostly correctly, and in fact their reason for being is to allow for a fundamental midstream redesign of a program without alteration of that program's API, I am thinking something to the effect that it is only possible to do the impossible in half- measures, and half-measures are only half-measures and who wants to work in an environment of half-measures. In Java, you should probably work out ahead of time if you want to use private variables cloaked in protective getters/setters, so that you might continue fiddling with the guts indefinitely, even as your users experience and enjoy a simple attributes-based API that hardly ever changes (like the front panel on a TV: channel and volume, yet no tubes inside (not even a picture tube these days)). In Python, you have more liberty to wrap what used to be a simple attribute in a property, and so maybe don't have to hard code so many design decisions up front. Java coders may be more likely to practice defensive programming than Python coders and make everything private and method-protected up front. This philosophy is manifest throughout the language (with its private, protected, and public attributes -- whereas in C++ you also have friends [1]). Some say Python is a consenting adults language, with permissions by convention vs. enforced by a nanny compiler (I'm not saying the latter can't be a nice experience also). I don't think mathematical notation, for example, includes the concept of the half-measure. Whatever. Art For me, non-executing math notation needn't be enshrined as the ideal. So much about math involves insulating one's self from having to deal with real world complexity (only to discover it later, one hopes in some manageable form). Computer languages ventured off into the wild west and took on whatever features we needed to do real time accommodation of client wishes. So I'm not nostalgic for the good old days, before we had computer science. I don't pine for a math rules world, wherein more machine
Re: [Edu-sig] Design patterns
-Original Message- From: Kirby Urner [mailto:[EMAIL PROTECTED] They're not here to whine about not being mere math notations as if that would be an improvement. That's one way to attempt to characterize my point - or Graham's point, for that matter. Except that it of course misses the point. And is a bit obnoxious. The usual. My target, if anything, is not Python - but the pressure on it to be more Java and C# like. But more to my point is the fact that I don't expect my programming language to solve the problem of decoupling my API from my code. Because I don't expect it to be a solvable problem. Seems to me to make more sense if my programming language provides the environment for deriving concrete solutions to defined problems. And project management tools (and human beings interacting with human beings) manage phase-in and change. Whatever. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Hello Kirby, Thanks for this good input (you too, Scott). My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html. I like your point about cutesy having its place. I just don't see a way to use what's in HFDP as the basis for a programming assignment, but maybe it will come after a few days. As a professor, I like having my ducks in a row a priori, but that's not happening this first time around. Since I teach 3 upper division courses, I'm just a little nervous about having time to invent sufficient material. I was just hoping someone had had a similar teaching experience I could borrow from. All comments appreciated. Thanks again. Tuesday, August 23, 2005, 5:29:33 PM, you wrote: -Original Message- From: Chuck Allison [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:43 PM To: Kirby Urner Cc: 'Arthur'; 'Scott David Daniels'; edu-sig@python.org Subject: Re[2]: [Edu-sig] Design patterns Hello Kirby, Since this discussion has swerved a little, I'd like to pose a query. I've been using patterns since 1995 and am teaching a course starting Wednesday (a full semester course) on Design Patterns using the Heads First book. My query: do you have any ideas you might proffer for programming assignments? I'd like to give a handful of programming assignments throughout the semester that aren't as short and cutesy as what's in the book. Any ideas would be greatly appreciated! KU Hi Chuck -- KU You could throw out ideas for big projects that Python has gotten used for: KU a) air traffic control and KU b) languages training for the military KU c) some other example only you know about (like El Fish) KU (or are you teaching this as a Java class and just lurk with snake charmers KU for ideas -- like I might do in a Ruby conference full of gem smiths). KU In case 'a)' there's a backend database to consult, and a Tk canvas object KU for showing airplanes along their vectors, converging/diverging from airport KU termini. KU In case 'b)', Python was glue around the game engine, knitting to a speech KU recognizer that'd give feedback as to how a soldier/player was doing using KU Arabic in Iraq (e.g. 'game over' if things were going badly -- like if a KU cuss word was said). KU I draw both of these examples from Pycon in March 2005, though I could have KU chosen other examples from EuroPython or OSCON, also events on my calendar KU this year. KU Probably an important design pattern common to both of these applications is KU MVC (model-view-controller). A key design pattern ideal is loose coupling KU without losing coupling i.e. you want to stay connected, but you don't want KU to overdo it, in case you want to recombine the various components down the KU road. MVC would let us swap in a different database on the back, and only KU have to teach the model about it, while the controllers and outputted views KU would go against the same API and use the same markup (or whatever). KU That being said, I think cutesy, short (even sexy) programs *are* what's KU needed in an intro design patterns course, since it's the *patterns* that KU matter, not industrial strength vertical market source code, crufted with KU 10,001 years of specific knowledge domain content (like the stuff I do for KU RHDS/MDRC -- clinical data around heart procedures, and tons more pattern KU language where that came from (not being an MD, I never had to learn much of KU it)). KU But I haven't seen your syllabus and don't know where in the curriculum your KU particular course fits in. I'm simply extrapolating from my own position, KU and our circumstances may not match (e.g. you probably didn't spend most of KU the day mixing wood stains and applying them to wood products -- like, KU welcome to Oregon/SiliconForest). KU Kirby KU ___ KU Edu-sig mailing list KU Edu-sig@python.org KU http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Arthur wrote: ... more to my point is the fact that I don't expect my programming language to solve the problem of decoupling my API from my code. Because I don't expect it to be a solvable problem. I don't know if I'm beating a dead horse, but I don't claim properties solves the problem of decoupling an API from its current implementation. I do claim it provides another tool to express a properly decoupled API. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Chuck Allison wrote: My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html. One thing I've always wanted to see if the class is small enough: Groups shuffling other group's previous layers, and providing feedback (but not grades) to the original group. It is always a shock the first time you see someone else trying to use code you thought was clear. The reason for no grades is to eliminate the grade race gaming among groups. A good MVC exercise is a fairy chess (e.g. kriegspiel) server and clients. A sample sequence of constraints: (1) single game (2) single game with observers (3) game with observers w/o enough info to cheat by players. (4) multi-game server. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
