paradigms (was Re: Python-list digest, Vol 1 #5925 - 11 msgs)

[Alex Martelli]

"Kyle Wayne Kelly" <kknbk2 at bellsouth.net> wrote in message
news:mailman.989628678.401.python-list at python.org...
    ...
> I love the way that Python's list-serve behaves.  The other list-serves
just
> send several independent messages.  My e-mail is constantly flooded with

Most mailing-list servers, in my experience, can be set to 'digest' mode.
How to do so varies by mailing list, but it's not unique to python-list.


> By the way, what programming paradigm does Python fall under?

I consider Python an example of a multi-paradigm language, with
primary support for more than one major paradigm.  Some other
languages do that, too -- C++ and Common Lisp, for example.

In the case of C++, procedural, O-O, and generic programming are
the directly supported ones.  You can use others, but there is some
boilerplate you have to develop for them (the language gives you
the tools to write that boilerplate, and you may find it already there
in some add-on framework, but it's not in the language proper).

In Python, procedural and O-O are "directly there", but generic
isn't far at all, because the polymorphism is mainly signature-based
(having lots of C++ experience, often it "feels" to me, as I'm coding
some Python function/class, much 'as if' I was coding a C++
template... except for the nicer syntax:-).  There is also some (partial)
support for functional programming, "pattern-matching directed"
(using re's), "concurrent" (using threads), &c, but those are not
quite as complete or 'nearly there'.

In Lisp, it's similar, but the functional part appears to be more
developed, and the generic/signature-based one less so (there tends
to be less boilerplate to do to get FP, but more to get generic).  I
think the pattern-matching is closer (with macros) and concurrent
is farther (I don't believe there is a threading specs in the standard),
but it's not really all that different.


"Purer" languages, focusing on a single paradigm, are OK as long
as that single paradigm is a reasonable match for your problem,
and indeed they may make your life simpler then because your
whole solution-architecture is "guided" or "constrained" that way.
However, this does make it harder to step out of the paradigm when
it's not optimal.  Coplien makes the point well in his "Multi-paradigm
DESIGN for C++" book, I believe.

I've seen Prolog used in cases where 3/4th of the issues matched
its logic-programming paradigm very well _BUT_ getting the other
1/4th of the program done was really a chore and a strain on the
language, simulating imperative &c with lots of 'cuts' & so on.  I
know that some feel similarly about Haskell's purity in 'lazy' FP --
that Haskell monads are there as 'stopgaps' (I do not fully concur,
but the viewpoint is defensible).  Notice that modern languages
of similar families appear to tend to multi-paradigm... Mercury or
Mozart/Oz for logic-programming-centered (but with good support
for others), OCaml for FP-centered but &c (though some might
say OCaml overdoes it:-), O'Haskell ditto.

Personally I think that single-paradigm _IS_ OK as long as one
doesn't superimpose artificial constraints about only using one
programming language in the system -- one good multiparadigm
language at the core can glue together and coordinate others that
are optimized for one specific paradigm, rather than trying to make
one big mess o'pottage of everything.  SQL is my favourite example
of a single-paradigm language which shines because it does not
even *TRY* to solve the WHOLE program -- it's MEANT to be used
together with at least one other language to fashion a solution (I
don't mean "extensions" such as Transact-SQL, just nice, pure
SQL itself:-).  I wish we had similarly-standardized monoparadigm
languages for stuff such as logic programming and generalized
pattern-matching, similarly "embeddable" painlessly into solutions
architected mostly around a multi-paradigm language such as
Python...!-)


Alex