assignment expression peeve

[Donn Cave]

In article <6ZWjb.49$Vf7.34 at nwrdny02.gnilink.net>,
 Carl Banks <imbosol at aerojockey.invalid> wrote:
...
> 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, donn at u.washington.edu