how to get the ordinal number in list

[Rustom Mody]

On Monday, August 11, 2014 3:58:59 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote:

> > On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote:
> >> You did the same thing in your own course, the only difference being
> >> you accepted a different set of primitive functions. But ultimately you
> >> have to introduce *some* amount of concreteness, at some level,
> >> otherwise we're just engaged in mental masturbation:
> >> Q: "Write a function to calculate the nth Catalan number." A: "Assume
> >> that a function Catalan(n) exists and calculates the nth Catalan
> >> number. Then the solution is Catalan."
> > You're concocting your own definitions and critiquing/refuting them.

> No, but I think you are deliberately choosing to ignore my point for the 

Because I dont understand what you are saying. [See below]

> My point is that, at *some* level, you have to 
> actually write code (well duh!) which must be targeted at some concrete 
> environment. Different languages provide different levels of abstraction, 
> but they all have a some concrete set of primitive operations which 
> actually do *something*, and that something is concrete, not abstract. 
> Every function, even in Haskell, has an implementation. Otherwise if you 
> don't need an implementation, you can just declare "imagine a function 
> that implements Foo" for any Foo, and you're done.[1]

I guess part of the problem is that evidently you and I use 'concrete'
and 'abstract' in almost diametrically opposite ways.

In my book, FP is easy and pleasant and smooth because (among other things)
FP types are concrete, whereas OOP types are abstract.

Here is an FP classic:

http://www.nlda-tw.nl/janmartin/vakken/TFIT/Extra%20materiaal/Bird_Wadler.%20Introduction%20to%20Functional%20Programming.1ed.pdf

In the section on 'abstract types' (pg 221 chap 8) he briefly explains what
is an abstract type and indicates that the whole book only deals with concrete types.

This was written in 1988.

Across the last 25 years this view has only strengthened at least in the
FP circles, viz. that concrete types are all thats needed for the most part
whereas abstract types (ADTs) and other OOP fancies are a waste of time, a PITA
and not worth the sweat of pursuing them.

You are of course free to disagree with this viewpoint -- the majority of
programmers do.

But now you are turning the tables and saying that the FP types/constructs
are more abstract than the conventional ones.

I dont argue with this because I dont know how to, other than to say
it does not seem to be the dominant view in either the conventional
(OOP/imperative) communities or in the FP community.

Here is a conversation from reddit: 
http://www.reddit.com/r/haskell/comments/xgq27/uday_reddy_sharpens_up_referential_transparency/
which should give a sense of the pov.


Person 1
| By the way, somebody commented on the StackOverflow page that the
| naive functional programmer seems to use syntactic reasoning while the
| naive imperative programmer seems to use operational reasoning.

Person 2
| Interesting. I have a theory that functional programmers use more
| concrete (denotative, indicative, elemental) thought whereas
| imperative programmers use more abstract (connotative, analogous)
| thought. However, sequential and random thinking styles can also be
| very different. On the Meyers-Briggs functional and imperative
| programmers seem to differ on both axies of the four main personality
| groups.

Person 3
| Yup, that is also a quite insightful point. But we also need to keep
| in mind the training aspect. Functional programming is taught in a
| semi-rigorous way, using the knowledge of set theory and mathematics
| that we all know. Imperative programming is taught in an intuitive
| way, because there is no well-understood mathematics for it yet. In
| fact, let us say that imperative programming is not really taught at
| all. Whatever the imperative programmers learn, they learn through
| experience. They write programs, see how they behave, and build up a
| mental picture of how they work and how to reason about them. It is an
| art rather than a science.