how to get the ordinal number in list

[Steven D'Aprano]

Chris Angelico wrote:

> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> I think this is why both declarative and functional programming idioms
>> will remain niche (although important niches). Most tasks are inherently
>> imperative to at least some degree, and often a *great* degree.
> 
> Maybe that's true as a whole, but there are certainly ways in which
> certain declarative or functional elements can be extremely useful to
> an otherwise-imperative program.

Oh yes! I think that using functional idioms is *very* valuable. List comps
and similar are great, but more than that, the idea of writing idempotent
functions with no side-effects (except IO) is (I believe) vital for good
programming. Relying on argument passing rather communicating by global
variables (or the OO equivalent, instance attributes) is likewise vital.

It's not *quite* impossible to write good, reliable code without functional
idioms, in the same sense that it is conceivable that somebody might write
bug-free unstructured spaghetti code, but I think one of the failures of OO
programming is the over-reliance on methods that communicate via
side-effects. I don't insist that side-effects are completely verboten, as
some functional programming purists do, but I do endeavour to ensure that
any side-effects are limited, encapsulated, and introduce as little
coupling as practical.

(It is my belief that inappropriate coupling is the great evil in
programming. Having too much coupling between parts of your code which
ought to be independent is like Ebola for reliable code, contagious and
deadly. I'm always looking for ways to reduce coupling between parts of my
code, and functional idioms are good for that.)



> Python's (list etc) comprehensions 
> are broadly functional in style, 

No surprise, since list comps were stolen from Haskell :-)


[...]
> I've sometimes done some extremely declarative coding in places; my
> MUD client builds its menus by looking for specially-named functions
> and getting some metadata from them to work out what the menu item
> name should be. An approximate Python equivalent would be:
> 
> @filemenu("E_xit")
> def exit():
>     prompt("Do you really want to exit?")
> 
> where the presence of the function is what causes the menu item to
> exist. In this case, the 'filemenu' decorator is probably imperative
> code that adds the menu item to the File menu, but if you're reading
> through a source file that has a bunch of functions like that, you'd
> have to agree that that's a declarative style of coding. And it's a
> style that works well for this kind of thing.

I don't think I would agree that's declarative style. I think that's a form
of imperative programming, where the syntax is:

    @ make menu
    def function: ...

rather than:

    def function: ...
    make menu (function)

but I wouldn't start a Holy War over it :-)

There's a fair amount of overlap between the major programming paradigms,
and hence disagreement as to what falls under which paradigm. For instance,
FOLDOC has a good, simple distinction in its definition for "imperative":

[quote]
The Free On-line Dictionary of Computing (20 July 2014) [foldoc]

imperative language
imperative
imperative programming

   <language> Any programming language that specifies explicit
   manipulation of the state of the computer system, not to be
   confused with a procedural language, which specifies an
   explicit sequence of steps to perform.

   An example of an imperative (but non-procedural) language is a
   data manipulation language for a relational database
   management system.  This specifies changes to the database
   but does not necessarily require anyone to specify a sequence
   of steps.

   Both contrast with declarative languages, which specify
   neither explicit state manipulation nor a sequence of steps.
[end quote]

You'll note that it suggests SQL would count as an imperative language, but
Wikipedia's article on declarative languages gives SQL as a paragon of
declarative languages!

http://en.wikipedia.org/wiki/Declarative_programming


In Python terms, we might consider "import" to be declarative, since it
specifies what to do (load a name from a module) but not how to perform
it. "import spam" might find spam anywhere, in any form (source code, byte
code, machine code, in a zip file, somewhere on the disk, inside the Python
executable itself), which to my mind suggests a declarative idiom. Or such
things as test discovery, where unittest and doctest will automatically
locate and run tests. (The tests themselves are typically written in a
procedural paradigm.) Otherwise, Python doesn't really have a lot to offer
in the declarative paradigm.


-- 
Steven