Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Ian Kelly <ian.g.kelly@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Is vars() the most useless Python built-in ever?
Date: Tue, 1 Dec 2015 22:48:57 -0600
Lines: 78
Message-ID: <mailman.100.1449031739.14615.python-list@python.org>
References: <565cf141$0$1612$c3e8da3$5496439d@news.astraweb.com> <4f0f7fc5-c93a-4223-9c05-e192a8fafbbd@googlegroups.com> <565d5282$0$14486$c3e8da3@news.astraweb.com> <11a610aa-41d8-433c-b36b-e23ba4d83243@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <11a610aa-41d8-433c-b36b-e23ba4d83243@googlegroups.com>
Precedence: list
Xref: csiph.com comp.lang.python:99845

On Dec 1, 2015 1:36 PM, "Rick Johnson" <rantingrickjohnson@gmail.com> wrote:

>

> On Tuesday, December 1, 2015 at 1:55:59 AM UTC-6, Steven D'Aprano wrote:

> > Python was never intended to be "merely" a teaching language. I think

> > Guido's original vision was for it to be a glue language between C

> > libraries, and a scripting language.

>

> It's a well know fact that GvR was inspired to create Python from his
experiences working with a language called ABC -- and ABC was designed
*EXCLUSIVELY* to be a beginners language.

Which is exactly what made ABC itself unsuitable for Guido's purpose, which
was to create an *applications* language with better productivity than C to
support users of Amoeba, the OS that he was working on at the time.

> I am not arguing that "abstractions are evil", no, my position is that
abstractions must be constructed in a manner that provides a clear trail of
bread crumbs which lead to the underlying processes. With print, not only
is the engine in another dimension, but the hood is as well! How is a noob
to discover the engine when he cannot find the hood?

>

> Ponder the following example code (as a noob!):

>

>  stdout.write("Dude, i found my car, the hood, and the effing engine!!!")

>

> Even a noob can intuit what is going on here. First we have an *OBJECT*
named "stdout, and we can extrapolate that stdout is an abbreviation for
StandardOutput. Next, we see a method called "write", and, if our IQ is
above room temperature, then we can extrapolate what that method will do.

This is absurd. You postulate a beginner so rank that they can't understand
what "print" means, yet you expect them to intuitively know:

1) what an object is;

2) what a method is;

3) that a method is identified by placing a period between the object and
the name of the method;

4) what "output" is in the context of programming;

5) and not be confused about what makes the output "standard".

> Now ponder this code (as a noob!):

>

>  print("Dude, where's the intuitiveness?")

>

> What the heck does print do? Where will the string go after i execute
this line of code? Should i turn my printer on? Should i check my ink
levels? And what OEM drivers are required?

You're describing this as if your hypothetical beginner were learning
Python in a vacuum. In reality, people learn from a teacher, or a book, or
at minimum a tutorial.

Here's how you teach somebody what "print" does: instruct them to type
print("hello world") at the interactive prompt. Note that Python writes
"hello world" as a result. If they really want, they can check their
printer and see that nothing came out. That's it. The student now
understands what "print" means.