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. GvR has even written that one of his
objections to ABC's design was it's tendency to create new jargon-isms to
replace old jargon-isms. The language designers "thought" they could ease the
learning curve simply thru virtue of symbols, but all they did was to further
confuse noobs. GvR saw the folly of this, and set out to prevent such design
flaws in his language, however, i argue that interfaces like the "print
function" are making the same mistakes. The linking of abstraction layers is
even *MORE* important than intuitive naming conventions. But sometimes the name
is the only path by which you can provide the link. As is the case with the
print function.
> > Rick said:
> > (1) How do you output a message without the print function?
>
Steven said:
> *scratches head*
>
> Why would you want to do that? print is clearly the "one obvious way" to
> output a message.
Well of course the answers are *OBVIOUS* when you already *KNOW* them Steven!
Climb down off your high horse for a moment, and take yourself back to a time
*BEFORE* you had any knowledge of output streams.
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.
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?
Not only is "print" un-intuitive (by nature of it's naming), it is obfuscating
the path to the underlying process of "sending data to an output stream".
--
https://mail.python.org/mailman/listinfo/python-list