[Edu-sig] ACM article on Python

[Mark Engelberg]

On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <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).
>

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: <http://mail.python.org/pipermail/edu-sig/attachments/20150314/fea91f00/attachment.html>