Chris Angelico wrote: > 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.
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 -- https://mail.python.org/mailman/listinfo/python-list