From kirby.urner at gmail.com Mon Mar 9 02:31:40 2015 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 8 Mar 2015 18:31:40 -0700 Subject: [Edu-sig] Exhibit: Python + POV-Ray (one of my favorite ways to get graphics) Message-ID: """ Author: Kirby Urner, 4D Solutions, Sept. 15 2005 Last modified: March 7, 2015 Version #: 1.7 (c) MIT Licence Developed for Bridges Conference to add graphic to paper Prototype shows two of the six plastic panels held in place by spokes. In the final assembly, spokes are replaced by chains in tension hooked to the six tetrahedron ribs on one end, and to brass fixture inserts in the six panel centers. Other materials and tension schemes apply. """ class Vector: texture = 'T_Chrome_4D' def __init__(self, xyz): self.xyz = xyz def write(self): basic = "cylinder {<0,0,0>, <%s,%s,%s>, 0.1" % self.xyz return "%s %s" % (basic, "texture {%s} no_shadow }" % self.texture) def __repr__(self): return "Vector <%s, %s, %s>" % self.xyz def __mul__(self, scalar): xyz = tuple([scalar * i for i in self.xyz]) return Vector(xyz) def __add__(self, other): xyz = tuple([ i+j for i,j in zip(self.xyz, other.xyz)]) return Vector(xyz) def _get_xyz(self): return '<%s, %s, %s>' % self.xyz def _get_length(self): return pow(sum([i**2 for i in xyz]), 0.5) coords = property(_get_xyz) length = property(_get_length) class Edge(object): texture = 'T_Chrome_4D' def __init__(self, v0, v1): self.v0 = v0 self.v1 = v1 def __repr__(self): return "Edge %s, %s" % (self.v0.coords, self.v1.coords) def write(self): basic = "cylinder {%s, %s, 0.05" % (self.v0.coords, self.v1.coords) return "%s %s" % (basic, "texture {%s} no_shadow }" % self.texture) class Vertex(object): texture = 'T_Chrome_4D' radius = 0.05 def __init__(self, v0): self.v0 = v0 def __repr__(self): return "Sphere %s, radius = %s" % (self.v0.coords, self.radius) def write(self): basic = "sphere {%s, %s" % (self.v0.coords, self.radius) return "%s %s" % (basic, "texture {%s} no_shadow }" % self.texture) class Polyhedron: texture = 'Red' def __init__(self, vertsdict, faces): self.verts = vertsdict self.faces = faces self.edges = self.__get_edges() def __repr__(self): return "Polyhedron: %s vertices, %s edges, %s faces" \ % (len(self.verts), len(self.edges), len(self.faces)) def __get_edges(self): """ take a list of face-tuples and distill all the unique edges, e.g. ((1,2,3)) => ((1,2),(2,3),(3,1)) e.g. icosahedron has 20 faces and 30 unique edges ( = cubocta 24 + tetra's 6 edges to squares per jitterbug) """ uniqueset = set() for f in self.faces: edgetries = zip(f, f[1:]+ (f[0],)) for e in edgetries: e = tuple(sorted(e)) uniqueset.add(e) return tuple(uniqueset) def write(self, name): """ generate the edges and vertices in POV-Ray scene description language """ lines = ['#declare %s = union {' % name] for e in self.edges: edge = Edge( self.verts[e[0]], self.verts[e[1]] ) edge.texture = self.texture lines.append(edge.write()) for v in self.verts.values(): sphere = Vertex(v) sphere.texture = self.texture lines.append(sphere.write()) lines.append("}") lines.append("object {%s}\n" % name) return '\n'.join(lines) def __mul__(self, scalar): newvectors = {} for v in self.verts: newvectors[v] = self.verts[v] * scalar return Polyhedron(newvectors, self.faces) class Header (object): # defaults bgcolor = "color White" lightloc0 = "<300, 300, -1000>" lightloc1 = "<-300, 300, -1000>" lightcolor = "White" @staticmethod def write(): return """ #version 3.6; // 3.7; global_settings{ assumed_gamma 1.0 } #default{ finish{ ambient 0.1 diffuse 0.9 }} #include "colors.inc" #include "textures.inc" #include "woods.inc" #include "glass_old.inc" // sun ------------------------------------------------------------- light_source{<1500,2000,-2500> color White*0.7} light_source{<-500, 500,-2500> color Yellow*0.7} // sky ------------------------------------------------------------- sphere{<0,0,0>,1 hollow texture{pigment{gradient <0,1,0> color_map{[0 color White] //<---2 [0.15 color White] [1.0 color Blue]}} finish {ambient 1 diffuse 0} } scale 10000} //================================================================== #include "colors.inc" #include "metals.inc" #include "glass.inc" """ class Camera: # defaults look_at = 0 location = '<0, .1, -25>' @staticmethod def write(): return """ camera { location %(location)s look_at %(look_at)s } """ % Camera.__dict__ def buildicosa(): """ Build an icosahedron from three mutually perpendicular golden rectangles """ phi = (1 + pow(5,0.5))/2.0 verts = {# 2*phi x 2 rectangle in XZ 1:Vector((-phi, 0, -1)), 2:Vector((-phi, 0, 1)), 3:Vector(( phi, 0, 1)), 4:Vector(( phi, 0, -1)), # 2*phi x 2 rectange in XY 5:Vector(( -1, phi, 0)), 6:Vector(( 1, phi, 0)), 7:Vector(( 1, -phi, 0)), 8:Vector(( -1, -phi, 0)), # 2*phi x 2 rectange in YZ 9:Vector(( 0, 1, phi)), 10:Vector(( 0, -1, phi)), 11:Vector(( 0, -1, -phi)), 12:Vector(( 0, 1, -phi))} faces = ((5,6,9),(5,9,2),(5,2,1),(5,1,12),(5,12,6), (1,11,12),(11,12,4),(12,4,6),(4,6,3),(6,3,9), (3,9,10),(9,10,2),(10,2,8),(2,8,1),(8,1,11), (7,11,4),(7,4,3),(7,3,10),(7,10,8),(7,8,11)) return verts, faces rt2 = pow(2, 1/2) def build_cube(): """ The hexahedron panels need no glue to adhere thanks to beveling and inward pull of the six chains. """ verts = {# octants left of Z plane 1:Vector((-rt2, -rt2, rt2)), 2:Vector((-rt2, -rt2, -rt2)), 3:Vector((-rt2, rt2, -rt2)), 4:Vector((-rt2, rt2, rt2)), # octants right of Z plane 5:Vector(( rt2, -rt2, rt2)), 6:Vector(( rt2, -rt2, -rt2)), 7:Vector(( rt2, rt2, -rt2)), 8:Vector(( rt2, rt2, rt2))} faces = ((1,2,3,4), (4,8,7,3), (8,5,6,7), (1,2,6,5), (2,3,7,6), (1,4,8,5)) return verts, faces def build_tetrahedron(): verts = {# octants left of Z plane 2:Vector((-rt2, -rt2, -rt2)), 4:Vector((-rt2, rt2, rt2)), # octants right of Z plane 5:Vector(( rt2, -rt2, rt2)), 7:Vector(( rt2, rt2, -rt2))} faces = ((4,5,2),(4,5,7),(2,7,5),(2,7,4)) return verts, faces def write_boxes(name): defines = "#declare Face = box{{ < -{0},-{0},-{0}>, <{0},{0},-{0}> texture{{ T_Ruby_Glass }} }}\n".format(rt2) defines += "object{Face}\n" defines += "object{Face rotate <0, 180, 0>}\n" return defines def build_spokes(): """ to be replaced with chains, springs, or wires / ropes with turnbuckle adjustment """ scalar = 0.25 verts = { 'A0' : Vector((-rt2, 0, 0)), 'B0' : Vector(( 0, -rt2, 0)), 'C0' : Vector(( 0, 0, -rt2)), 'D0' : Vector(( rt2, 0, 0)), 'E0' : Vector(( 0, rt2, 0)), 'F0' : Vector(( 0, 0, rt2)), 'A1' : Vector((-rt2, 0, 0)) * scalar, 'B1' : Vector(( 0, -rt2, 0)) * scalar, 'C1' : Vector(( 0, 0, -rt2)) * scalar, 'D1' : Vector(( rt2, 0, 0)) * scalar, 'E1' : Vector(( 0, rt2, 0)) * scalar, 'F1' : Vector(( 0, 0, rt2)) * scalar } faces = (('A0', 'A1'), ('B0', 'B1'), ('C0', 'C1'),('D0', 'D1'),('E0','E1'),('F0','F1')) return verts, faces def main(): cube = Polyhedron(*build_cube()) tetra = Polyhedron(*build_tetrahedron()) * 0.25 spokes = Polyhedron(*build_spokes()) # overwriting defaults: cube.texture = 'T_Wood33' tetra.texture = 'T_Silver_4D' spokes.texture = 'T_Brass_4D' Header.bgcolor = 'Gray20' Header.lightloc1 = '<0, 0, 0>' Camera.location = '<2, 4, -3>' f = open('bridges.pov','w') print(Header.write(), file = f) print(Camera.write(), file = f) print(cube.write("duo_tet"), file=f) # shapes need a name print(tetra.write("tet"), file=f) # shapes need a name print(spokes.write("spokes"), file=f) # shapes need a name print(write_boxes("boxes"), file=f) # shapes need a name f.close() # just to be neat & tidy if __name__ == '__main__': main() -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Mar 9 03:43:15 2015 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 8 Mar 2015 19:43:15 -0700 Subject: [Edu-sig] Exhibit: Python + POV-Ray (one of my favorite ways to get graphics) In-Reply-To: References: Message-ID: On Sun, Mar 8, 2015 at 6:31 PM, kirby urner wrote: > """ > Author: Kirby Urner, 4D Solutions, Sept. 15 2005 > Last modified: March 7, 2015 > Version #: 1.7 > (c) MIT Licence > > Developed for Bridges Conference to add graphic to paper > > Here's a link to the rendered graphic should you go to the trouble to run the .pov file output by the Python script above: https://www.flickr.com/photos/kirbyurner/16140315443/ Running POSIX, so it looks like this to render the above picture $ povray +H768 +W1024 +Q9 +A0.3 bridges.pov Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Mar 12 17:53:02 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 12 Mar 2015 16:53:02 +0000 Subject: [Edu-sig] BBC MicroBit Message-ID: <5501C46E.7080900@ntoll.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Today the BBC announced the MicroBit (part designed by PSF fellow Michael Sparks) - http://www.bbc.co.uk/news/technology-31834927. About 1 million of these small programmable devices will be given away to 11-12 year olds starting their secondary education at the start of the UK's next academic year in September. Python is one of the three languages that work with the device. The PSF is involved in helping to generate community sourced Python resources for the project and we hope the MicroBit will be a big part of PyconUK's education track (taking place at the end of September). In addition to the BBC article above, the Guardian gives a good summary and mentions the PSF here: http://www.theguardian.com/technology/2015/mar/12/bbc-micro-bit-raspberry-pi I have an alpha-version of the device sitting on my desk and my impression is that kids will have a *lot* of fun. Think Pythonic blinkenlights, buttons, bluetooth and IO. Yay! Best wishes, Nicholas. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVAcRuAAoJEP0qBPaYQbb6kB0H/3UA7NGgdHOYQ8Xe0UHcA+Kg f6eyl9dMALcolbKBlbNROhDkoBosY1AmzNQ8HgcoWXpuFTXvREL67/KDk3WNs09s /52hDLqug0zgeIclYbT61OuJZnmLiSTh3bjEB6nXZFhXlPuMLDvSXojryOQEnQwh D/M5nees9VoVzWcuamrTEQ6ug1PDGykIehVMamHaJ8/RuGglcBvygrKtm2KvYK0M Sb3nhvuJC+Yjao2YuKl+AmgHQUAAV61QYMDgYDxqQX/eKkF9eId6NqeWaxjpULbf NOHe+LKK+AuAwaJoZiWQaKDG/uuOcJxiGmbzqI8lgPn2ALoZyEnDM+7E6mkegg8= =NmJM -----END PGP SIGNATURE----- From ntoll at ntoll.org Thu Mar 12 18:47:46 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 12 Mar 2015 17:47:46 +0000 Subject: [Edu-sig] [PSF-Members] BBC MicroBit In-Reply-To: References: <5501C46E.7080900@ntoll.org> Message-ID: <5501D142.6050303@ntoll.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Luciano, That'd probably be me and Michael (cc'd) in the first instance. I'm acting as PSF person on the ground interacting with the BBC. Michael was/is involved in writing the Python compiler and other technical aspects of the device. I will certainly pass on your questions to the people I know at the BBC and cc you in so we both get their reply. Best wishes, Nicholas. On 12/03/15 17:32, Luciano Ramalho wrote: > Hi, Nicholas, thanks for sharing such exciting news! > > I am a teacher and leader of the Pingo project [1], a > multi-platform Python API that provides uniform access to GPIO pins > in Raspberry Pi, Intel Galileo, pcDuino, UDOO and similar SBCs. > > [1] http://www.pingo.io/docs/ > > I and the Pingo team would love to be involved in helping Python > thrive on the MicroBit. Who should we contact to learn about > Python support in the MicroBit and to get our hands on a MicroBit > board? > > Cheers! > > Luciano -- author of Fluent Python (O'Reilly, 2014) > http://shop.oreilly.com/product/0636920032519.do > > > On Thu, Mar 12, 2015 at 1:53 PM, Nicholas H.Tollervey > wrote: Hi, > > Today the BBC announced the MicroBit (part designed by PSF fellow > Michael Sparks) - http://www.bbc.co.uk/news/technology-31834927. > > About 1 million of these small programmable devices will be given > away to 11-12 year olds starting their secondary education at the > start of the UK's next academic year in September. > > Python is one of the three languages that work with the device. > > The PSF is involved in helping to generate community sourced > Python resources for the project and we hope the MicroBit will be a > big part of PyconUK's education track (taking place at the end of > September). > > In addition to the BBC article above, the Guardian gives a good > summary and mentions the PSF here: > > http://www.theguardian.com/technology/2015/mar/12/bbc-micro-bit-raspberry-pi > > I have an alpha-version of the device sitting on my desk and my > impression is that kids will have a *lot* of fun. Think Pythonic > blinkenlights, buttons, bluetooth and IO. > > Yay! > > Best wishes, > > Nicholas. >> _______________________________________________ PSF-Members >> mailing list PSF-Members at python.org >> https://mail.python.org/mailman/listinfo/psf-members PSF home >> page (http://www.python.org/psf/) PSF membership FAQ >> (http://www.python.org/psf/membership/) PSF members' wiki >> (http://wiki.python.org/psf/) > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVAdFCAAoJEP0qBPaYQbb6E3IIAJuTzbshGfvWin245UREN9yA qKsG4KbZFLQAeTcwaXur4xS/dX3AIX6NshpxxJrHWU7k9ua6YSUV2bGekk+uXin2 IbpYZX9a8pavkTFdEiteSEBFj05XOLeBvY64DEU7Srwtj629voC98SU7PvgxYLVf VtvIhFPAeUWOeXY8VJ4y8H6zoMBmhlFazrOo4fJd2M0NUVDsRj3WqSq6gLa5+QM0 wruowtli6divVyIGfk/MaPtwN1w3MXWqX8F4XbV8Z/JIkTAGw3ULSmK0hMz4n2BQ 6khrv/Fv7VLUjJdF4TXTYlCInCqGPbOqUpNqaATF6yzI4azRnI51cx9qS42us5I= =Co2L -----END PGP SIGNATURE----- From jurgis.pralgauskis at gmail.com Fri Mar 13 12:52:35 2015 From: jurgis.pralgauskis at gmail.com (Jurgis Pralgauskis) Date: Fri, 13 Mar 2015 13:52:35 +0200 Subject: [Edu-sig] turtle coordinates: Y increase downards - as in most graphics API? Message-ID: Hi, usually in computer graphics Y is counted to increase downwards. I casn do it with: setworldcoordinates(0, 400, 600, 0) but then, "right(..)" turns to the left :/ I could swap: right, left = left, right but on errror I get a bit misleading message >>> right() Traceback (most recent call last): File "", line 1, in right() TypeError: left() takes exactly 1 argument (0 given) I thought to make this hack for kids, so better clearer error msgs... Any Ideas? Thanks :) -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt -------------- next part -------------- An HTML attachment was scrubbed... URL: From macquigg at ece.arizona.edu Fri Mar 13 15:33:24 2015 From: macquigg at ece.arizona.edu (David MacQuigg) Date: Fri, 13 Mar 2015 07:33:24 -0700 Subject: [Edu-sig] ACM article on Python Message-ID: The latest issue of Communications of the ACM (March 2015) has an article titled "Python for Beginners" with a few points that surprised me. The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. I read the article carefully, looking for substantive comparisons, and found only more baffling, vague statements without enough definition or specificity to reach any understanding. What does it mean that Java is more "industrial strength"? I would say Java is a more "industrial" language, but that is not a compliment. The biggest problem is calling Python a "scripting language". Any language can do scripting, and Python is particularly good at it, but this label makes me think of shell scripting (e.g. tcsh, bash, and all the variants of these special-purpose "job control" languages), not a modern, object-oriented, full-feature language like Python. Another problem is quoting a Python advocate on the productivity advantage of Python (2 man-months vs 24). Wild statements make prospective users walk away without further investigation. I tell my faculty friends it is 2 to 1 over an expert's productivity in Java. I might even quote Bruce Eckel's estimate, 5 to 1, but only to back up my own more conservative estimate. Until now, I've never seen 12 to 1. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org). I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. When I first started using Python, I was astonished to learn that it was not derived from Java. See codingbat.com for many one-to-one comparisons of various code snippets. See Goldwasser's "Object Oriented Programming in Python" for an excellent transition to either Java or C++. This article was disappointing and superficial. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.roberge at gmail.com Fri Mar 13 16:48:18 2015 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 13 Mar 2015 12:48:18 -0300 Subject: [Edu-sig] turtle coordinates: Y increase downards - as in most graphics API? In-Reply-To: References: Message-ID: On Fri, Mar 13, 2015 at 8:52 AM, Jurgis Pralgauskis < jurgis.pralgauskis at gmail.com> wrote: > Hi, > > usually in computer graphics Y is counted to increase downwards. > I casn do it with: setworldcoordinates(0, 400, 600, 0) > > but then, "right(..)" turns to the left :/ > > > I could swap: > right, left = left, right > > but on errror I get a bit misleading message > > >>> right() > Traceback (most recent call last): > File "", line 1, in > right() > TypeError: left() takes exactly 1 argument (0 given) > > I thought to make this hack for kids, so better clearer error msgs... > > Any Ideas? > http://bugs.python.org/issue23660 (includes a proposed "permanent" fix). Andr? > Thanks :) > -- > Jurgis Pralgauskis > tel: 8-616 77613; > Don't worry, be happy and make things better ;) > http://galvosukykla.lt > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > https://mail.python.org/mailman/listinfo/edu-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jurgis.pralgauskis at gmail.com Fri Mar 13 21:13:32 2015 From: jurgis.pralgauskis at gmail.com (Jurgis Pralgauskis) Date: Fri, 13 Mar 2015 22:13:32 +0200 Subject: [Edu-sig] turtle coordinates: Y increase downards - as in most graphics API? In-Reply-To: References: Message-ID: Thanks, would be even better, if there were possibility to swich orientation with mode(...) https://docs.python.org/3/library/turtle.html#turtle.mode don't know how to call this mode, maybe 'crt_style' or so? now there are 'standard', 'logo', or custom 'world' On Fri, Mar 13, 2015 at 5:48 PM, Andre Roberge wrote: > > > On Fri, Mar 13, 2015 at 8:52 AM, Jurgis Pralgauskis < > jurgis.pralgauskis at gmail.com> wrote: > >> Hi, >> >> usually in computer graphics Y is counted to increase downwards. >> I casn do it with: setworldcoordinates(0, 400, 600, 0) >> >> but then, "right(..)" turns to the left :/ >> >> >> I could swap: >> right, left = left, right >> >> but on errror I get a bit misleading message >> >> >>> right() >> Traceback (most recent call last): >> File "", line 1, in >> right() >> TypeError: left() takes exactly 1 argument (0 given) >> >> I thought to make this hack for kids, so better clearer error msgs... >> > >> Any Ideas? >> > > http://bugs.python.org/issue23660 (includes a proposed "permanent" fix). > > Andr? > > > >> Thanks :) >> -- >> Jurgis Pralgauskis >> tel: 8-616 77613; >> Don't worry, be happy and make things better ;) >> http://galvosukykla.lt >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig at python.org >> https://mail.python.org/mailman/listinfo/edu-sig >> >> > -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.engelberg at gmail.com Sat Mar 14 22:27:15 2015 From: mark.engelberg at gmail.com (Mark Engelberg) Date: Sat, 14 Mar 2015 14:27:15 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg wrote: > The first thing that got my attention was the banner text "Choosing Python > is the modern equivalent of the old adage 'nobody ever got fired for > choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just > wanting to run with the herd, the choice would be Java, not Python. The > only clarification I can find is in the conclusion of the article where we > learn that Python is "blandly conventional", just the latest crest in the > "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is > not mentioned anywhere. > Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": > 1) Creating non-trivial data structures is onerous. > 2) Limited support for testing. > 3) Lack of static types. > 4) Difficult transition to other languages because the syntax is quite > different. > > Show me some real-world examples of a data structure or test setup I can't > do better in Python. Python's doctest is an excellent methodology for > teaching Test-Driven Design, or even just teaching basic Python (see > pykata.org). > I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. > I understand the complaint about data types, but I would not give up the > advantages of dynamic typing for the few projects where I really need the > efficiency of static types. Write first in Python, then insert some C code > where testing shows that it is actually needed. > I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. -------------- next part -------------- An HTML attachment was scrubbed... URL: From macquigg at ece.arizona.edu Sun Mar 15 18:40:48 2015 From: macquigg at ece.arizona.edu (David MacQuigg) Date: Sun, 15 Mar 2015 10:40:48 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: Mark, thanks for the excellent reply on this topic. I was not aware of Pyret, and this is really opening my eyes. It has been a few years since I thought about the next step after Python. Ruby didn't add anything fundamentally better. On Sat, Mar 14, 2015 at 2:27 PM, Mark Engelberg wrote: > On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg > wrote: > >> The first thing that got my attention was the banner text "Choosing >> Python is the modern equivalent of the old adage 'nobody ever got fired for >> choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just >> wanting to run with the herd, the choice would be Java, not Python. The >> only clarification I can find is in the conclusion of the article where we >> learn that Python is "blandly conventional", just the latest crest in the >> "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is >> not mentioned anywhere. >> > > Remember, this article is specifically about language choices for > programming education. I agree that Java is still the default choice for a > risk-averse bureaucrat in industry, but in education, Python has become the > most popular, default choice (that's sort of the whole point of the > article). In industry, many managers don't feel the need to look beyond > Java to find more compelling options (even those that might boost > productivity); similarly, at this point, many educators don't feel the need > to look beyond Python to see if there are more compelling options (even > those that might provide a better educational experience). > I wonder if there might be a significant difference between the top schools and all the rest. Faculty at schools like Caltech and MIT might be more willing to break with tradition, more likely to favor teaching fundamentals over training for industry. So Python appears to be most popular in the top schools surveyed for the article, but book sales still show Java to be tops. That's what I think the author's point is about Python being "blandly > conventional". There's no reason to think that Python is the pinnacle of > educational languages. It wasn't designed to be an educational language, > so it should be possible to do better. But it happens to be a pretty good > choice for education, good enough that many people have stopped looking for > better. > I used to think we were on a merry-go-round with a new language every ten years (starting with FORTRAN). Now I see it as a convergence, with Python being very close to the optimum. There are certain fundamental methodologies in computing, and Python implements those methodologies very well. Languages like Ruby, Prothon, now Pyret offer platforms to test new ideas that may one day be brought into Python. Ruby isn't mentioned because it never made significant waves in the > educational community. Remember, the article is just about educational > language choices, not fashionable languages in general. > > The bulk of the article is discussion of Python's "weaknesses": >> 1) Creating non-trivial data structures is onerous. >> 2) Limited support for testing. >> 3) Lack of static types. >> 4) Difficult transition to other languages because the syntax is quite >> different. >> >> Show me some real-world examples of a data structure or test setup I >> can't do better in Python. Python's doctest is an excellent methodology >> for teaching Test-Driven Design, or even just teaching basic Python (see >> pykata.org). >> > > I think the best way to understand these criticisms is to take a look at > the language Pyret (pyret.org), a language that is being developed by > Shriram Krishnamurthi (one of the educators quoted in the article) as an > answer to the problems he sees with Python as an educational language. > > Excellent website!! I can see some serious thought going into this new development. > In Python you have a couple options to build structured data. You can use > the object system, but that's a little heavyweight and clunky for > beginners. You can just use dictionaries with the relevant entries, but > beginners often don't have the discipline to mentally keep track of many > different types of objects that are all dictionaries with different > combinations of entries. This gets especially problematic when you get to > recursive data structures like binary trees. It's pretty tough to teach > this well in Python with dictionaries, so teaching this usually gets > delayed until the object system has been taught, and then all your > functionality that operates on the trees are generally written as methods > split between the branch and leaf classes. This is tough for students > because the code for a given function isn't all in one place, it is spread > out among the two different types of classes. Contrast this with Pyret's > approach to structured data and recursive data structures. > I'm not convinced, but I'll let someone else address the issue of comparing data structures. > As far as testing goes, Python's biggest limitation is that structured > data created with dictionaries or objects are mutable data structures. It > is fundamentally more difficult to test mutable data structures because you > can't use a built-in notion of structural equality. So all tests must be > in the form of setting up an object, calling functions/methods which mutate > it, and then testing various properties of the mutated object. This is > onerous for beginners, and very hard to get them to do this with any kind > of discipline. Testing is radically more simple in languages that offer a > rich set of immutable data structures and an easy way to create new > immutable data structures that automatically come with a structural > equality comparison. So it's easier to teach a "tests first" approach by > starting with immutable data structures and moving to mutable data > structures after students are more mature in their programming > experiences. Doctests are great for regression testing, e.g., copying and > pasting an interactive transcript into the actual code, but are not very > easy for students to write the tests ahead of writing their code, > especially for complex data structures or testing that certain errors are > raised -- it is hard to figure out ahead of time how that kind of stuff is > going to print. > We need good, real-world examples to nail this down. The example on the Pyret website: check: empty.first raises "not-found" [list: 1,2,3,4,5].first is 1 [list: 2,4,6,8].first is 2 end shows a comparison with Python's clunky unittest. Doctest is much better for teaching than unittest: def first(lst): '''Returns the first element of a list >>> first([1,2,3,4,5]) is 1 True >>> first([2,4,6,8]) is 2 True >>> first([]) Traceback (most recent call last): ... IndexError: list index out of range ''' return lst[0] The Pyret syntax is less verbose, but as you pointed out, the Python is just a snip from an interactive session pasted into the docstring. A student can experiment easily getting a command to work in the interpreter, then just paste it into his final code. I have to disagree about the difficulty of writing tests first. Even in cases where the exact output cannot be predicted (e.g. a memory address) the doctest module allows those parts of the output to be ignored. Notice in the above example, we have ignored all the cruft in the traceback response. > >> I understand the complaint about data types, but I would not give up the >> advantages of dynamic typing for the few projects where I really need the >> efficiency of static types. Write first in Python, then insert some C code >> where testing shows that it is actually needed. >> > > I vastly prefer dynamic typing over static typing in my own code. But > this is about education. We have a responsibility to teach students both, > so a language that lets you gradually transition from dynamic typing to > static typing is preferable (in education) to one that doesn't. > I forgot to mention the module "numpy", which doesn't even require C to teach the benefits of static typing. Have the students sort a huge list of integers, then compare the speed using a static array of integers. This isn't about bashing Python; we all recognize that Python is one of the > more compelling alternatives right now in programming education. But let's > not settle for "good enough". There's value to diagnosing the weaknesses > of Python so we can continue to build and look for even better options. > Let's nail down what those weaknesses really are. So many faculty just repeat what they have heard, and this article may be doing the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Mar 16 01:16:47 2015 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 15 Mar 2015 17:16:47 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": > 1) Creating non-trivial data structures is onerous. > 2) Limited support for testing. > 3) Lack of static types. > 4) Difficult transition to other languages because the syntax is quite > different. > Show me some real-world examples of a data structure or test setup I can't > do better in Python. Python's doctest is an excellent methodology for > teaching Test-Driven Design, or even just teaching basic Python (see > pykata.org). > I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. Shiriam Krishnamurti & Co. have a long history of being bitter about Python's success and vocal about it's perceived shortcomings. I suppose it makes sense that the ACM might be getting some input from that corner, which has also given us PLT Scheme and Racket before Pyret. 'Nature" also had an article on Python recently and pointed out that one of Python's chief advantages is the ecosystem to which it gives access, as a controller language. There's no reason to avoid "teaching languages" such as Racket, Squeak (Process?), Pyret and so on, but I do note they tend to have a shorter half life than languages used widely in industry and they do not open as many doors to 3rd party assets. I wouldn't give up on on Ruby making greater inroads in education, just maybe not among English-speakers as much. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurner at oreillyschool.com Tue Mar 17 22:11:35 2015 From: kurner at oreillyschool.com (Kirby Urner) Date: Tue, 17 Mar 2015 14:11:35 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: Checking the edu-sig archive, looks like indentation doesn't show this paragraph was quoted by me not written by me: """ I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. """ Just thought I'd make that clearer. Email clients and what shows up archivally are sometimes different. https://mail.python.org/pipermail/edu-sig/2015-March/011213.html In addition, I'm continuing to explore where in STEM the kind of curriculum writing we need best fits, pre-college. Example post on that theme: http://mathforum.org/kb/thread.jspa?messageID=9724150 Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.engelberg at gmail.com Thu Mar 19 08:59:24 2015 From: mark.engelberg at gmail.com (Mark Engelberg) Date: Thu, 19 Mar 2015 00:59:24 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: Kirby, have you ever looked at mathpiper? (http://www.mathpiper.org/) I know you have a strong interest in fusing math explorations with programming, so it seems like something that would be right up your alley -- sort of an accessible Mathematica intended for education. The docs section also contains a couple e-textbooks that weave in a lot of mathematics examples into the programming instruction ( http://www.mathpiper.org/documentation-1) Certainly one of the more attractive aspects of Python is that it is both relatively-easy-to-learn and relatively-useful-in-the-real-world. But there's definitely a school of thought that *no* language used in industry is optimal for education, that the aims of industry and education are too incompatible for one language to rule for both purposes. It's definitely an interesting debate. I feel fortunate that I work with young enough kids that I feel little pressure to teach them something with immediate marketable value. This gives me the freedom to experiment with many different languages; I've found that I rather like teaching ones expressly designed for education, but Python remains one of my favorite educational options of the popular, mainstream languages. For me, the thing that has made me lose some enthusiasm for Python was not even mentioned in the article. For me, the biggest downside is that the language, with its Global Interpreter Lock, lacks a clean solution to teaching concurrency. IMHO, concurrency has become a vital issue, and requires a somewhat different way of thinking about problems. To create the next generation of exceptional programmers, I believe we need to introduce models of concurrent programming much earlier in the curriculum. Almost every recent programming language places a huge emphasis on concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but none of those are particularly welcoming to beginner programmers. So I'd love to see more educational languages that feature concurrency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Thu Mar 19 15:38:39 2015 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 19 Mar 2015 07:38:39 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 12:59 AM, Mark Engelberg wrote: > Kirby, have you ever looked at mathpiper? (http://www.mathpiper.org/) I > know you have a strong interest in fusing math explorations with > programming, so it seems like something that would be right up your alley > -- sort of an accessible Mathematica intended for education. The docs > section also contains a couple e-textbooks that weave in a lot of > mathematics examples into the programming instruction ( > http://www.mathpiper.org/documentation-1) > Thanks Mark, perusing the book / language now. Rings a bell. Yes: https://mail.python.org/pipermail/edu-sig/2010-December/010148.html Having an interactive console is key I think, so you may use the interpreter as a calculator. All the languages we're discussing are like that, including: ISETL (cited by Tim Peters early on), J, APL (both Iverson & Co.), and Mathpiper here (and Wolfram's Mathematica of course, and Guido's Python, and Pyret). REPL is king. [1] Logo was of course a huge pioneer in adding graphical / robot output really early. Logo had just the one "context turtle" e.g. FD 10 meant the one turtle. OO makes it easy to incarnate many such animals, each with its own state. Some schools of though decry "internal state" but I notice that we have it in the real world and value that feature. I've never been a "one language uber-alles" kind of guy in that I always encourage exposure to multiple languages, at least two that are different enough to provide real contrasts. I'm not eager for everyone to "agree on one language" for all purposes, though "business English" does serve as a kind of global esperanto in some dimensions. That doesn't mean it should take over in higher level thought. Sure, one language might be "front burner" compared to another in one's studies. Python + J (jsoftware.com) has been a combo I've often recommended. The LEX Institute approach ("Who is Fourier?") to learning human languages has been influential (better to tackle many over just one, because of the synergies involved). My first exposure to programming in university, no counting high school hours spent with an HP-65 programmable calculator as (a) eclectic and (b) pre-Python. Our intro course was more of a survey including: PL/1, Snobol, Assembler, APL, LISP. Obviously we were not to become masters of any, however letting the contrasts sink in really opened my thinking to the "ecosystem" idea. APL became my favorite in the 1970s (because of REPL in large degree), which explains my later fascination with J (both Iverson languages).[2] > > Certainly one of the more attractive aspects of Python is that it is both > relatively-easy-to-learn and relatively-useful-in-the-real-world. But > there's definitely a school of thought that *no* language used in industry > is optimal for education, that the aims of industry and education are too > incompatible for one language to rule for both purposes. It's definitely > an interesting debate. I feel fortunate that I work with young enough kids > that I feel little pressure to teach them something with immediate > marketable value. This gives me the freedom to experiment with many > different languages; I've found that I rather like teaching ones expressly > designed for education, but Python remains one of my favorite educational > options of the popular, mainstream languages. > > I'm all for encouraging debate. What I hear a lot is once your language becomes typecast as "a teaching language" that's "the kiss of death" as far as industry is concerned. That's a stereotype to overcome I think. I tend to think of industry as averaging 10 years ahead of academia with the latter making do with what more competitive / secretive enterprises have contributed to open source (I associate "free and open" with the "liberal" in "liberal arts"). That's more typecasting institutions than individuals, which latter tend to go back and forth between the two. So my attitude is more "Python and what else?" i.e. lets not stop with Python as if it were some be-all-end-all. It ain't. It's another tool, like business English is a tool. Python + Pyret as a bridge to something else then? Haskell? Prolog? I'm not one of those who think you need to join warring Camp A (OOP) or warring Camp B (FP) and then express loyalty to one by dissing the other. Rather, play up the strengths of both paradigms (I know Shiriam disputes that OOP is really a "paradigm" but whatever).[3] For me, the thing that has made me lose some enthusiasm for Python was not > even mentioned in the article. For me, the biggest downside is that the > language, with its Global Interpreter Lock, lacks a clean solution to > teaching concurrency. IMHO, concurrency has become a vital issue, and > requires a somewhat different way of thinking about problems. To create > the next generation of exceptional programmers, I believe we need to > introduce models of concurrent programming much earlier in the curriculum. > Almost every recent programming language places a huge emphasis on > concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but > none of those are particularly welcoming to beginner programmers. So I'd > love to see more educational languages that feature concurrency. > > That sounds valid and interesting. How well does Pyret fit that bill I wonder? Python has new infrastructure growing out of Tulip around the syntax of yield, using from and send, to develop its native asynchronous capabilities even more. For myself, when I'm at OSCON you'll find me in the Scala and Clojure tutorials. [4] My friend Dr. David DiNucci has written a book on concurrency which has plunged me back into thinking of programming as theater, scripting characters (agents) to do stuff, oft in parallel.[5] Managing concurrency in ordinary life amongst multiple players is something I think we need to get better at in business / enterprise / institution management in general, not just in our use of multiple processors. Operations Research, as it used to be called, with its PERT charts and critical paths, was always about concurrency (e.g. building a submarine or A-bomb faster than the competition). I go back to Python being a "glue language" that "plays well with others" and believe in harping on those virtues as they both imply "others" to glue together and play with. Python is not like the pythons in Florida, stereotyped as devouring everything else, leaving only pythons (all alligators eaten). That's not a goal. The evolutionary advantages that go with biodiversity is an important principle. Python is so useful because it's like a tour bus: once you're on board, you get to visit many alien lands through what it controls i.e. talks to (e.g. Blender). So for me it's always "Python and what else?" these days, and not "How can we replace Python with something else more trendy?". Kirby [1] http://mathforum.org/kb/message.jspa?messageID=9718737 http://mathforum.org/kb/message.jspa?messageID=9700004 [2] http://www.4dsolutions.net/ocn/Jlang.html (Jiving in J -- Iverson himself helped me catch a typo or two) [3] http://cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/paper.pdf (anti "paradigms") [4] http://controlroom.blogspot.com/search?q=Clojure (Scala comes up too) [5] Dave's book: http://www.barnesandnoble.com/w/scalable-planning-david-dinucci/1110902186?ean=9781475211160 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.engelberg at gmail.com Fri Mar 20 05:42:48 2015 From: mark.engelberg at gmail.com (Mark Engelberg) Date: Thu, 19 Mar 2015 21:42:48 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 7:38 AM, kirby urner wrote: > > I'm not one of those who think you need to join warring Camp A (OOP) or > warring Camp B (FP) and then express loyalty to one by dissing the other. > Rather, play up the strengths of both paradigms (I know Shiriam disputes > that OOP is really a "paradigm" but whatever).[3] > I followed your link [3], and that's not my take on what he's saying at all. My reading of the paper is that his central claim is that modern real-world languages don't fall into neat little divisions like "object-oriented" or "functional". Therefore, he claims, the typical "programming paradigms" course in college is out of date, and in need of a renovation, so students can gain an appreciation for how these paradigms blend, rather than thinking of them as separate entities. (He then puts forth his own textbook Programming Languages and Interpretation as a proposed solution). He even cites Python as an example of a language that blurs the lines between paradigms (it has OO, but it doesn't force you to use it, it has some functional constructs, but it's still not typically thought of as a functional programming language, etc.) I'd expect you to mostly agree with that premise. > > For me, the thing that has made me lose some enthusiasm for Python was not >> even mentioned in the article. For me, the biggest downside is that the >> language, with its Global Interpreter Lock, lacks a clean solution to >> teaching concurrency. IMHO, concurrency has become a vital issue, and >> requires a somewhat different way of thinking about problems. To create >> the next generation of exceptional programmers, I believe we need to >> introduce models of concurrent programming much earlier in the curriculum. >> Almost every recent programming language places a huge emphasis on >> concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but >> none of those are particularly welcoming to beginner programmers. So I'd >> love to see more educational languages that feature concurrency. >> >> > That sounds valid and interesting. How well does Pyret fit that bill I > wonder? > Sadly, I don't expect Pyret will address concurrency at all. I learned that Pyret is now strictly a compile-to-javascript language (presumably they feel the language will have better educational reach if you can code it entirely in a web-based IDE). That may end up limiting Pyret's ability to include concurrency features. Thanks for the other interesting comments and links. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Fri Mar 20 15:31:16 2015 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 20 Mar 2015 07:31:16 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 9:42 PM, Mark Engelberg wrote: > On Thu, Mar 19, 2015 at 7:38 AM, kirby urner > wrote: > >> >> I'm not one of those who think you need to join warring Camp A (OOP) or >> warring Camp B (FP) and then express loyalty to one by dissing the other. >> Rather, play up the strengths of both paradigms (I know Shiriam disputes >> that OOP is really a "paradigm" but whatever).[3] >> > > I followed your link [3], and that's not my take on what he's saying at > all. My reading of the paper is that his central claim is that modern > real-world languages don't fall into neat little divisions like > "object-oriented" or "functional". Therefore, he claims, the typical > "programming paradigms" course in college is out of date, and in need of a > renovation, so students can gain an appreciation for how these paradigms > blend, rather than thinking of them as separate entities. (He then puts > forth his own textbook Programming Languages and Interpretation as a > proposed solution). > > I agree, his paper spells it out much more, where he thinks the "paradigms" notion falls down and betrays us, leading us into sloppy thinking. Before posting that email, I'd only seen a cross comment on math-thinking-l telling us to stop thinking of OOP as a "paradigm". It's a little bit like "races" which I likewise do not believe in, i.e. if you cling to the idea of "pure specimens" of any race, then you get the concept of "mixed" for the impure. It's like the "primary colors" model or RGB, very tempting. As long as we see OO and FP as paradigms, then Python may be cast as a "hybrid" of the two. It's somewhat hard *not* to think that way, with races too, until you read papers which remind us its all in our heads anyway. We circle some attributes, some family resemblances, and make those "hallmark". But the genetics (memetics) is really more complicated than that and not subject to such gross cartoonification. What we also need to consider is the nebulous concept of Community. Why did Smalltalk dissipate? https://youtu.be/YX3iRjKj7C0 Uploaded on May 8, 2009 Robert Martin (Object Mentor, Inc.) "What Killed Smalltalk Could Kill Ruby, Too" I used to think only the grammar / semantics / technical attributes of a language mattered, but others (e.g. one Michael Jennings at Food Not Bombs servings) opened my eyes to the importance of community, governance, PR etc. That the Python community has worked hard on a Code of Conduct for Pycons, a Diversity theme etc. has been beneficial. I think a next step is more literature / documentation not-in-English. > He even cites Python as an example of a language that blurs the lines > between paradigms (it has OO, but it doesn't force you to use it, it has > some functional constructs, but it's still not typically thought of as a > functional programming language, etc.) I'd expect you to mostly agree with > that premise. > > I think what Shiriam really finds distasteful is the sudden ballooning of Java in popularity, starting with the hype of Java One and all the web stuff we were promised (where are applets today? Hardly used much right?). I was hanging with a C++ coder at the time and could see why he found Java more beautiful and convenient than C++ at least. > > >> >> For me, the thing that has made me lose some enthusiasm for Python was >>> not even mentioned in the article. For me, the biggest downside is that >>> the language, with its Global Interpreter Lock, lacks a clean solution to >>> teaching concurrency. IMHO, concurrency has become a vital issue, and >>> requires a somewhat different way of thinking about problems. To create >>> the next generation of exceptional programmers, I believe we need to >>> introduce models of concurrent programming much earlier in the curriculum. >>> Almost every recent programming language places a huge emphasis on >>> concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but >>> none of those are particularly welcoming to beginner programmers. So I'd >>> love to see more educational languages that feature concurrency. >>> >>> >> That sounds valid and interesting. How well does Pyret fit that bill I >> wonder? >> > > Sadly, I don't expect Pyret will address concurrency at all. I learned > that Pyret is now strictly a compile-to-javascript language (presumably > they feel the language will have better educational reach if you can code > it entirely in a web-based IDE). That may end up limiting Pyret's ability > to include concurrency features. > > Thanks for the other interesting comments and links. > > Interesting, didn't know that. When Mark Shuttleworth summoned (asked politely, paid some ways, including mine) a bunch of us to England for a pow wow on the future of education in South Africa, Alan Kay, the Smalltalk guy, showed up all burning with admiration for JavaScript.[1] He'd just done a Logo in that language. He liked Python too. We had many solid hours of meetings. Now the RSA is lightyears ahead, building Chappie and all. [2] :-D Another interesting language that leverage Python you may know about: Hy https://hy.readthedocs.org/en/latest/tutorial.html Thanks for another interesting thread, maybe more will chime in on this one. Kirby [0] http://mybizmo.blogspot.com/2012/10/omsi-science-on-race.html [1] http://controlroom.blogspot.com/2006/04/shuttleworth-summit-day-two.html [2] Chappie: http://worldgame.blogspot.com/2015/03/chappie-movie-review.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at handysoftware.com Mon Mar 23 03:23:32 2015 From: david at handysoftware.com (David Handy) Date: Sun, 22 Mar 2015 22:23:32 -0400 (EDT) Subject: [Edu-sig] ACM article on Python In-Reply-To: References: Message-ID: <1427077412.14816097@apps.rackspace.com> This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <[ macquigg at ece.arizona.edu ]( mailto:macquigg at ece.arizona.edu )> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see [ pykata.org ]( http://pykata.org/ )). I think the best way to understand these criticisms is to take a look at the language Pyret ([ pyret.org ]( http://pyret.org )), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. -------------- next part -------------- An HTML attachment was scrubbed... URL: From MDiPierro at cs.depaul.edu Mon Mar 23 03:40:33 2015 From: MDiPierro at cs.depaul.edu (DiPierro, Massimo) Date: Mon, 23 Mar 2015 02:40:33 +0000 Subject: [Edu-sig] ACM article on Python In-Reply-To: <1427077412.14816097@apps.rackspace.com> References: <1427077412.14816097@apps.rackspace.com> Message-ID: http://pt.slideshare.net/rdonkin/minecraft-in-500-lines-with-pyglet-pycon-uk?next_slideshow=1 On Mar 22, 2015, at 9:23 PM, David Handy > wrote: This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" > said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg > wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org). I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. _______________________________________________ Edu-sig mailing list Edu-sig at python.org https://mail.python.org/mailman/listinfo/edu-sig From macquigg at ece.arizona.edu Mon Mar 23 04:49:39 2015 From: macquigg at ece.arizona.edu (David MacQuigg) Date: Sun, 22 Mar 2015 20:49:39 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: <1427077412.14816097@apps.rackspace.com> References: <1427077412.14816097@apps.rackspace.com> Message-ID: On Sun, Mar 22, 2015 at 7:23 PM, David Handy wrote: > This evening I had an interesting conversation with a very determined > 10-year old boy who wants to learn programming in Java and nothing but Java. > I told him that I recommend Python as a first programing language, because > learning Python is easier. But he was adamant. It's Java or nothing. Why? > Minecraft is implemented in Java. That made Java the ultimate in coolness to > him. No "risk-averse bureaucratic" thinking there, just a willingness to do > hard things to get what he wanted. > > So I told him, go for it, more power to you, and offered my assistance. What > else could I do? :) In the face of determination like that, it's lead, > follow, or get out of the way... When I was an undergrad at Caltech, we had no good courses in programming or computer science, and I really wanted to understand computers. So I dedicated most of one summer to slugging through several feet of IBM manuals. My first "computer language" was JCL!! It was a total waste. I lost interest in programming for many years. Same thing happened to my interest in literature, after a string of really bad teachers in high school. Give that 10-year old plenty of encouragement, but be ready to catch him when he falls. Write the Java for him, if necessary, but then show him the equivalent in Python. From chalmer.lowe at gmail.com Mon Mar 23 16:43:45 2015 From: chalmer.lowe at gmail.com (Chalmer Lowe) Date: Mon, 23 Mar 2015 05:43:45 -1000 Subject: [Edu-sig] Edu-sig Digest, Vol 140, Issue 12 In-Reply-To: References: Message-ID: This tutorial at PyCon in the next few weeks will cover using Python to manipulate Minecraft. Not sure if this is on the Raspberry Pi version OR works against the Desktop PC version of Minecraft. On the Raspberry Pi, folks have been manipulating Minecraft environments for years, but my understanding is that there were some differences that prevent/limited portability to the Desktop variant. https://us.pycon.org/2015/schedule/presentation/414/ Also see the Raspberry Pi version: http://www.raspberrypi.org/updates-to-minecraft-documentation/ Chalmer Lowe, MS President, Dark Art of Coding http://darkartofcoding.com/ Chairman, Python Education Summit https://us.pycon.org/2015/events/edusummit/ On Mon, Mar 23, 2015 at 1:00 AM, wrote: > Send Edu-sig mailing list submissions to > edu-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/edu-sig > or, via email, send a message with subject or body 'help' to > edu-sig-request at python.org > > You can reach the person managing the list at > edu-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Edu-sig digest..." > > > Today's Topics: > > 1. Re: ACM article on Python (David MacQuigg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Mar 2015 20:49:39 -0700 > From: David MacQuigg > To: David Handy > Cc: Mark Engelberg , "edu-sig at python.org" > > Subject: Re: [Edu-sig] ACM article on Python > Message-ID: > h-Ot0a+k9xLqTkPv+QQ9BpSqkxq6bJRJKYTSE2cECo-7SQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Mar 22, 2015 at 7:23 PM, David Handy > wrote: > > This evening I had an interesting conversation with a very determined > > 10-year old boy who wants to learn programming in Java and nothing but > Java. > > I told him that I recommend Python as a first programing language, > because > > learning Python is easier. But he was adamant. It's Java or nothing. Why? > > Minecraft is implemented in Java. That made Java the ultimate in > coolness to > > him. No "risk-averse bureaucratic" thinking there, just a willingness to > do > > hard things to get what he wanted. > > > > So I told him, go for it, more power to you, and offered my assistance. > What > > else could I do? :) In the face of determination like that, it's lead, > > follow, or get out of the way... > > When I was an undergrad at Caltech, we had no good courses in > programming or computer science, and I really wanted to understand > computers. So I dedicated most of one summer to slugging through > several feet of IBM manuals. My first "computer language" was JCL!! > It was a total waste. I lost interest in programming for many years. > Same thing happened to my interest in literature, after a string of > really bad teachers in high school. > > Give that 10-year old plenty of encouragement, but be ready to catch > him when he falls. Write the Java for him, if necessary, but then > show him the equivalent in Python. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > https://mail.python.org/mailman/listinfo/edu-sig > > > ------------------------------ > > End of Edu-sig Digest, Vol 140, Issue 12 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurner at oreillyschool.com Mon Mar 23 23:31:10 2015 From: kurner at oreillyschool.com (Kirby Urner) Date: Mon, 23 Mar 2015 15:31:10 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: References: <1427077412.14816097@apps.rackspace.com> Message-ID: > Give that 10-year old plenty of encouragement, but be ready to catch > him when he falls. Write the Java for him, if necessary, but then > show him the equivalent in Python. > Having the motive to master Minecraft is a good reminder that a lot of us tackle a language as a means to an end not as an end in itself. Saying "Python is easier" is no consolation, like saying, "why not Sanskrit, it's easier than Czech" when, in fact, you're moving to Prague? A lot of us "like programming" and "enjoy learning languages" but lets remember our own personal story is just that. Some of us really do like to argue and/or debate whereas others just see that as being disagreeable. Finding good friends in the Java / Minecraft community, true peers who enjoy the same projects, might possibly be a critical step, though not knowing the individual in question, that could only be a guess. Perhaps those friendships have already been made. I had breakfast with a former Python student who was still overseas when we met online. He's a computer science student at a local university these days and is using C++. Although good at Python and steeped in SQL, he's not disrespectful of what C++ does for us in this world: a lot. Python extends through these languages i.e. is made the richer for them. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.dion at gmail.com Tue Mar 24 00:41:44 2015 From: francois.dion at gmail.com (Francois Dion) Date: Mon, 23 Mar 2015 19:41:44 -0400 Subject: [Edu-sig] ACM article on Python In-Reply-To: <1427077412.14816097@apps.rackspace.com> References: <1427077412.14816097@apps.rackspace.com> Message-ID: <20B97E6F-B707-4E70-94B1-BA5DA40963A8@gmail.com> http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with-python/ Francois El Mar 22, 2015, a las 10:23 PM, "David Handy" escribi?: > This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. > > So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... > > David H > > On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" said: > > On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg wrote: > The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. > Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). > That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. > Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. > > > The bulk of the article is discussion of Python's "weaknesses": > 1) Creating non-trivial data structures is onerous. > 2) Limited support for testing. > 3) Lack of static types. > 4) Difficult transition to other languages because the syntax is quite different. > Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org). > I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. > > In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. > As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. > > I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. > I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. > This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > https://mail.python.org/mailman/listinfo/edu-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at handysoftware.com Tue Mar 24 02:41:19 2015 From: david at handysoftware.com (David Handy) Date: Mon, 23 Mar 2015 21:41:19 -0400 (EDT) Subject: [Edu-sig] ACM article on Python In-Reply-To: <20B97E6F-B707-4E70-94B1-BA5DA40963A8@gmail.com> References: <1427077412.14816097@apps.rackspace.com> <20B97E6F-B707-4E70-94B1-BA5DA40963A8@gmail.com> Message-ID: <1427161279.026426338@apps.rackspace.com> Thank you all for the links pointing to Minecraft on the Raspberry Pi and articles on how to control it with Python. That's not something I've tried myself, but I have passed the links along to my friend. David H On Monday, March 23, 2015 7:41pm, "Francois Dion" said: [ http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ ]( http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ ) [ http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with-python/ ]( http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with-python/ ) Francois El Mar 22, 2015, a las 10:23 PM, "David Handy" <[ david at handysoftware.com ]( mailto:david at handysoftware.com )> escribi?: This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" <[ mark.engelberg at gmail.com ]( mailto:mark.engelberg at gmail.com )> said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <[ macquigg at ece.arizona.edu ]( mailto:macquigg at ece.arizona.edu )> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see [ pykata.org ]( http://pykata.org/ )). I think the best way to understand these criticisms is to take a look at the language Pyret ([ pyret.org ]( http://pyret.org )), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. _______________________________________________ Edu-sig mailing list [ Edu-sig at python.org ]( mailto:Edu-sig at python.org ) [ https://mail.python.org/mailman/listinfo/edu-sig ]( https://mail.python.org/mailman/listinfo/edu-sig ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Tue Mar 24 03:44:31 2015 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 23 Mar 2015 19:44:31 -0700 Subject: [Edu-sig] ACM article on Python In-Reply-To: <1427161279.026426338@apps.rackspace.com> References: <1427077412.14816097@apps.rackspace.com> <20B97E6F-B707-4E70-94B1-BA5DA40963A8@gmail.com> <1427161279.026426338@apps.rackspace.com> Message-ID: Yes many thanks for the Minecraft with Pi link. @psf_snake tweeted about it too today -- and re a 111 line python chess engine a student pointed me at. Kirby -------------- next part -------------- An HTML attachment was scrubbed... URL: