Late-binding of function defaults (was Re: What is a function parameter =[] for?)

[Ned Batchelder]

On Wednesday, November 25, 2015 at 8:23:36 PM UTC-5, BartC wrote:
> On 26/11/2015 00:31, Steven D'Aprano wrote:
> > On Thu, 26 Nov 2015 09:41 am, BartC wrote:
> >
> >> Maybe you're too familiar with it. But the idea of executing the
> >> function and other definitions in a file, instead of they just being
> >> there, is novel.
> >
> >
> > It really, truly isn't. Your viewpoint is clouded by too much immersion in
> > crippled languages. *Old and obsolete versions* of crippled languages.
> > Dynamic creation of functions goes back to the 1950s.
> >
> > Functions in Python are *first class values*, just like ints, strings, lists
> > etc. That means functions can be passed around as arguments, assigned to
> > variables, returned from functions, and created on the fly as needed. This
> > is not an innovation from Python -- Python rarely, if ever, innovates. By
> > the time any feature hits Python (yes, even significant indentation) it has
> > typically been proven in at least one other language.
> >
> > Languages with first class functions include Perl, Javascript, Lua, PHP,
> > Tcl/Tk, Io, Go, Rust, Maple, Mathematica, Smalltalk, Swift, and varied mix
> > of old (Smalltalk and Perl) and new (Rust and Swift).
> >
> > It is almost unthinkable to imagine a functional programming language
> > without this feature, and sure enough Scala, Haskell, ML, Clojure, and
> > Scheme have it -- as does Lisp, which is the second oldest high level
> > language in existence. Only Fortran is older.
> >
> > Delphi (a variant on Pascal/Algol) has supported them since 2009. C++, C#
> > and Objective C have support for first class functions. Even Java 8 and
> > above includes this feature.
> >
> > In 2015, it's hard to think of any non-obsolete, non-toy language which
> > doesn't treat functions as first-class values, including creating them on
> > the fly. Fortran and C perhaps.
> 
> It's funny then that the vast majority of top-level function definitions 
> I see in Python (and import and class statements too) are decidedly static.
> 
> The names are declared, but the names are rarely bound to anything else. 
> Functions are just called the same boring way they are in C.
> 
> /They might as well be static definitions/.
> 
> (In fact, all this dynamic set-up, while it makes for an elegant and 
> consistent language, probably also makes it unnecessarily harder to 
> accelerate.)
> 
> Clearly a huge amount of programming can be done without having to deal 
> with first-class functions (or constructing functions at run-time; that 
> sounds fun). (Or without using OOP, another thing I can't stand.)
> 
> Some people just don't want to be functional programmers. It is elitist 
> to try and make out it that it is that important.
> 
> If lots of languages now have functional features, it's more likely to 
> be a case of keeping up with the Joneses.

I almost started to explain about how yes, Python is often written in
conservative static ways. I was going to mention that a little dynamic
nature goes a long way, and is never far from the surface in even the
simplest Python programs.

But I won't, because I'm not sure you're really interested.  There's a
pattern here of people trying to explain Python to you, and eventually,
after many words, getting to some kind of shared understanding, only
for you to shrug it all off as a fad, or pocket-lining, or needless
complexity.

For someone who claims to be interested in language design, you're
remarkably dismissive of pretty much the entire industry.  I don't think
it's worth the effort to try to change your mind.

--Ned.