By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,269 Members | 1,509 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,269 IT Pros & Developers. It's quick & easy.

How do I dynamically create functions without lambda?

P: n/a
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)

Jan 27 '06 #1
Share this Question
Share on Google+
25 Replies


P: n/a
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


It doesn't exist, yet. Python 3000 isn't even in planning stages, yet. There are
just some loose ideas floating around about what will (and won't!) be in it.

You can't write Python 3000 compliant code right now because there is nothing to
comply with.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jan 27 '06 #2

P: n/a
"Russell" <ru************@hotmail.com> writes:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated.


Nobody knows yet what Python 3000 will change, so relax.
Jan 27 '06 #3

P: n/a

Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Kay

Jan 27 '06 #4

P: n/a
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


Is this what you mean?

# making functions partially bound with foo, dynamically

def make_newfunc(foo):
def _newfunc(x, f=foo):
print x, foo
return _newfunc

foo = 42

newfunc = make_newfunc(foo)

newfunc()
Jan 27 '06 #5

P: n/a
Kay Schluehr wrote:
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)

If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Kay

For anyone who got my last post: sorry, typos....
def f(foo, x):
print foo, x

def make_newfunc(foo):
def _newfunc(x, foo=foo):
f(foo, x)
return _newfunc

foo = 42 # or "dynamically generated"

newfunc = make_newfunc(foo)

newfunc(14) # output will be "42 14"

newfunc2 = make_newfunc(69)

newfunc(21) # output will be "69 21"
If this doesn't fit your needs, then please elucidate.
Jan 27 '06 #6

P: n/a
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

That's nonsense! A lambda function *IS* a nested function, and has *NO*
extra capabilities over a nested function. If you can do something with
a lambda, you can also do it with a nested function defined at the same
point. However, a nested function *does* give you several extra
capabilities: (1) it has a name rather than being anonymous like the
lambda, and (2) the body can use statements rather just one expression.

So use a nested function. You'll get the same capabilities, plus a
name, plus more expressive power in the body. You won't lose anything.
and your code will survive any eventual removal of the lambda functionality.
Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


Jan 27 '06 #7

P: n/a
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.


I don't understand this argument here. The code above is almost exactly
equivalent to:

def newfunc(x):
return f(foo, x)
someobject.newfunc = newfunc

Observe:
class C(object): .... pass
.... someobject = C()
someobject.newfunc = lambda x: f(foo, x)
import dis
dis.dis(someobject.newfunc) 1 0 LOAD_GLOBAL 0 (f)
3 LOAD_GLOBAL 1 (foo)
6 LOAD_FAST 0 (x)
9 CALL_FUNCTION 2
12 RETURN_VALUE def newfunc(x): .... return f(foo, x)
.... someobject.newfunc = newfunc
dis.dis(someobject.newfunc)

2 0 LOAD_GLOBAL 0 (f)
3 LOAD_GLOBAL 1 (foo)
6 LOAD_FAST 0 (x)
9 CALL_FUNCTION 2
12 RETURN_VALUE

Note that both the lambda and the function have exactly the same
byte-code. The only real difference is that if you use a def-statement
instead of a lambda, your function will get a real name, "newfunc",
instead of <lambda>.

STeVe
Jan 27 '06 #8

P: n/a
On Fri, 27 Jan 2006 11:41:56 -0800, Kay Schluehr wrote:

Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Fascinating. A couple of thoughts:

- I really wish that people would make up their minds about what currying
is, and how it differs from partials and closures. If the people who
do know can't agree, how do they expect the rest of us to understand?

- What, if anything, is the difference between a closure and an iterator?
Is an iterator just a closure wrapped up with an API?

- The first sample code seems needlessly confusing to me. It gives:

class partial(object):
def __init__(*args, **kw):
self = args[0]
self.fn, self.args, self.kw = (args[1], args[2:], kw)
def __call__(self, *args, **kw):
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kw
return self.fn(*(self.args + args), **d)

It seems to me to needlessly break the convention that the first argument
is self, to no benefit and considerable reduction in clarity. After some
experimentation, I worked out what it was doing, and realised that it
would work just as well but much less obscurely if the __init__ function
was written as:

def __init__(self, fn, *args, **kw):
self.fn, self.args, self.kw = fn, args, kw
- It seems a shame to me that having created a partial _function_ using
that technique, type(partial(...)) returns <class partial>. It would be
nicer if the type made it more obvious that the instance was callable.
Something like <callable class partial> perhaps? Is there any way for a
class to customise the type representation?

--
Steven.

Jan 28 '06 #9

P: n/a
Steven D'Aprano wrote:
On Fri, 27 Jan 2006 11:41:56 -0800, Kay Schluehr wrote:
Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-) If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Fascinating. A couple of thoughts:

- I really wish that people would make up their minds about what currying
is, and how it differs from partials and closures. If the people who
do know can't agree, how do they expect the rest of us to understand?


Me too, but I disagree with the people who won the argument on the name.
Curry derives its name from the mathematician who formulated the
Curry-Howard isomorphism that says a function of multiple arguments
can be expressed as a function taking a single argument which returns a
function which takes a single argument which... takes a single argument
and returns the result of the original multi-argument function. This
isomorphism means that you need only define functions which take single
arguments. In some functional languages, functions are called adjacent
to their arguments, and a function which looks like it takes multiple
arguments is actually taking a single argument of a tuple.

The Curry recipe I put in the Python Cookbook did the analogous thing
for the Python language, since there is no way for a "Curry" argument
to know when to call the underlying function, rather than simply
accumulate arguments.
- What, if anything, is the difference between a closure and an iterator?
Is an iterator just a closure wrapped up with an API?
A closure is a function and the environment it was created in.
So, for example, the result of calling:

def multiplier(n):
def result(m):
return n * m

multiplier(2) returns a closure (the function called result and its
environment where n is set to 2).

An iterator is a different beasty.
- The first sample code seems needlessly confusing to me. It gives:

class partial(object):
def __init__(*args, **kw):
self = args[0]
self.fn, self.args, self.kw = (args[1], args[2:], kw)
def __call__(self, *args, **kw):
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kw
return self.fn(*(self.args + args), **d)

It seems to me to needlessly break the convention that the first argument
is self. Actually, it does, but only because the second doesn't break it as well.
to no benefit and considerable reduction in clarity. After some
experimentation, I worked out what it was doing, and realised that it
would work just as well but much less obscurely if the __init__ function
was written as:

def __init__(self, fn, *args, **kw):
self.fn, self.args, self.kw = fn, args, kw
It would pretty much work like this, _but_ you could not used named args
of self or fn when using one of these things.

A better definition:
class partial(object):
def __init__(*args, **kw):
self = args[0]
self.fn, self.args, self.kw = (args[1], args[2:], kw)
def __call__(*args, **kw):
self = args[0]
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kw
return self.fn(*(self.args + args[1:]), **d)

Now you can, for example:

def function(self, other, fn):
return fn([self, other])

defaults = partial(function, self=object(), fn=repr)
print defaults(other=3), defaults(self='self', other=3)

The fancy-schmancy stuff is to keep from hiding some names. I suspect
both args and kw have this problem as well. It might have been
reasonable to call them __self, __function, __args, and __kwargs
and do it your way.
- It seems a shame to me that having created a partial _function_ using
that technique, type(partial(...)) returns <class partial>. It would be
nicer if the type made it more obvious that the instance was callable. But callable(defaults) returns True. You will eventually learn that
partial is callable, just as you know "type"s are callable. Seeing
that it is class partial, you can (if you are nosey), see what the
arguments already provided are (so you could get a nicer print).
For example, adding a method to partial:

def __repr__(self):
return 'partial(%r, *%r, **%r)' % (self.fn, self.args, self.kw)
Something like <callable class partial> perhaps? Is there any way for a
class to customise the type representation?


--
-Scott David Daniels
sc***********@acm.org
Jan 28 '06 #10

P: n/a
Steven D'Aprano wrote:
On Fri, 27 Jan 2006 11:41:56 -0800, Kay Schluehr wrote:

Russell wrote:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)
If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Fascinating. A couple of thoughts:

- I really wish that people would make up their minds about what currying
is, and how it differs from partials and closures. If the people who
do know can't agree, how do they expect the rest of us to understand?


If they can't agree they probably don't know ;)

Concepts like "closure" and "currying" are well defined in lambda
calculus and hence in functional programming.
- What, if anything, is the difference between a closure and an iterator?
Is an iterator just a closure wrapped up with an API?


I would expect a closure to be a function with free/unbound variables
that are bound by an enclosing context. In FP slang a function without
any free variables is called a "combinator". An iterator is a function
related to an abstract data type equipped with a partial order. The
iterator abstracts from the particular ordering scheme and makes the
ADT look like a list. In Python we have a nice correspondence between
generators as implicit defined sequences of yielded values, iterators
that enable uniform access to the values produced by generators and
lists that make the sequence explicit ( if finite ).

Fun with combinators
======================
There are quite interesting relationships deep down in the theory of
computation. For instance understanding recursion in lambda calculus is
not that easy because you cannot simply reintroduce an anonymous
function by the name into its own body. The idea is to create a
fixpoint of a higher order curried function instead. See for example
this curried extension of a factorial:

F = lambda h: lambda n : n<2 and 1 or n*h(n-1)

Now imagine you have a fixpoint fix(F) of F which is again a function
and pass it into F then you will get:

fix(F) = F(fix(F)) = lambda n : n<2 and 1 or n*fix(F)(n-1)

That is fix(F) is actually the searched factorial ! There is a generic
way to create fixpoints of higher order curried functions such as F.
The most popular one is the so called Y-combinator ( not to confuse
with Paul Grahams company ;).

In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Kay

Jan 28 '06 #11

P: n/a
On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]
In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees? You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?

--
Steven.

Jan 28 '06 #12

P: n/a
Steven D'Aprano wrote:
On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]
In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees?


Probably not. But the good thing about Y is that it is in closed form
and the expression is not infinitely long. By the way I have no less a
hard time to read C code with advanced data-structures and many type
casts which is much more likely to happen in the "real world".
From what I've seen the only *practical* purpose fixpoint combinators serve is a kind of recursion "overloading". Without modifying F one can
memoize values by adapting the fixpoint combinator. We already know
something similar from the Go4 "command pattern" but there is no
self-referential entanglement and it is less general.
You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?


Ask a Scheme guy at LtU. Accuse the original author in Den Haag and if
caught put him to shame by making photos at a dentist. Google for
"lambda calculus Y". Ask someone here at comp.lang.python. Ask your
boss for more time ;)

Kay

Jan 28 '06 #13

P: n/a
Op 2006-01-27, Russell schreef <ru************@hotmail.com>:
I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newfunc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.
I don't see how dynamic is supposed to contradict with
nested functions. I assume from your tekst that foo
has some parameter-like charateristics. So the following
should work.

def produce(foo):

def func(x):
return f(foo, x)

return func
someobject.newfunc = produce(foo)
This kind of code can be generalized. Look for partial
application or curry.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)


The new and shiny, pythonic way depends on what you
really want, your question was a bit vague to answer
that.

--
Antoon pardon
Jan 30 '06 #14

P: n/a
In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]
In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees? You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?


Excessive cleverness can lead to unmaintainable code. So can excessive stupidity.
Since there are a lot more stupid people than clever people out there I think
the more likely scenario is having to maintain unmaintainable code written by a
complete idiot whose programming knowledge comes solely from books whose titles
end with "In 7 Days".

Oh, and I'd hope that code reviews, etc. would have kept lambda-boy from getting
too far down this path of self invocation.

Alan
--
Defendit numerus
Feb 1 '06 #15

P: n/a
Alan Morgan <am*****@xenon.Stanford.EDU> wrote:
...
Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.
+1 QOTW.
Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".


Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.
Alex
Feb 2 '06 #16

P: n/a
Alex Martelli wrote:
Alan Morgan <am*****@xenon.Stanford.EDU> wrote:
...
Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.

+1 QOTW.

++
Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".

Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.


Just as 85% of drivers believe their skill level is "above average".

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Feb 2 '06 #17

P: n/a
In article <1h****************************@yahoo.com>,
Alex Martelli <al*****@yahoo.com> wrote:
Alan Morgan <am*****@xenon.Stanford.EDU> wrote:
...
Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.
+1 QOTW.


import blush
Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".


Disagree -- far more people THINK they're clever, than really ARE
clever.


No doubt about it, but I don't see how it contradicts my statement.
According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.


I wonder if python, which has a low barrier to entry due to its simple syntax
and general readability, might not have a worse time of this than other languages.

Alan
--
Defendit numerus
Feb 2 '06 #18

P: n/a
Alex Martelli wrote:
Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.


It's apparently no different anywhere:
http://www.phule.net/mirrors/unskilled-and-unaware.html
--
Benji York
Feb 2 '06 #19

P: n/a
Benji York <be***@benjiyork.com> wrote:
Alex Martelli wrote:
Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.


It's apparently no different anywhere:
http://www.phule.net/mirrors/unskilled-and-unaware.html


Tx. Maybe it's a genetically adaptive trait: the FT points out that
while there is little correlation between an employee's opinion of their
skills, and the employee's actual performance, there IS positive
correlation between said opinion and the employee's career advancement.
One way to explain the correlation is: if you truly (albeit perhaps
mistakenly) believe you're great, you project that and are more likely
to get promotions or raises, than is somebody else, perhaps objectively
better, who's torn by self-doubt and projects THAT.

My working hypothesis would be that this effect would be far stronger in
fields where it's hard to get hard quantitative measures of performance,
so the managers (or clients, etc) rely to a large extent on subjective
judgment which can be influenced by such "projections"...
Alex

Feb 3 '06 #20

P: n/a
Alan Morgan <am*****@xenon.Stanford.EDU> wrote:
...
Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".


Disagree -- far more people THINK they're clever, than really ARE
clever.


No doubt about it, but I don't see how it contradicts my statement.


The problem comes with the ones who aren't clever, think they are, and
attempt cleverness.

According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.


I wonder if python, which has a low barrier to entry due to its simple
syntax and general readability, might not have a worse time of this than
other languages.


So far, no, according to all the people I often exchange chat on such
experiences with. E.g., I was a panelist at SDForum the other day, the
moderator was Alexandra Weber Morales (until recently head editor of SD
Magazine, she's a freelance now), and she confirmed that Python
programmers still have the highest median and average salaries
(VisualBasic ones, the lowest), a strong indicator that they ARE good.

[[ Surprisingly, from all anecdotal experiences I hear about, the new
"digital peons" after VB programmers appear to be J2EE coders (I use the
word deliberately: people who _architect_, or even just _design_, J2EE
apps, are on a different plane -- people who _code_ J2EE apps are the
ones laboring long hours for low salaries, it seems). And, from
somebody who desperately needs to hire a small number of stellar-quality
Java experts, I've heard strong anecdotal confirmation: candidates who
tout their "J2EE" are much more likely to be "mindless code drones" than
ones who just focus in their resume on "Java". I don't understand J2EE
well enough to even guess at an explanation of why that might be so. ]]

Paul Graham makes the same point: if you're an entrepreneur with a
startup just ramping up, you'll get much abler people if you're looking
for Lisp or (failing that) Python programmers, than if you look for Java
programmers (he fails to distinguish between "Java" and "J2EE").

Now Lisp (or Haskell, etc) I could easily see. But why should Python
tend to correlate with "high skill", when, as you point out, it's in
fact _simpler_?! My current working hypothesis: Python has never been
marketed and hyped the way Java and C# &c have; somebody who CHOOSES
Python shows some ability to think for themselves, rather than following
the herd, and such ability correlated with programming skill. Note that
this hypothesis is reasonably independent of whether Python is a great
language or not: it would apply equally well to any language that has
never been substantially hyped/marketed. But there are probably too few
programmers who identify as, say, "D programmers", "Eiffel programmers",
etc, to show up in SD's statistics, while Python's starting (gradually,
and mostly "by word of mouth") to register on their radar...
Alex
Feb 3 '06 #21

P: n/a
al*****@yahoo.com (Alex Martelli) writes:
Now Lisp (or Haskell, etc) I could easily see. But why should Python
tend to correlate with "high skill", when, as you point out, it's in
fact _simpler_?! My current working hypothesis: Python has never been
marketed and hyped the way Java and C# &c have; somebody who CHOOSES
Python shows some ability to think for themselves, rather than following
the herd, and such ability correlated with programming skill.


Python also has a type of beauty to it (despite warts here and there),
so someone who chooses it probably has better attunement to
well-designed software than someone who chooses an uglier but equally
obscure language. That attunement would correlate with skill.
Feb 3 '06 #22

P: n/a
On Thu, 2 Feb 2006 20:05:14 -0800
al*****@yahoo.com (Alex Martelli) wrote:
Benji York <be***@benjiyork.com> wrote:
Alex Martelli wrote:
Disagree -- far more people THINK they're clever, than
really ARE clever. According to a recent article in
the Financial Times, over 40% of a typical financial
firm's employees firmly believe they are among the 5%
best employees of the firm -- and the situation,
believe me, is no different in programming.


It's apparently no different anywhere:
http://www.phule.net/mirrors/unskilled-and-unaware.html


I have to say, I've read this paper, and it's pretty bad
science. I think they seriously over-interpreted their
data. There are a lot of different ways to interpret the
data they present, and it takes a fair amount of sophistry
for them to come up with it "supporting" their hypothesis.

Which doesn't *disprove* the idea, but I remain unconvinced
by their reasoning. No doubt the effect they describe is
not non-existant, but I question whether it has as much
impact as proposed.

Note also in the datasets that *overperformers* *underrated*
their performance.

Also, the research was done on *particularly* subjective
subject matter! Take the "humor" category for example.

I also think this is precisely the kind of experiment that
has to be made *very* objective to be at all useful. It's so
easy to sensationalize: it plays on your self-worth fears,
your cynicism, and your arrogance *at the same time*. It's
hard to imagine that anyone accepting the results is doing
so for scientific reasons.

Frankly this paper sounds like a bid for the "Journal of
Irreproducible Results" that somehow got accidentally
submitted to a serious journal (of course, I don't know
enough about psychology journals to know if that is really
a "serious journal", but I'm taking it at face value).

Of course, you *could* conclude that I'm just "unskilled and
unaware of it" for believing this -- but that's the beauty
of all self-reinforcing delusions, isn't it. ;-)

Cheers,
Terry
--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Feb 3 '06 #23

P: n/a
Terry Hancock wrote:
Frankly this paper sounds like a bid for the "Journal of
Irreproducible Results" that somehow got accidentally
submitted to a serious journal


http://www.improbable.com/ig/ig-pastwinners.html#ig2000

</F>

Feb 3 '06 #24

P: n/a
Terry Hancock wrote:
Note also in the datasets that *overperformers* *underrated*
their performance.


Well, if you're the best in the group and aren't perfectly exact
in your evaluation of your position relative to others, you can't
overrate yourself. It's quite natural that the self evaluation curve
would be flatter than the actual curve, since "noise" will drive
the curve towards the middle, and it's also natural that the bad
performers are also less good at evaluating their own work, but
the strange thing is that the lowest quartile has higher self-
evaluation than the second lowest. I can't say my general picture
of coworkers generally support *this*, but I supect we've all run
across people who were incompetent and unaware of it now and then...
Feb 3 '06 #25

P: n/a
On Fri, 3 Feb 2006 09:39:39 +0100
"Fredrik Lundh" <fr*****@pythonware.com> wrote:
Terry Hancock wrote:
Frankly this paper sounds like a bid for the "Journal of
Irreproducible Results" that somehow got accidentally
submitted to a serious journal

http://www.improbable.com/ig/ig-pastwinners.html#ig2000
</F>


Wow. It's a relief to know I'm not the only one who regards
this paper as a joke. :-)

Cheers,
Terry

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Feb 3 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.