On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <st...@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. Python's (list etc) comprehensions
are broadly functional in style, as are most of the itertools
oddments. There's not a lot that's declarative in Python, but (at
least in Python 3) the presence of __eq__() in a class disables the
default __hash__ implementation, which effectively makes __eq__ a
declaration "I'm doing custom equality, so I'm unhashable unless I say
otherwise".
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.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
