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" <da...@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.engelb...@gmail.com> said: > > On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <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). > 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@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
