how to get the ordinal number in list

[Neil D. Cerutti]

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