[Edu-sig] ACM article on Python

[David MacQuigg]

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 <mark.engelberg at gmail.com>
wrote:

> 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).
>

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