Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: "Neil D. Cerutti" <neilc@norwich.edu>
Subject: Re: how to get the ordinal number in list
Date: Tue, 12 Aug 2014 15:29:35 -0400
References: <53E658CD.5020904@gmail.com> <CACwCsY7icE7X2upr0auNhe37xh5HdC09Ad4yaetqpo+fcoBRYg@mail.gmail.com> <mailman.12780.1407551775.18130.python-list@python.org> <53e59035$0$29998$c3e8da3$5496439d@news.astraweb.com> <338e8fb0-c9ec-462a-b560-1c1ff77de17e@googlegroups.com> <roy-3060CA.11342209082014@news.panix.com> <b5ac5b12-cda7-464e-9c14-63ef184a7a10@googlegroups.com> <roy-FEFEEE.13102110082014@news.panix.com> <154cc342-7f85-4d16-b636-a1a953913c98@googlegroups.com> <roy-FD5EE7.14142310082014@news.panix.com> <mailman.12890.1407865263.18130.python-list@python.org> <70c65ab0-0a9d-4705-a8a3-43b9ee0600a0@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <70c65ab0-0a9d-4705-a8a3-43b9ee0600a0@googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.12898.1407871797.18130.python-list@python.org>
Lines: 77
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:76146

On 8/12/2014 2:20 PM, Rustom Mody wrote:
> On Tuesday, August 12, 2014 11:10:48 PM UTC+5:30, Neil D. Cerutti wrote:
>> Beginners are particularly poor, in relation to experts, at noticing the
>> applicability of idea, and at combining ideas together. Breaking things
>> into component parts has multiple benefits:
>
>> 1. The applicability of individual ideas becomes obvious. It's one thing
>> to know about [].sort, and another thing to know when it's appropriate
>> to sort something.
>
>> 2. The expert specifically shows how and why the ideas are combined.
>> This helps build the connection for the beginner, whose knowledge is not
>> stored as an expert stores it; i.e, in broad categories with multiple
>> connections; but as disorganized data with very few connections.
>
> Nice!
>
> And how do we lead the beginners towards expertise?
> In a way functional programming is to programming creativity
> what lego is to children's spatial creativity.
>
> Specifically there are a bunch of pieces that need to fit:
>
> 1. Functional Programming: Nothing more than composing functions
>     [Maybe a bit simplistic but not unrealistic a defn]
> 2. Trying this out at the interpreter
> 3. Introspectable objects

Functional programming could be particularly hard to teach since it is 
generally made up of numerous small units of work combined in a complex 
way. This is precisely the formula for something that beginners will 
find extremely challenging.

When functional programming is dumbed down enough for a beginner to be 
able to grok it, the programming problems start to look really lame. It 
needn't be that way, of course, but it takes a good deal of creativity 
on the part of the instructor. If Factorial doesn't turn you on, you 
might be screwed. ;)

> Some things follow from this:
>
> For the lego-game of playing with functions at the REPL to work and be
> pleasant and rewarding:
>
> 1. functions should be non side-effecting; else same trials giving different
> answers adds more confusion than understanding
> 2. They should be non-printing else:
>
> def foo(x): return x+1
> def bar(x): print x+1
>
> look similar when trivially tried but compositionally are utterly different
>
> In effect a printing function breaks the lego bricks

That may be so, but printing stuff to the screen is very natural to 
people. I've downloaded Haskell a few times, but the knowledge that 
getting input and writing output requires something mysterious called 
gonads just frightens me.

> [The P in the REPL is DRY enough that it does not usually need to be
> repeated all over]

A good REPL does help a lot, though.

> 3. Abstractions (class instances) should be avoided in favor of
> concrete data (lists, dicts, scalars) because they add undue mess at little
> comprehension advantage. eg take the example of a regex match. It
> returns some object and then we have to scratch our heads wondering
> whats in the magic box. If instead of match, we use findall, the data
> is manifest and obvious.

I'm with you on regex: match objects suck. That and escaping.

-- 
Neil Cerutti