On 23.06.2018 5:46, Steven D'Aprano wrote:
On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:
I've started testing the proposed syntax when I teach. I don't have a
large
sample yet, but most students either dislike it or don't appreciate the
benefits. They state a clear preference for shorter, simpler lines at the
consequence of more lines of code.
Of course they do -- they're less fluent at reading code. They don't
have the experience to judge good code from bad.
The question we should be asking is, do we only add features to Python
if they are easy for beginners? It's not that I especially want to add
features which *aren't* easy for beginners, but Python isn't Scratch and
"easy for beginners" should only be a peripheral concern.
Python's design principles are expressed in the Zen. They rather focus
on being no more complex than absolutely necessary, without prioritizing
either beginners or old-timers ("simple is better than complex",
"complex is better than complicated").
This is partly because students, lacking the experience to instantly
recognize larger constructs, prefer a more concrete approach to
coding. "Good code" is code where the concrete behaviour is more
easily understood. As a programmer gains experience, s/he learns to
grok more complex expressions, and is then better able to make use of
the more expressive constructs such as list comprehensions.
I don't think that's the only dynamic going on here. List comprehensions
are more expressive, but also more declarative and in Python they have nice
parallels with SQL and speech patterns in natural language. The concept of
a comprehension is separate from its particular expression in Python. For
example, Mozilla's array comprehensions in Javascript are/were ugly [0].
Mozilla's array comprehensions are almost identical to Python's, aside
from a couple of trivial differences:
evens = [for (i of numbers) if (i % 2 === 0) i];
compared to:
evens = [i for i in numbers if (i % 2 == 0)]
- the inexplicable (to me) decision to say "for x of array" instead of
"for x in array";
- moving the expression to the end, instead of the beginning.
The second one is (arguably, though not by me) an improvement, since it
preserves a perfect left-to-right execution order within the
comprehension.
Students who are completely new to programming can see the similarity of
list comprehensions to spoken language.
o_O
I've been using comprehensions for something like a decade, and I can't
:-)
The closest analogy to comprehensions I know of is set builder notation
in mathematics, which is hardly a surprise. That's where Haskell got the
inspiration from, and their syntax is essentially an ASCIIfied version
of set builder notation:
Haskell: [(i,j) | i <- [1,2], j <- [1..4]]
Maths: {(i,j) : i ∈ {1, 2}, j ∈ {1...4}}
I teach secondary school children maths, and if there's a plain English
natural language equivalent to list builder notation, neither I nor any
of my students, nor any of the text books I've read, have noticed it.
--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
