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 <da...@handysoftware.com<mailto:da...@handysoftware.com>> 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" <mark.engelb...@gmail.com<mailto:mark.engelb...@gmail.com>> said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <macqu...@ece.arizona.edu<mailto:macqu...@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., co pying 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@python.org<mailto:Edu-sig@python.org> https://mail.python.org/mailman/listinfo/edu-sig _______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
