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

[Rick Johnson]

On Friday, December 11, 2015 at 10:45:02 PM UTC-6, Steven D'Aprano 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."

Sorry Steven, but that command will not be executed. First
you must say: "Ok Google". ;-)

Even google is not insane enough to write software that
attempts interpretation of every spoken within ear-shot of
it. But your interface has an even greater problem: since
software cannot yet read minds, and since most metropolitan
areas contain more than one airport, you may want to be more
specific than "take me to the airport". Heck, why not follow
that one with "take me shopping". ;-)

Not only have you demonstrated that your "mock interface" is
un-intuitive, your commands are so implicit that the banter
between human<->software is likely to descend into a sad
parody of Abbott and Costello!

> > Sure, even the most atrocious interface can be "learned", but what i
> > cannot understand, except in the case of you being a contrarian, is why
> > you would argue *AGAINST* intuitive interfaces? And believe it or not,
> > *SYNTAX* is an interface! As are paradigms!
>
> I do believe that you are arguing against a strawman. I don't think that
> anyone here has argued *against* "intuitiveness", all else being equal. But
> you are glossing over a whole lot of real complexity:
>
> - what makes you think all else actually is equal?
>
> - who decides what is intuitive and what isn't? why should we take
>   your word over what's intuitive and what isn't?
>
> - intuitive for who? my dad, who has never used a computer? my mum,
>   who has used a computer but only for word processing and web
>   browsing? a ten year old maths prodigy? a thirty year veteran
>   of C programming? a beginner to programming with a month's
>   experience in PHP?
>
> - what level of power are we willing to forgo in order to keep
>   the language "intuitive"?
>
> - what the hell does "intuitive" mean anyway?

Who's needs Abbott! Listen Steven, the litmus test for
intuitiveness is simple: if the overwhelming majority of the
users find it to be intuitive during the learning process,
then your interface is intuitive. That's it.

> I know what the definition of the word is, but it doesn't apply to
> programming language interfaces. As has been pointed out many times, the
> only truly intuitive interface is the nipple. Everything else has to be
> learned.

And what experience do *YOU* have with breast feeding that
would in any way qualify *YOU* to make such an assertion?

> In practice, "intuitive interface" gets bandied about in two ways:
>
> (1) Some people use it as a thought-terminating cliche. What they really
> mean is that they want this interface feature, for reasons of their own,
> and by calling it 'intuitive', they hope to bamboozle or intimidate others
> into backing down and accepting the feature. Who could possibly be
> against "intuitive" interfaces? That's like being against "usefulness",
> or "flexibility".
>
> When people start protesting about others being "against intuitive
> interfaces" (especially if they SHOUT the word "against", that's an good
> sign that they're using it as a thought-terminating cliche. To these
> people, "intuitive" is like "New And Improved!!!" to advertisers.
>
> (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.

This last comparison looks an awful lot like a straw-man
Steven. Nice. Extra points for painting me as a bully, and
then using my exact definition of intuitiveness but applying
it to the "friendly challenger". Your sleight of hand is
impressive my friend.

> [...]
>
> And most importantly, they recognize that programmers are beginners for
> perhaps 1% of their programming life: you might be completely new to
> programming for three months out of a 30 year span of programming. Why
> optimize the language for something that you will use for less than 1% of
> your productive lifespan? Apart from intentional beginner's languages like
> Scratch, for most languages it makes sense to add power even if it
> increases the learning curve.

I can assure you that complexity is not sacrificed when we
design interfaces to be intuitive. And to illustrate, we
need look no further than the automobile for a fine example.
The interface for driving a car is not only intuitive, it is
consistent!

  It is intuitive because it exposes a small number of high
  level operator components: the steering wheel, the brake
  petal, and the accelerator petal.

  And it is consistent because no matter what brand or model
  you choose to drive, *ALL* of them will expose these same
  three components.

  *Heck, even when observing the differences between British
  and American driver position (left side versus right
  side), the components are still the same!

Now, even though all automobiles expose an interface of only
three high level components, the range of power is vast.
Because the power is not defined inside the *CONTROLS*,
no, the power is *ABSTRACTED* away under the hood, and the
controls are merely methods of wielding the power.

We can observe this elegance, and broad range of power, by
observing that, not only can a small child putt around in a
toy car in the front yard with great ease, but a Formula One
race car driver can push an advanced power-train to the
limits of physics! From the nostalgic joy of a treasured
childhood toy, to the harsh grind of daily commuting, to the
bleeding edge of high performance motorsports, the interface 
remains the same.

But the most important aspect of this great design to
observe, is that, the power and the interface are two
separate components. Alone they cannot do much, but when
linked together in a master/slave relationship, they become
the basis of the "relegation of logical abstractions".  The
secret to great software design is realizing that it is the
layers of abstraction that exist *underneath* intuitive
interfaces which provide scale-able power on demand.

(RETORT_1) The "idea" that intuitive interfaces are only
useful for "toy programs" is complete rubbish. Trying to
blame performance issues on an interface is like driving a
toy car on the interstate at 0.2 miles per hour, and then
suing drivers who accidentally plow over you. Poor
performance is a result of poor design choice. The absurdity
of expecting a toy car to perform at highway speeds is only
overshadowed by the absurdity of blaming the accelerator
petal for the lack of power!

(RETORT_2) The "idea" that experienced users are limited by
intuitive interfaces is also rubbish. When abstractions are
properly layered, many levels of interfacing will be
exposed. Our goal should not be to create the highest level
interface, but instead, the highest layer of the
interfacing *CAKE*! If the experienced programmer feels
that the highest layer is too confining, then all he needs
to do is drop-into a lower level interface. Using our
car example, if we wanted to gain more power, we would
modify the engine (we could inject more air/fuel, or use a 
more volatile fuel). But this type of modification is not
possible for the new user, so we must provide the high
levels, while maintaining multiple lower levels of
interfacing. But most importantly, we *MUST* maintain a
layered cake model. Abstractions built on abstractions.