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" <francois.d...@gmail.com>
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" <[ da...@handysoftware.com ](
mailto: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 ]( 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., 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 ]( mailto:Edu-sig@python.org )
[ https://mail.python.org/mailman/listinfo/edu-sig ](
https://mail.python.org/mailman/listinfo/edu-sig )
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
