Is vars() the most useless Python built-in ever?

[Chris Angelico]

On Sat, Dec 12, 2015 at 3:44 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, 12 Dec 2015 09:13 am, Rick Johnson wrote:
>
>> Intuitiveness and productivity have a
>> synergy like peas and carrots! One cannot be productive if one is fighting
>> an unintuitive interface. Could you drive with your toes? How about your
>> tongue?
>
> Drive a car with my tongue? Perhaps not, but I could drive a car with my
> mouth if it were equipped with a sufficiently powerful interface.
>
> "Driver, please take me to the airport."

Bring on the self-driving cars! They're already comparable to human
drivers in skill. Instead of getting my sister to chauffeur me around,
I could just hop in my automatic car, tell it my destination, and sit
back with my laptop. All I need is for them to become more affordable.

> In practice, "intuitive interface" gets bandied about in two ways:
>
> (2) Others use it to mean an interface which is:
>
> * predictable;
> * consistent;
> * easy to explore and learn;
> * and "easy to use" in some vague sense.
>
>
> They recognise that what seems unpredictable to one person may be perfectly
> predictable to a more experienced user.

Which really means that "intuitive" is a feature of
skill/comprehension transference. This is the exact reason for the
extensive use of metaphors in design - even though those metaphors
often get orphanned, they are useful. How many people have actually
carried around a folder full of documents? A few of you, maybe? How
many of you instantly understand what a folder is, and that you can
drag documents into it? Everyone. It makes perfect sense that you
should be able to put stuff inside other stuff, so we can extend that
to "compressed folders" or "shared folders" or "backed-up folders" or
any other adjective you care to use. These are then touted as
"intuitive" - eg I can use Dropbox by just sticking something into the
Dropbox folder, ergo this interface is intuitive.

Most modern languages seem to assume at least some knowledge of
mathematics (maybe as far as algebra). It's considered intuitive that
(1.0 + 2.0 / 6.0) should be equal to 1.333, because the fraction bar
translates fairly readily into the slash. (And it doesn't equal 0.5,
because the order of operations demands it.) Learning that you need
the asterisk for multiplication is usually not a problem - at worst,
it's the price you pay for multi-letter names (xy is distinct from
x*y). Give people a staircase of small comprehensions and they'll
master it; shove them up against a wall of new knowledge and they
can't mantle up.

>> (1) When laymen consider the word "print" (in the context of computing),
>> they first think of "sending a document to a printing device".
>
> No they don't. They think of printing to the screen, not printing to paper.
>
> Even if they think of printing to paper, it takes them less than a second to
> learn otherwise. That's a fantastic user interface: you can learn and
> explore the functionality of the language very easily.

Maybe if you had people entering code on a typewriter and seeing the
output two hours later on parchment, then they'd assume it meant print
to paper. Does anyone these days even print out listings?

There are two broad types of code: Simple and complex. There are two
broad types of job: Common and unusual. If you see a very simple piece
of code, you will generally expect that it's doing something common.
Let's posit a domain-specific language for building objects for a
MMORPG. Here's a piece of code, with all crucial keywords replaced
with names from my current D&D campaign:

soyutlanma on_wield(player)
[[[
   parildiyor player#level >> 72
   [[[
      dogmakta «You cannot wield this weapon.»
      uzakta
   ]]]
   parildiyor player#classes << {«bard»}
   [[[
      dogmakta «You can ne'er wield this weapon.»
      uzakta
   ]]]
   dogmakta «It feels strong and sturdy in your hand.»
   taneleri item, inventory
   [[[
      parildiyor kaylee<->item
      [[[
          dogmakta «Your helmet glows brightly with increased magic!»
      ]]]
   ]]]
]]]

So, what operations do you think would be sufficiently common to
justify language keywords? I've deliberately made them nonsense so
there's no clues from the words themselves, but I expect that anyone
here should have a reasonable shot at figuring out what things might
mean. Voila! I've made an intuitive language. Right?

Sending content to a printer is at least as complicated as writing to
a file on disk. I would expect that any language keyword or built-in
function for generating paper output should, at a minimum, stipulate
which printer it's going to, and have a means of saying "I'm done with
that page now". We don't tend tto "log to prn" these days, so you
wouldn't expect to see a command/function to "write this line to the
printer, and if there are 66 lines written, push that page out and
bring the next one in".

> (One of the weaknesses of Python, and nearly all mainstream programming
> languages, is that there is nothing even remotely like an easy-to-explore
> UI for programming GUI applications.)

That might change without any change to Python. All you need is to
start by introducing a GUI builder, and then have a way to pop out an
"event editor" where you enter the code to be run when a button gets
clicked (and that code would then be Python). But I'm not sure we need
that. In my experience, those kinds of "hey, don't write code yet"
tools tend to be either very limiting, or just as complicated as
writing actual code.

>> (2) The path to the underlying process is not even remotely clear. LIKE IT
>> NOT, PRINT IS "MAGIC SYNTAX".
>
> print does what it says of the tin: it prints (to the screen). You don't
> have to understand how it manages that to use it effectively, just as you
> don't have to understand calculus in order to use math.sqrt().

More specifically, it prints to the standard output stream.
Understanding how info gets from that stream to an actual screen is
another huge mess. Back when I first learned 80x86 assembly language
programming under DOS, I could write a tiny program like this:
B4 09 BA 09 01 CD 21 CD 20
and then append whatever text I want to write (terminated by 24,
dollar sign). That would write the specified content to stdout, which
first goes through a whole lot of DOS checks to see if there's
redirection or anything, and maybe parses ANSI.SYS codes, and then
hands the characters off to the BIOS, which does another bunch of
checks, then stuffs the bytes into video memory, where they get picked
up by the video card, transformed into pixels, and then encoded into
the appropriate signal, which goes to the actual monitor, which
renders 720x348 pixels (we had a Hercules Graphics Card and a
monochrome monitor) by pitching quantum particles at incredible speeds
through powerful magnets at phosphors that get so excited they
positively glow, which then stimulates my optic nerve... you know, we
could go on like this ad infinitum, but the fact is, that program
*wrote to the screen*. And I felt great accomplishment for doing so.

ChrisA