assignment expression peeve

[Paul Rubin]

More likely it's the dreaded sequence point problem,
which, in its purest form, shows up in the C statement

arry = i++;

where there's no obvious way to decide which element of arry
is going to get the new value.

That's no big deal. The spec can explicitly say the order of
evaluation is not specified. In C,

a = f(g(x,y), h(z,w))

doesn't evaluate its args in a specified order either. You don't know
whether g or h will be called first. Programmers live with that.

 

[Paul Rubin]

Paragraph that defines some of its own words?

Seriously, you're comparing apples to oranges here. I'm comparing
syntax here, and there's nothing syntactical about metaclasses. If
you want to compare a class statement to natural language, that works.

Actually, assignment expressions happen in natural language too.
In English you could say "A guy named Bob walks into a bar".
In Python with assignment expressions, you'd write

bar.enter(bob := Guy())

Without assignment expressions you'd have to say something like

bob = Guy()
bar.enter(bob)

which in English would be two sentences:

"There's a guy named Bob. Bob walks into a bar."

As I see it, the one-sentence, assignment-expression version is
perfectly natural and less stilted-sounding in normal conversation.

 

[Andrew Dalke]

Paul Rubin

Actually, assignment expressions happen in natural language too.
In English you could say "A guy named Bob walks into a bar".
In Python with assignment expressions, you'd write

bar.enter(bob := Guy())

Without assignment expressions you'd have to say something like

bob = Guy()
bar.enter(bob)

Well that's a stretch. How would you write the code for
"A guy walks into a bar. His name is Bob."
"Bob, a guy, walks into a bar"
"A guy walks into a bar. 'Hi Bob', says the tender upon seeing him."
"As the guy walks into the bar he pulls off his conference name tag
with it's disgustingly chirpy 'Hi, my name is Bob' annoucement.
He needs a drink. Now."
"Like all other guys that Guy Fawkes day, Bob bobbed into Bob's Bar."
"Two nuns walk into a bar. Third one ducks."

Err, sorry, got carried away with the last ones.

Andrew
(e-mail address removed)

 

[Alexander Schmolck]

More likely it's the dreaded sequence point problem,
which, in its purest form, shows up in the C statement

arry = i++;

where there's no obvious way to decide which element of arry
is going to get the new value.

That's no big deal. The spec can explicitly say the order of
evaluation is not specified. In C,

a = f(g(x,y), h(z,w))

doesn't evaluate its args in a specified order either. You don't know
whether g or h will be called first. Programmers live with that.

Sure, it's also no big deal that the C software I have to uses segfaults every
now and then (I'm sure the spec says so somewhere). Users live with that.

'as

 

[Carl Banks]

Actually, assignment expressions happen in natural language too.
In English you could say "A guy named Bob walks into a bar".
In Python with assignment expressions, you'd write

bar.enter(bob := Guy())

No. The English equivalent of "a=b" is "set a to b" or "let a equal
b" or something like that. Your construction "a named b" completely
fails to communicate that a's value becomes the same as b's.

Again, apples and oranges. You are comparing meanings, when the
problem is syntax. "A guy named Bob walks into a bar" and
"bar.enter(bob := Guy())" might have the same meaning, but they use a
diffenent syntax to convey it. And the latter uses a syntax with no
analogue in any natural language I know of.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Paul Rubin]

Again, apples and oranges. You are comparing meanings, when the
problem is syntax. "A guy named Bob walks into a bar" and
"bar.enter(bob := Guy())" might have the same meaning, but they use a
diffenent syntax to convey it. And the latter uses a syntax with no
analogue in any natural language I know of.

Whatever. You're the only programmer I've ever encountered who claims
to have actual trouble understanding assignment expressions. With
other people, the objection is that they can be confused with
comparison expressions, or that they're simply another
not-so-important feature that Python doesn't need.

 

[Donn Cave]

Quoth Paul Rubin <http://[email protected]>:
|> Again, apples and oranges. You are comparing meanings, when the
|> problem is syntax. "A guy named Bob walks into a bar" and
|> "bar.enter(bob := Guy())" might have the same meaning, but they use a
|> diffenent syntax to convey it. And the latter uses a syntax with no
|> analogue in any natural language I know of.
|
| Whatever. You're the only programmer I've ever encountered who claims
| to have actual trouble understanding assignment expressions. With
| other people, the objection is that they can be confused with
| comparison expressions, or that they're simply another
| not-so-important feature that Python doesn't need.

They are an impediment to understanding, says the second programmer.

If there were some way to support the functionality you wanted
there, and ONLY as represented in your example, then the impediment
would not be a severe one, and the only question would be whether
such a trivial gain is worth the bother. I think the class wrapper
work-arounds, as proposed in your initial post and one or two
follow-ups, are better, so it's no gain at all in my eye.

But when you can say

if g := match(a, b):

then I suspect you will also be able to say things like -

if not (dv := start() and f := nfile(dv)
and ((t := f.find("--") > 0 and fx = f[:t]) or (fx = f))):
print "Well, bless me!"

Of course no one would do such a thing. I translated this from C code
written by someone who is a far more accomplished programmer than I,
whose name I know you would recognize. (Identifiers etc. changed to
protect the not-entirely-innocent.)

Donn Cave, (e-mail address removed)

 

[anton muhin]

Paul Rubin wrote:

No. The English equivalent of "a=b" is "set a to b" or "let a equal
b" or something like that. Your construction "a named b" completely
fails to communicate that a's value becomes the same as b's.

I cannot agree, especially when Python is concerned: Python assignment
just copies references, therefore, it's rather direct counterpart for
'Bill guy' example.

best regards,
anton.

 

[Bengt Richter]

OK, I want to scan a file for lines matching a certain regexp. I'd
like to use an assignment expression, like

for line in file:
if (g := re.match(pat, line)):
croggle(g.group(1))

Since there are no assignment expressions in Python, I have to use a
temp var. That's a little more messy, but bearable:

for line in file:
g = re.match(pat, line)
if g:
croggle(g.group(1))

It gets annoying when there are 4 different regexps that the line
might match, and I want to do something different depending on which
one matches. That's not that uncommon a text scanning situation.
With assignment expressions, it's a very natural if/elif chain:

for line in file:
if g := re.match(pat1, line):
croggle(g.group(1), 17)
elif g := re.match(pat2, line):
x = mugwump(g.group(3))
y = wumpus(g.group(2))
return defenestrate(x, y+3)
elif g := re.match(pat3, line):
# do something completely different with groups of g
elif g := re.match(pat4, line):
# more of the same

I posted a "holder" class a fairly long time ago that I'd use (untested code here):

class Holder(object):
def __call__(self, *v) # v is () or (the_value,)
if v: self.v = v[0]
return self.v

value = Holder() # as many as you need simultaneous recall of distinct expressions

for line in file:
if value( re.match(pat1, line) ):
croggle(value().group(1), 17) # or you could use a short name: len('h()') == len('h.v') ;-)
elif value( re.match(pat2, line) ):
x = mugwump(value().group(3))
y = wumpus(value().group(2))
return defenestrate(x, y+3)
elif value( re.match(pat3, line) ):
# do something completely different with groups of g
elif value( re.match(pat4, line) ):
# more of the same

Without assigment expressions, it gets unspeakably ugly. You have to
use a deeply nested if/else if sequence where you match the regexp and
test the result on 2 separate lines at each branch, or reorganize the
code to use some kind of dispatch table (good if there's a lot more
than 4 regexps, but overkill for just 4), or whatever. I ended up
creating a special class instance just to match a regexp and remember
the result, so I could write in the if/elif style.

This kind of regexp matching is a common pattern and I keep wanting
assignment expressions whenever I code it, and end up crocking up some
silly workaround.

Is the above what you did? You only need to do it once (although its
often easier to rwrite things like this than find where they're filed ;-)

Regards,
Bengt Richter

 

[Carl Banks]

Whatever. You're the only programmer I've ever encountered who claims
to have actual trouble understanding assignment expressions.

I really don't appreciate you putting words in my mouth, and I'm sorry
you feel the need to resort to dishororable tactics.

I claim assignment expressions are counterintuitive, and hard to read,
because they go against the grain of natural language. They require
more effort because we can't use the language parts of our brains to
help.

I've NEVER said there was any trouble understanding them. The trouble
is inputing them into our brains.

With other people, the objection is that they can be confused with
comparison expressions, or that they're simply another
not-so-important feature that Python doesn't need.

Bullshit. I'm not the only person to have said these things about
assignment expressions. And if you think there are no language
experts out there who think assignment expressions are a mistake,
you're deluded.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Carl Banks]

I cannot agree, especially when Python is concerned: Python assignment
just copies references, therefore, it's rather direct counterpart for
'Bill guy' example.

That's simply a flawed argument. I agree that Python's assignment
semantics make "set a to b" incorrect. But, that doesn't mean "a
named b" is right. "a named b" does not, by any stretch of the
imagination, communicate that a is being set to the value of b. In
order to be a lingusitic analogue, the phrase would have to
communicate that.

If you like, you can think of "a=b" as "set a to reference the value
of b".


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Alex Martelli]

Carl Banks wrote:
...

The real reason is that assignment expressions lead to all kinds of
ugly and unreadable code. This is because there is no linguistic
analogue for assignment as an expression. Things that work as

"""
Once upon a time, in a Kingdom far, far away, there was a
strong, corageous prince, who we'll call Richard, and his weak,
cowardly, but cunning younger brother, who we'll call John,
secretly hated and feated Richard and envied his strength.
One day, Richard and John set out on a fateful hunt in the woods
....
"""

Those clauses "who we'll call Richard" and "who we'll call John"
are exact natural-language equivalents of assignment-as-expression
(in a computer language with reference, not copy, semantics, of
course - but Python qualifies in this regard), or as close as
anything in natural language ever gets to computer languages.

Basically, I'm parentethically affixing a name to some entity
I'm describing, just so I can later use the name, rather than
some periphrasis, or a pronoun, with the well-known problems
that these can cause (computer languages don't have pronouns,
unless you want to consider perl's $_ as such perhaps....

Of course there are alternatives (aren't there always, most
particularly in natural language?), such as claiming that you're
just informing the reader of the prince's "actual" name (but if
the kingdom was so far away, it's believable that the prince's
actual name was too hard to pronounce for us and "Peter" is just
a pseudonym you're using for convenience;-) -- but values in
computer languages don't have "actual names", in this analogy,
just "pseudonyms" anyway.

I'm not necessarily dissenting with your detestation of
assignment-as-expression (although gradually I'm getting some
doubts about the general, overall wisdom of Python's strong
distinction between expressions and statements, that's a more
general and problematic issue). But I _am_ dissenting with
your specific claim that "there is no linguistic analogue"
for it in natural language.


Alex

 

[Paul Rubin]

I really don't appreciate you putting words in my mouth, and I'm sorry
you feel the need to resort to dishororable tactics.

I claim assignment expressions are counterintuitive, and hard to read,
because they go against the grain of natural language. They require
more effort because we can't use the language parts of our brains to
help.

What does it mean to be hard to read? Your eyes can't make out the
characters on the screen? Or your eyes can make out the characters,
but the meaning conveyed isn't immediately clear to you. If the
latter, that means you claim to have trouble understanding the
expressions.

They require more effort because we can't use the language parts of
our brains to help.

Some of us either manage to limit our use them to ways where this
isn't a problem, or else it just isn't an issue to begin with.

Frankly your thing about no natural language analog sounds like hot
air to me. Have you got an analysis of every natural language ever
spoken in the world, that finds no construct like that? And even if
you do, where is the slightest evidence that it makes any difference?
Even if it does take an extra millisecond of mental effort to parse
the assignment expression, a workaround resulting from not using it
(such as defining a new class and making an instance of it and calling
some operation on it), being may take 100 times as much effort.

 

[Carl Banks]

Carl Banks wrote:
...

"""
Once upon a time, in a Kingdom far, far away, there was a
strong, corageous prince, who we'll call Richard, and his weak,
cowardly, but cunning younger brother, who we'll call John,
secretly hated and feated Richard and envied his strength.
One day, Richard and John set out on a fateful hunt in the woods
...
"""

Those clauses "who we'll call Richard" and "who we'll call John"
are exact natural-language equivalents of assignment-as-expression
(in a computer language with reference, not copy, semantics, of
course - but Python qualifies in this regard), or as close as
anything in natural language ever gets to computer languages.

Basically, I'm parentethically affixing a name to some entity
I'm describing, just so I can later use the name, rather than
some periphrasis, or a pronoun, with the well-known problems
that these can cause (computer languages don't have pronouns,
unless you want to consider perl's $_ as such perhaps....

Ok, I disagree that this is a suitable analogue. I'll explain.

My contention is that a large part of what makes something "readable"
in code is that is it resembles, to some degree, natural language.
This is because we can use the parts of our brain that parse natural
language to help us parse code. Makes sense, pretty obvious.

The thing is, these analogues have to match syntactically as well as
semantically. In other words, if the language construct in question
does not have an analogue that matches syntactically, then we have to
acquire the ability to parse it. Furthermore, if it turns out that
our "language circuits" are not able to internalize an unusual syntax,
then parsing it will always require intellectual effort. (Whether
this is true of assignment expression I won't speculate at this
moment.) In the end, we have something that is at least harder to
learn, and possibly takes more effort to read.

Now, your example does manage to communicate the semantics of
assignment expression (unlike Rubin's example, which didn't
communicate that anything was being assigned). However, I would say
your example still is not a proper analogy, for a very simple reason:
most people read computer programs as imperative, while your example
is declarative.

I hope I don't have to argue the point that most people think of
programming as imperative. I believe programmers think of "a=b" as
"Set a to b," not "a's value becomes b's value". Therefore, I don't
consider a declarative clause to be an analogue of an assignment; it
is both syntactically and semantically different.

Now, the question is, is there any way, syntactically, to have an
imperative in a relative clause? If so, can it be set in a relative
clause such that the object is also the antecedent? Certainly you
could *communicate* that with a detailed enough explanation, but can
you do it with analogous syntax? I would say no.

Another argument is the drop-in argument. In programming languages,
you are typically able to drop an expression anywhere an expression is
valid. The natural langauge analogue of an expression is a noun
phrase, and as in programming languages, it is syntactically valid to
drop a noun phrase anywhere a noun is expected.

What about assignment expression? If you think of the programming
language as imperative, "a=b" would parse as "Set a to the value of
b." If declarative, "a=b" would parse as "a gets the value of b."
You cannot use either phrase as a noun phrase (you would have to
change them around). It follows that "a=b" is not suitable as an
expression.


[snip]

I'm not necessarily dissenting with your detestation of
assignment-as-expression (although gradually I'm getting some
doubts about the general, overall wisdom of Python's strong
distinction between expressions and statements, that's a more
general and problematic issue). But I _am_ dissenting with
your specific claim that "there is no linguistic analogue"
for it in natural language.

Well, sorry, I'm standing by it. However, it got me to thinking.
Even if it did have a solid linguistic analogue, I still wouldn't like
it.

When I look at a statement or an expression, I prefer that I can look
at it and know that exactly ONE thing happens. Either it has a side
effect, or it returns a value: not both. (Although I'm not opposed to
stuff like readline(), which affect its file object and returns a
value, as long as the side effects are contained.) Assignment
expressions are, of course, the epitome of both at the same time,
which is the real reason I have such a distaste for them.

It would be really nice (generally, not Python in particular) if we
could have all things that return values be expressions, and all
things that have side effects be statements, AND be able to implement
it in a practical way.

I'm not sure if it's practical, thought; Ada does (or tries to do)
something like it, and it went a little too far.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Carl Banks]

What does it mean to be hard to read? Your eyes can't make out the
characters on the screen? Or your eyes can make out the characters,
but the meaning conveyed isn't immediately clear to you. If the
latter, that means you claim to have trouble understanding the
expressions.

No. Go look up the word understand. Whether assignment expressions
are easy to read, or hard to read, I can UNDERSTAND them just fine.

Some of us either manage to limit our use them to ways where this
isn't a problem, or else it just isn't an issue to begin with.

Some of us have programmed in C or Lisp for a long time, and don't
realize how counterintuitive and awkward the construction is.

Frankly your thing about no natural language analog sounds like hot
air to me.

Go back a few posts, and you'll see I implored you to take my
linguistic argument as you would. You evidently felt it was
reasonable enough to argue with. If you'd like to dismiss it as crap,
be my guest. I'm here to defend my views, not to change your mind.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Paul Rubin]

No. Go look up the word understand. Whether assignment expressions
are easy to read, or hard to read, I can UNDERSTAND them just fine.

You're not making any sense. To understand an expression, you have to
read it first. So if it's hard to read, it's hard to understand.

Some of us have programmed in C or Lisp for a long time, and don't
realize how counterintuitive and awkward the construction is.

Then after you've programmed in C or Lisp for a while, maybe the
construction stops being counterintuitive and awkward, hmm? Sort of
like putting the adjective after the noun instead of before it is
counterintuitive for English speakers, but becomes intuitive if you
speak French for a while? If Python had those expressions too, they
would also become intuitive and non-awkward for Python programmers.

(Btw, I remember the exact moment when assignment expressions in C
became natural to me: When I first started learning C from Brian
Kernighan's C tutorial that explained

while ((c = getchar()) != '\0')
do stuff with c;

I had to spend a few moments understanding what was happening, but
then it made perfect sense. No long period of counterintuition or
awkwardness for me, thanks. So there's another counterexample to your
theory. In fact I had an "aha" when I saw that "a = b = c;" is also
an assignment expression in C and worked automatically for that
reason. In Python, of course, it's a special syntactic kludge with,
um, no natural language analog, not that that matters.)

Go back a few posts, and you'll see I implored you to take my
linguistic argument as you would. You evidently felt it was
reasonable enough to argue with. If you'd like to dismiss it as
crap, be my guest. I'm here to defend my views, not to change your
mind.

OK then, based on the decades of experience of millions of C and Lisp
programmers, I'll take your advice and dismiss your linguistic view as
crap. If you want to continue to embrace it, be my guest. Happy
crapping.

 

[Donn Cave]

My contention is that a large part of what makes something "readable"
in code is that is it resembles, to some degree, natural language.
This is because we can use the parts of our brain that parse natural
language to help us parse code. Makes sense, pretty obvious.

The thing is, these analogues have to match syntactically as well as
semantically. In other words, if the language construct in question
does not have an analogue that matches syntactically, then we have to
acquire the ability to parse it. Furthermore, if it turns out that
our "language circuits" are not able to internalize an unusual syntax,
then parsing it will always require intellectual effort. (Whether
this is true of assignment expression I won't speculate at this
moment.) In the end, we have something that is at least harder to
learn, and possibly takes more effort to read.

This part is less obvious. Syntactical relationships are learned,
and arguably learned in a very context sensitive way. Computer
programming languages are relatively simple and regular, and it
is not clear that they depend a lot on congruence with some natural
language.

Now, your example does manage to communicate the semantics of
assignment expression (unlike Rubin's example, which didn't
communicate that anything was being assigned). However, I would say
your example still is not a proper analogy, for a very simple reason:
most people read computer programs as imperative, while your example
is declarative.

I hope I don't have to argue the point that most people think of
programming as imperative. I believe programmers think of "a=b" as
"Set a to b," not "a's value becomes b's value". Therefore, I don't
consider a declarative clause to be an analogue of an assignment; it
is both syntactically and semantically different.

If we stipulate that we are talking about Python programmers, maybe.

In more general terms, though, I think it could be argued that
assignment actually doesn't play much of a role in natural speech
anyway, whether in the declarative or imperative sense. Unless
you count lexical function, but you're talking about syntax.
This should be bad news for Python, but by the time people get
here it doesn't matter much.

Moreover, I think you should probably quit while you're ahead,
because I have a hunch that the point you're pushing there would
actually work against you if it were more patently true. Suppose
the syntax actually were "set a to b", or of course more like
"set `a b" because this isn't Applescript or Cobol. Borrow the
time machine and make it so. Now, will this turn out to be an
expression? Very good odds, because now it's just a function.
Functions can be imperative, and they're certainly expressions.

Basically, I don't think you want to tie the quality of a computer
programming language to its congruence with English syntactical
forms. If there were a clear case for that, I think the FPL crowd
would come out way ahead.

When I look at a statement or an expression, I prefer that I can look
at it and know that exactly ONE thing happens. Either it has a side
effect, or it returns a value: not both. (Although I'm not opposed to
stuff like readline(), which affect its file object and returns a
value, as long as the side effects are contained.) Assignment
expressions are, of course, the epitome of both at the same time,
which is the real reason I have such a distaste for them.

It would be really nice (generally, not Python in particular) if we
could have all things that return values be expressions, and all
things that have side effects be statements, AND be able to implement
it in a practical way.

I'm not sure if it's practical, thought; Ada does (or tries to do)
something like it, and it went a little too far.

Probably didn't go near far enough. You have to get a look at
Haskell. Whether it's practical is endlessly debatable, and
I'm not sure it exactly does what you say there ... or maybe
you'd have to program in Haskell to see what you're saying.
But it is rather rigorous in this respect.

Donn Cave, (e-mail address removed)

 

[Paul Rubin]

But when you can say

if g := match(a, b):

then I suspect you will also be able to say things like -

if not (dv := start() and f := nfile(dv)
and ((t := f.find("--") > 0 and fx = f[:t]) or (fx = f))):
print "Well, bless me!"

Well, yes, you can write messy code in any language. There will
always be some need for tastefulness in programming. Language
designers can't make that need go away.

 

[Carl Banks]

This part is less obvious. Syntactical relationships are learned,
and arguably learned in a very context sensitive way.

Well, I can assure you that it's at least harder to learn, seeing that
learning a new syntax is always harder than using syntax similar to
what you already know. (Otherwise, explain why Spanish is easier to
learn for English speakers than Japanese.)

As for the argument that it could take more effort, let's just
remember that our internal language circuits cannot handle arbitrary
syntax. Simple as assignment expressions are, I'm not so sure our
language circuits can parse a syntax which doesn't exist in any
language I know of (and I suspect doesn't exist in any language). If
we cannot parse an assignment expression though ordinary language
processing, then it follows that it takes more effort to read it.

(I sense we're getting dangerously close to introducing Chomsky into
this discussion; if so, I'm outta here.)

Computer
programming languages are relatively simple and regular, and it
is not clear that they depend a lot on congruence with some natural
language.

I highly disagree with this statement, however.

Relatively simple and regular has nothing to do with it. Assembly
language is relatively simple and regular. Intercal is relatively
simple and regular. Perl is relatively simple and regular. And
they're all unreadable messes. (Even still, all of them rely on a
smittering of resemblance to natural language.)

There's a reason hardly any successful programming languages eschew a
resemblance to human language: because humans are good at thinking in
terms of language.

If we stipulate that we are talking about Python programmers, maybe.

In more general terms, though, I think it could be argued that
assignment actually doesn't play much of a role in natural speech
anyway, whether in the declarative or imperative sense.

You're completely missing the point.

I'm not trying to claim that assignment, per se, plays a role in
natural speech. My claim is that assignment is a command. When a
programmer writes a=b, he's commanding the computer to set a to b.
Commands do play a role in natural speech, and only the imperative
mood conveys it (without descriptive circumlocations).

Which is (getting back to the point) why I think Martelli's example
was incorrect.


[snip]

Basically, I don't think you want to tie the quality of a computer
programming language to its congruence with English syntactical
forms. If there were a clear case for that, I think the FPL crowd
would come out way ahead.

Basically, I think you're missing the whole point of what I'm saying,
and are therefore ill suited to judge the strength of my position.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Dave Benjamin]

But when you can say

if g := match(a, b):

then I suspect you will also be able to say things like -

if not (dv := start() and f := nfile(dv)
and ((t := f.find("--") > 0 and fx = f[:t]) or (fx = f))):
print "Well, bless me!"

Well, yes, you can write messy code in any language. There will
always be some need for tastefulness in programming. Language
designers can't make that need go away.

Of course. But what I think a lot of people miss is that language design is,
in some ways, an experiment on human behavior, with programmers as the
subjects. If you wrote a language, and found that adding one particular set
of features as opposed to another set of features resulted in code that,
overall, you preferred to look at, you might prefer to design the language
that way. Regardless of whether or not you trust yourself (or others) to
use/abuse the features available.

Some languages prefer to let the programmer do anything. This makes
programmers very happy, because they have the freedom to do whatever they
want. However, it also means that it's more difficult to read other people's
code, because they have that same freedom. There's more variance.

As a programmer, you already have the freedom to pick the language you want.
If your job doesn't allow it, you can pick another job. Or you can start
your own company, or program as a hobby. No language designer is telling you
what to do; you are making the choice to pick a given language, ultimately.

But from the perspective of a language designer, your decisions affect the
code that other people will produce. By adding a single feature, you may be
indirectly creating 10,000 actual usages of that feature in other people's
code. In a sense, you are programming the programmers, and if you make
things possible in your language, your programmers will do those things. If
it turns out to be a fault, this reflects directly on you.

This is, I think, the fundamental reason for the statement vs. expression
dichotomy in Python. It's not that clear statements can't be written with
embedded statements. It's that Guido doesn't want to have to read other
people's code written that way (I'm guessing - feel free to unstuff these
words from Guido's mouth if I'm in error , and he certainly doesn't want
the "everyone" to which his "computer programming for everyone" refers to
have to read code written that way. It's a problem for some people. He
wanted a language that didn't pose that problem for those people.

In the end, I fullheartedly recommend against taking an antagonistic
viewpoint against language designers because they don't support Feature X.
They didn't write the language for you; if they did, they would have
included Feature X, because obviously it's important to you. But instead,
they saw (hopefully) the greater picture; the gigantic body of code that
others would go on to produce. By designing a language in a particular way,
language authors in effect design this body of code as well.

For instance, I personally think Python would be even better than it is if
it had code blocks. I'm aware that this probably won't happen. But I
understand why, and it has nothing to do with *me*. So, I don't take it
personally. Besides, Python is free, and it rocks, and it makes me happy
because it puts my code so much closer to my thoughts than any other
language. Python targets a particular demographic, and it managed to find
one which I belong to, to a fairly large degree.

But when I want statements in my lambdas, I'll have to look elsewhere.
This means I might play around with Ruby, or ActionScript, or SmallTalk, to
get a taste of that. And if I want assignment expressions, maybe I'll try
Java or C++. But I don't find myself wanting for those often... or ever...