Steven D'Aprano wrote:
[...]
> I am using "abstract" in the sense of an abstraction, as opposed to
> something concrete and real, not as a mechanism for specifying interfaces
> in Java or Python. Python's float is a leaky abstraction of mathematical
> Real numbers, and Python's softed() is a leaky abstraction of the concept
> of sorting a collection.
Oh, I forgot to mention... "sorting a collection" is itself an abstraction
(that is, a generalisation) of concrete examples of sorting, such as
sorting a hand of cards, sorting an unruly crowd of school children into
order of height, sorting out a messy cutlery drawer, or sorting the books
in a library.
Abstractions are good and necessary, being a programmer is about learning to
invent and use abstractions, but both object-oriented and functional
programming circles are prone to over-abstraction and that's why they're a
an ill-fit for teaching beginners.
To a beginner, functions and their return result is an abstraction (and
quite a hard one for many people to learn). The natural tendency is to
write functions like this:
def frobnicate(value):
print (value + spam + eggs)
because they're thinking "how do I get the frobnicated value?" and the
obvious interface between "I" (the beginner) and the computer is visual.
They haven't learned the essential abstraction known as "returning a value"
yet and so they use:
- calculate the frobnicated value
- print it
instead of the generalisation:
- calculate the frobnicated value
- return[1] it to the caller[2]
- which captures that return result somewhere[3]
- and finally prints it
or possibly this one:
- calculate the frobnicated value
- return it to the REPL
- which prints it then throws it away
[1] What does "return" in the context of functions even mean? Try explaining
it to a beginner who doesn't understand functions. The best I can come up
with is you just keep showing them examples until they draw the connection
themselves.
[2] Who?
[3] Where?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
