-----Original Message----- From: Kirby Urner [mailto:urnerk@qwest.net]
A lot of these lessons about robust software development come from group or community efforts. Some aspects of Python maybe don't much excite you because you're primarily a solo coder (as am I much of the time).
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. Python itself can be thought of as a robust community effort - in C, which itself probably pre-dates/ignores much of the lessons of what is necessary for such effort. Java seems obsessed with these kinds of concerns - which is why I do in fact find coding in it as a solo as a kind of foolishness. OTOH, I find code readability absolutely satisfying, even without an expectation that anyone else will in fact be reading it. Whatever. Art
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. The design patterns movement is the latest chapter in the series, drawing inspiration from that 'pattern language' book beloved by the architects, and followed by a big splash by the Gang of Four (an allusion to recent Chinese political history). O'Reilly's 'Head First Design Patterns' is one of the most pedagogically sophisticated in this tradition to date (I'm still somewhat awed by it, though I've heard others express a wish for still greater content density): http://www.oreilly.com/catalog/hfdesignpat/ We had the structured programming revolution, which tossed out the GOTOs, and the object oriented revolution. Under the hood, we've been moving to virtual machine platforms with their own byte code languages. This paradigm has taken over at Microsoft and places (i.e. .NET). Python is one of these VM languages, as are Java and C# (the latter being system languages, less agile, yet very necessary, as implementation languages for Python itself among other things).
Python itself can be thought of as a robust community effort - in C, which itself probably pre-dates/ignores much of the lessons of what is necessary for such effort. Java seems obsessed with these kinds of concerns - which is why I do in fact find coding in it as a solo as a kind of foolishness.
And now we have IronPython in C#. C is like clay -- it can be anything you want it to be if you're good at it, which Guido and friends are (I'm not -- I enter the picture as an xBase coder, working up the dBase II, III, IV, FoxPro fish ladder (we've always had an interactive 'dot prompt,' which is why Python's >>> seems so natural to us (there're other FoxPro geeks out there, bending a Python framework into a familiar shape (named Dabo), as I learned at Pycon in DC last March [1]))). The object orientation was always there in Python, but user-defined classes were originally 2nd class citizens. Getting them to be top level, unifying types and classes, has been a long haul saga within the Python community. I'm still a bit hazy myself on how to subclass some of the primitive types. Where do you store the value? I appreciated getting a history lesson on Python's origins and early evolution from Guido himself in Sweden, where he talked to a packed upper floor room full of mostly newbies (EuroPython had a friendly newbie track).
OTOH, I find code readability absolutely satisfying, even without an expectation that anyone else will in fact be reading it.
Whatever.
Art
I'm glad to hear it, as I do expect PyGeo code will be eyeballed by many more newbies as time goes on, ready to get their feet wet as strangers in a strange land. Your coding style will be an early influence on these little penguins. One of the challenges I had @ OSCON was how to talk about Elastic Interval Geometry (EIG) as inspired by Kenneth Snelson and others, without being off topic. Because the best open source EIG apps are written in Java (Springie and Fluidiom), and the best closed source offering (Alan's SpringDance) is in Delphi. My solution: write the presentation manager itself in Python, such that at any given moment, even if the slides were showing Java creations, the screen itself would be Python + Pygame driven (I also went out over the Internet to demo the Java applets live, but only for a few minutes). This strategy worked well IMO (plus I got positive feedback from people in the audience who came up to me during the rest of the conference). My code, though somewhat quirky (look at the weird way I pass parameters -- inside a parameters object), isn't especially crash prone, does what it's supposed to do.[2] I too am an influence, and fortunately just one of many (my stuff should be part of a balanced diet). Kirby [1] http://mybizmo.blogspot.com/2005/03/pycon-2005.html [2] http://www.4dsolutions.net/ocn/oscon2005.html
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! Monday, August 22, 2005, 11:08:42 AM, you wrote: KU> There's a long history of coders seeking consensus, but not arriving at any KU> set in stone answers (no carved tablets at the Smithsonian), in part because KU> the backdrop is always shifting, in terms of languages and technologies. KU> The design patterns movement is the latest chapter in the series, drawing KU> inspiration from that 'pattern language' book beloved by the architects, and KU> followed by a big splash by the Gang of Four (an allusion to recent Chinese KU> political history). O'Reilly's 'Head First Design Patterns' is one of the KU> most pedagogically sophisticated in this tradition to date (I'm still KU> somewhat awed by it, though I've heard others express a wish for still KU> greater content density): KU> http://www.oreilly.com/catalog/hfdesignpat/ KU> We had the structured programming revolution, which tossed out the GOTOs, KU> and the object oriented revolution. Under the hood, we've been moving to KU> virtual machine platforms with their own byte code languages. This paradigm KU> has taken over at Microsoft and places (i.e. .NET). Python is one of these KU> VM languages, as are Java and C# (the latter being system languages, less KU> agile, yet very necessary, as implementation languages for Python itself KU> among other things). -- Best regards, Chuck
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 Scott.Daniels@Acm.Org
-----Original Message----- From: Chuck Allison [mailto:chuck@freshsources.com] 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
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:chuck@freshsources.com] 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
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 Scott.Daniels@Acm.Org
-----Original Message----- From: edu-sig-bounces+urnerk=qwest.net@python.org [mailto:edu-sig- bounces+urnerk=qwest.net@python.org] On Behalf Of Chuck Allison Sent: Tuesday, August 23, 2005 6:19 PM To: Kirby Urner Cc: edu-sig@python.org Subject: 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.
Hi Chuck -- I don't have HFDP in front if me, but if it does MVC at all, I can imagine using the Triangle we've been discussing as a model, then adding viewer and controller objects, making the triangle change in some way (controlling it), while displaying (viewing it). Here's some code, which as yet doesn't actually make use of VPython -- but that's where it's going. Note that my viewer expects to work with a 'shape' object, which is supposed to have attributes verts (a dictionary of labeled vertices) and edges (a list of vertex pairs, using those labels). Since my triangle object wasn't written that way, I subclass a Triangle2 as TriAdapter, solely for the purpose of making it behave like a shape. Kirby === # uses code already/recently posted to this list for BaseTriangle class Triangle2(BaseTriangle): """ Model """ @property def coords(self): return {'A':self._pA, 'B':self._pB, 'C':self._pC} def _reset(self): a,b,c = self.a, self.b, self.c # for brevity self.perimeter = a + b + c s = 0.5 * self.perimeter self.area = math.sqrt(s * (s - a)*(s - b)*(s - c)) self.A = math.acos((-a**2 + b**2 + c**2)/(2.0*b*c)) self.B = math.acos(( a**2 - b**2 + c**2)/(2.0*a*c)) self.C = math.acos(( a**2 + b**2 - c**2)/(2.0*a*b)) self._pA = (0.0, 0.0, 0.0) self._pB = (a , 0.0, 0.0) self._pC = ((a**2 + b**2 - c**2)/(2.0*a), math.sqrt((-a+b+c)*(a-b+c)*(a+b-c)*(a+b+c))/(2*a), 0.0) def __mul__(self, scalar): a = self.a * scalar b = self.b * scalar c = self.c * scalar return self.__class__(a,b,c) __rmul__ = __mul__ class TriAdapter(Triangle2): """ Make a triangle work like a Shape, i.e. add edges and verts attributes """ def __init__(self, a,b,c): Triangle2.__init__(self, a,b,c) self.edges = [('A','B'),('B','C'),('C','A')] @property def verts(self): return self.coords class Pulser(object): """ A controller: makes a shape bigger in steps, then smaller, back to original """ def __init__(self, shape, viewer): self.shape = shape self.viewer = viewer def run(self): for i in range(15): self.viewer.display(self.shape) self.shape = self.shape * 1.1 for i in range(16): self.viewer.display(self.shape) self.shape = self.shape * (1/1.1) class Vpyview(object): """ A viewer: view using VPython -- very unfinished """ def display(self, shape): self._showverts(shape.verts) self._showedges(shape.edges) def _showedges(self, edges): # stub method for e in edges: print e def _showverts(self, verts): # stub method for v in verts: print v, verts[v] def main(): """ Main call sequence -- maybe loop through random triangles eventually """ theviewer = Vpyview() theshape = TriAdapter(3,3,3) pulser = Pulser(theshape, theviewer) pulser.run()
Here's some code, which as yet doesn't actually make use of VPython -- but that's where it's going.
And here's where it (the code) went. Very minimal, at this point but enough to get VPython actually doing something with the triangle. A student could start with this code and start adding stuff e.g. make it more colorful, add defaults (e.g. radius), cycle through random triangles in main() -- using a try loop to catch illegals -- and so on. Kirby === class Vpyview(object): """ A viewer: view using VPython """ def __init__(self): self._garbage = [] def display(self, shape): self._garbagecollect() self._showverts(shape.verts) self._showedges(shape.edges, shape.verts) time.sleep(.1) def _garbagecollect(self): for g in self._garbage: g.visible = 0 def _showedges(self, edges, verts): for e in edges: v0 = vector(verts[e[0]]) v1 = vector(verts[e[1]]) edge = cylinder(pos=v0, axis=v1-v0, radius = 0.1) self._garbage.append(edge) def _showverts(self, verts): for v in verts: v0 = vector(verts[v]) sph = sphere(pos=v0, radius=0.1) self._garbage.append(sph) from visual import * import time def main(): """ Main call sequence """ thescene = display(title='MVC Demo', center=(0,0,0), background=(.5, .5, .5)) thescene.autoscale = 0 theviewer = Vpyview() theshape = TriAdapter(3,3,3) pulser = Pulser(theshape, theviewer) pulser.run()
participants (4)
-
Arthur -
Chuck Allison -
Kirby Urner -
Scott David Daniels