[Python-ideas] Does jargon make learning more difficult?

[Abe Dillon]

[Steven D'Aprano]

> Indeed. I wonder whether Abe drives, and if he does, whether he has read
> the owner's manual. They are typically *full* of jargon.


Do you still not understand the difference between documentation and
interface?
You seem to not even acknowledge that there's a difference between how one
talks about a tool and how one uses said tool.

Typically, the main concern of someone making a complex tool like a
bulldozed is that the interface is as clear, accessible, language agnostic,
simple, and utilitarian as possible. The reverse noise is a simple beep,
not a voice saying "throttle set to reverse position". You use levers and
buttons typically labeled with symbols rather than words. There are reasons
why designers favor symbols and indicator lights over technical jargon. It
has nothing to do with kiddie design vs. professional tools. It has
everything to do with favoring the most intuitive interface possible to get
work done.

I honestly don't know what to say anymore. You keep conflating the syntax
of Python with documentation and human-to-human communication. It's
incredible. I don't know how many times I need to point out the difference.
Do you think python's conditional operator should be like this:

z = ConditionalOperator(predicate: x==y?, affirmative: x*2, negative: None)

?
What can I do to illustrate that there is, indeed, a difference between
what people call something and how someone uses a tool?

I'm at a loss for words.



On Thu, Aug 23, 2018 at 12:21 AM Steven D'Aprano <steve at pearwood.info>
wrote:

> On Thu, Aug 23, 2018 at 03:12:30PM +1200, Greg Ewing wrote:
> > Abe Dillon wrote:
> > >They still find it's better to use a red break
> > >light symbol with the aim of clearly communicating to non-experts.
> >
> > The handbrake warning light on my dashboard has a symbol
> > that represents a brake drum and a pair of brake shoes,
> > and the word "BRAKE" written underneath it. That's a
> > technical term and an implementation detail, right there
> > in the user interface!
>
> Indeed. I wonder whether Abe drives, and if he does, whether he has read
> the owner's manual. They are typically *full* of jargon.
>
> Similarly for bulldozers. Here's a short instructional video:
>
> https://www.youtube.com/watch?v=p2mh6kUuedk
>
> Many of the controls are described in common terms (why would they need
> jargon terms for "forward", "reverse", "left", "right"?), but they also
> mention specialist jargon like "throttle" and "decelerator".
>
> A bulldozer has perhaps as many as a dozen critical functions: move
> forward, reverse, lift the blade, etc, which can only combine in a
> rather limited number of ways. The user-interface is designed for
> real-time manual operation.
>
> Programming languages have multiple dozen features, hundreds if you
> include Python's std lib, which combine in a near-infinite number of
> ways. Programming is a batch operation: while a bulldozer operator has
> to react on the spot, the programmer typical gets to think ahead, write
> some code, think some more, write a bit more, do some incremental tests,
> write some more code, do some research, write a bit more code, think
> some more etc in dozens or hundreds of iterations before actually
> running the code in production.
>
> I don't think its productive to compare programming to driving a
> bulldozer. A better analogy would be sound mixing:
>
> https://videohive.net/item/sound-mixer-2/2244660
>
> https://www.soundonsound.com/sound-advice/glossary-technical-terms
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180823/001b0f48/attachment-0001.html>