On Wed, Sep 28, 2016 at 3:27 PM, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > Lawrence D’Oliveiro wrote: >> >> On Wednesday, September 28, 2016 at 3:35:58 AM UTC+13, Peter Otten wrote: >> >>> is Python actually a "functional language"? >> >> >> Yes >> <https://groups.google.com/d/msg/comp.lang.python/P1Edc4eJNkY/D5KBo7skAgAJ>. > > > No, not according to what the term "functional language" > usually means. > > Languages described as "functional" usually incorporate > all or most of the following characteristics: > > * No side effects (new variable bindings may be created, but > existing ones cannot be changed; no mutable data structures).
If that's adhered to 100%, the language is useless for any operation that cannot be handled as a "result at end of calculation" function. You can't produce intermediate output. You can't even produce debugging output (at least, not from within the program - you'd need an external debugger). You certainly can't have a long-running program that handles multiple requests (eg a web server). That kind of rule is fine for mathematical systems, and it's fine for certain specific sub-parts of larger programs, but IMO it's utterly impractical for an entire programming language. > * Lazy evaluation by default. Given that you said "usually means", sure, but only because most functional programming is abysmal (or impossible - calculating the squares of all positive integers, then subscripting it) unless optimized like that. > * Syntactic support for currying. Is that really such a big deal? What's the true difference between syntactic support and stdlib support? > * Syntactic support for case-analysis-style definition of > functions, by matching the arguments against a series of > patterns. Again, why such a big deal? Unless you're deliberately defining "functional language" as "clone of Haskell" or something, there's no particular reason for this to be a requirement. > * A standard library geared towards a programming style > that makes heavy use of higher-order functions. This I would agree with. > Python has none of these features. It's possible to use a > subset of Python in a functional way, but it goes against the > grain, and without all the above support from the ecosystem > it's clumsier than it would be in a real functional language. > > Some parts of Python, such as list comprehensions, have a > functional flavour, but Python is predominantly an imperative > language. Python is predominantly a *practical* language. Since purely functional programming is fundamentally impractical, Python doesn't force us into it. You want to work functionally? No problem. Pretend that "def" is a declaration, make all your functions pure, and either finish with a single "print(main())" or do your actual work at the REPL. No problem. Want to make event-driven code? Hide an event loop (maybe a GUI one, maybe asyncio, whatever) in your main routine, and do everything through that. Want to use Smalltalk-style "message passing"? Fits nicely into classes and methods. Want a simple batch scripting style? Ignore functions and classes, and write your code flush left. Python doesn't force you into any of these models, ergo Python isn't a functional language, nor an event-driven language, etc, etc. It's a general-purpose language. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
