Lambda: the Ultimate Design Flaw

[Sunnan]

Boring code is code that numbs your senses with constant flow of
boilerplate crap, memory management and redundant type declarations
and general blah blah that you skip when you are trying to figure out
what a piece of code does.

The python code I've read so far has looked like that. Not type
declarations, but loooong class declarations.

Also, Guido recently urged people to explicitly write recursions rather
than to use reduce - which I thought was completely in line with what
I've seen as python's goals: readability/understandability as more
important than terseness/non-boringness.

> It's a code that you wish you could train a
monkey to write for you while you go for lunch. Think C++ or Java.

Oh, yes. C++ and Java can be super boring. C++ can also be pretty hard
to understand - it's not all boilerplate.

I'm not saying Python is always boring (maybe I've just been in an
easily bored mood when I've read Python stuff), and I'm not saying that
boring is always bad.

Yesterday, I read some marketing prop describing a proprietary IDE
(don't remember what language) as "exciting", and I went "Ugh, no
thanks! Give me calm computing." And then I thought - wait: I just
ranted about boringness on comp.lang.python. Can't boring and calm
sometimes mean the same thing?

 

[Ville Vainio]

Sunnan> Ville Vainio wrote:

Sunnan> Also, Guido recently urged people to explicitly write
Sunnan> recursions rather than to use reduce - which I thought was
Sunnan> completely in line with what I've seen as python's goals:
Sunnan> readability/understandability as more important than
Sunnan> terseness/non-boringness.

The problem w/ reduce is that it's not intuitive. You'll have to stop
to think what the code w/ reduce does - effectively converting it to a
normal loop (not recursion!) in your head. It's a net loss when you
compare it to just reading an explicit loop as written in code.

Sunnan> Yesterday, I read some marketing prop describing a
Sunnan> proprietary IDE (don't remember what language) as
Sunnan> "exciting", and I went "Ugh, no thanks! Give me calm
Sunnan> computing." And then I thought - wait: I just ranted about
Sunnan> boringness on comp.lang.python. Can't boring and calm
Sunnan> sometimes mean the same thing?

Not for me at least. 'Boring' implies a certain sense of frustration,
not getting anywhere and generally feeling like you are wasting your
time. Human attention is a limited resource, and being bored leads to
loss of attention.

 

[Michele Simionato]

Sunnan:

The python code I've read so far has looked like that. Not > type

declarations, but loooong class declarations.

What do you mean? Lots of repetitive
"self.variable=variable" in the __init__ method? Use of classes when
you would use closures? Or maybe you
are comparing with CLOS classes, which are pretty
slim, since the (multi)methods are defined outside
them?

Michele Simionato

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Aahz]

[François]

Many of us are using Python today, week after week, year long. So
let's be pragmatic. Python is what it became and now is. Let's not
define it as a memory from the past nor as a futuristic dream.

You're free to continue using 1.5.2. [...]

Sure, of course. Yet, our friendly argument is sliding away from was it
originally was. The point was about not asserting in this forum that
Python "has only one way to do it", because this is not true anymore.

The principle has been, it may be back in some distant future, but now
it is not.

 

[Scott David Daniels]

You just can't have your cake and eat it, too.

I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.

-Scott David Daniels
(e-mail address removed)

 

[Simon Brunning]

I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.

Clearly you're just not trying. ;-)

 

[bruno modulix]

Aahz wrote:
(snip)


Is the space added automatically? (Like awk does, if you add a comma.)

Yes. But you can also format it how you like:
print "foo is %s and that's a good news, my friends" % foo

 

[John J. Lee]

Clearly you're just not trying. ;-)

))


John

 

[Greg Ewing]

Sunnan> It's just that I'm having a hard time matching that quote
Sunnan> to what I though python was about. I thought boring code
Sunnan> was considered a virtue in python.

There's a difference between unsurprising and boring.
The coffee I drank this afternoon, for instance, did
not surprise me, but I still enjoyed it.

 

[Greg Ewing]

I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.

You need to recursively subdivide the cake until
you have a piece small enough to fit in your input
buffer. Then the atomicity of the cake-ingestion
operation will become apparent.

 

[Aahz]

[Aahz]

[François]

Many of us are using Python today, week after week, year long. So
let's be pragmatic. Python is what it became and now is. Let's not
define it as a memory from the past nor as a futuristic dream.

You're free to continue using 1.5.2. [...]

Sure, of course. Yet, our friendly argument is sliding away from was it
originally was. The point was about not asserting in this forum that
Python "has only one way to do it", because this is not true anymore.

The principle has been, it may be back in some distant future, but now
it is not.

You're conflating two different things:

* Whether Python currently has only one way to do things

* Whether Python has a design goal of only one way to do things

I'll agree that Python currently has many examples of more than one way
to do things (and even Python 3.0 won't remove every example, because
anything more complicated than a Turing Machine has more than one way to
do things). But I won't agree that Only One Way has been abandoned as a
design principle.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

 

[Bill Mill]

You need to recursively subdivide the cake until
you have a piece small enough to fit in your input
buffer. Then the atomicity of the cake-ingestion
operation will become apparent.

+1 QOTW

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Aahz]

I'll agree that Python currently has many examples of more than one
way to do things (and even Python 3.0 won't remove every example
[...]). But I won't agree that Only One Way has been abandoned as a
design principle.

To summarize, instead of saying "Python has only one way to do it",
rather say "Python will eventually have only one way to do it", and with
such a wording, nobody will not be mislead.

 

[Ron_Adam]

You're conflating two different things:

* Whether Python currently has only one way to do things

* Whether Python has a design goal of only one way to do things

I'll agree that Python currently has many examples of more than one way
to do things (and even Python 3.0 won't remove every example, because
anything more complicated than a Turing Machine has more than one way to
do things). But I won't agree that Only One Way has been abandoned as a
design principle.

I would add that the meaning is:

Python has one obvious best way to do things.

Meaning that the most obvious and clearest way, the way that comes to
mind first, will in most cases, also be the best way.

I seem to remember reading it put in that way some place at some time.

 

[Robin Becker]

You need to recursively subdivide the cake until
you have a piece small enough to fit in your input
buffer. Then the atomicity of the cake-ingestion
operation will become apparent.

Ok course according to Tarski we can cut the cake up so it increases in volume.
The slices have to be immeasurable, but the final volume can be almost anything.
I bet that makes cake buffering harder to plan for.

-paradoxically yrs-
Robin Becker

 

[Steve Holden]

Ok course according to Tarski we can cut the cake up so it increases in
volume.
The slices have to be immeasurable, but the final volume can be almost
anything.
I bet that makes cake buffering harder to plan for.

-paradoxically yrs-
Robin Becker

Not at all - we just apply the same division techniques to the buffer
space until we can map the pieces of cake one-to-one onto the buffers.

stick-that-in-your-cakehole-ly y'rs - steve

 

[Frank Wilde]

alex goldman wrote:

The fault of goto in imperative languages is that it has no
arguments, thus creating spaghetti of gotos and assignments.

Continuations rule!

While continuations are a very interesting abstraction, the improvement
of structured programming was to be able to prove properties of your
programs in time linear to the size of the program instead of quadratic.
I don't see how giving arguments to the GOTO would help there.

Ciao,
Perle

 

[Michael Spencer]

Not at all - we just apply the same division techniques to the buffer
space until we can map the pieces of cake one-to-one onto the buffers.

That technique can be applied to layer cakes, but not all real cakes.

Michael

 

[Aahz]

[Aahz]

I'll agree that Python currently has many examples of more than one
way to do things (and even Python 3.0 won't remove every example
[...]). But I won't agree that Only One Way has been abandoned as a
design principle.

To summarize, instead of saying "Python has only one way to do it",
rather say "Python will eventually have only one way to do it", and with
such a wording, nobody will not be mislead.

Let's go back to the original comments, shall we?

> [...] for Pythons ideal of having one canonical, explicit way to
> program.

No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.

Your claim that the ideal has been abandoned is just plain wrong. In
addition, nobody has ever said "Python has only one way to do it". The
actual principle from ``import this`` is

There should be one-- and preferably only one --obvious way to do it.

Some people have advocated that Python's motto should be "There's Only
One Way" as a counterpoint to Perl's TMTOWTDI -- but that's different
from the design principle. Which I repeat has not been abandoned, but
should be understood to exist alongside eighteen other design principles
for Python.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

 

[Terry Reedy]

You're conflating two different things:

* Whether Python currently has only one way to do things

* Whether Python has a design goal of only one way to do things

I'll agree that Python currently has many examples of more than one way
to do things (and even Python 3.0 won't remove every example, because
anything more complicated than a Turing Machine has more than one way to
do things). But I won't agree that Only One Way has been abandoned as a
design principle.

The statement in the Zen of Python is "There should be one-- and
preferably only one --obvious way to do it." The splits into two related
statements:
There should be [at least] one obvious way to do it.
There should preferably be only one obvious way to do it.

Commentary:

While 'should' can mean 'must', it can also mean something something
softer, like desireability and preference. In Pythonese, it has (as far as
I know) such softer meanings, with 'must' used when 'must is meant. In
the second sentence, preference is made explicit.

The presence of 'obvious' is obviously not accidental. Without it, and
with 'should' replaced with 'must', we eventually end up with any of
numerous simple, possibly interesting, and mostly practically useless
Turing-equivalent systems. The qualifier 'obvious' does not exclude
non-obvious ways. For example, the obvious way, in Python, to add 1 and 2
to get 3 is '1+2'. Two non-obvious (certainly for the beginner) ways are
'1 .__add__(2)' [space required] and 'import operator; operator.add(1,2)'.

Unfortunately, 'obvious' too often get elided in the discussion of this
principle. For some, its because it is so obviously needed that it seems
to not need to be said. For others, it appears to be because they are not
fully cognizant of it. The result can be people talking past each other.
And, of course, obviousness is somewhat in the mind of the beholder.

The first sentence provides impetus to add new features that 'should be'
present but are not. At this point, that mostly means new library modules.

The second principle inhibits (but not absolutely prevents) adding
'obvious' redundancy. When exceptions are made, the principle of not
breaking code prevents deleting the old except after a while and very
occasionally. The inhibitory principle does encourage attempts to relegate
the old to a less obvious status by treatments in the tutorial and manuals.

The inhibitory principle is certainly still alive. Function decorators
barely made it past. The proposal to extend them to classes has so far
been rejected by GvR since class decorators seem redundant with
metaclasses. And lots else has been ignored or rejected.

Terry J. Reedy