Python was designed (was Re: Multi-threading in Python vs Java)

[Chris Angelico]

On Mon, Oct 21, 2013 at 1:07 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> One of the reasons multiple languages exist is because people find that
> useful programming idioms and styles are *hard to use* or "ugly" in some
> languages, so they create new languages with different syntax to make
> those useful patterns easier to use. But syntax is not everything.
> Whether you write:
>
> object.method(arg)    // Python, VB, Ruby, Java
> object#method arg     // OCaml
> object:method arg     // Lua
> method object arg     // Haskell, Mercury
> object method arg     // Io
> object->method(arg)   // C++, PHP
> method(object, arg)   // Ada, Dylan
> send method(arg) to object  // XTalk family of languages
>
>
> etc. does not really change the fact that you are calling a method on an
> object, despite the change in syntax. Even Forth has frameworks that let
> you write object-[oriented|based] code using a stack and reverse Polish
> notation syntax.

There seems to be a school of thought that "if it doesn't have special
syntax, the language doesn't support it". This is true to an extent
(eg C doesn't support sockets, the code is all in the standard
library), and it does distinguish C from C++ in object orientation
(C's version is simply dedicating the first function argument to
'self', where C++ and Python and so on have an alternative syntax that
puts the self/this argument before the function name), but I don't
know that it's the whole story. Python 2.x has special (and somewhat
magical) syntax for file I/O; Python 3.x, as far as I know, has none -
open and print are just builtins, with no magic around them. Which is
better? I would say that standard functions are inherently more
flexible (you can shadow print and call the original, for instance),
but that would mean that the better way is to NOT "support" I/O.

If an analogy helps, let's look at the trading card game Magic: The
Gathering. The general design principle is that unusual effects get
written out on the card, rather than having actual rules to support
them; rulebook text is used only when printing abilities on the card
is unable to do everything. (There are also keyword abilities, which
are like Python's builtins - "fear" simply means "can't be blocked
except by artifact and/or black creatures", and it could just as well
be written out on the card.) Does this mean that Magic supports
lifelink (which has entries in the Comprehensive Rulebook) but doesn't
support defenders (which simply can't attack)? I think not; the game
is most definitely designed for both.

Granted, C probably wasn't designed with object orientation in mind;
but it doesn't take very much effort to make it work (just pointer
casts and some argument order conventions). Sure, a bit of real
support helps (preventing accidental cross-casts), but it's pretty
easy to manage without. Adding to the list of object oriented C
systems is NIH:

http://ifdeflinux.blogspot.com/2012/05/quick-libnih-tutorial.html

It's small enough and light enough to be used by really early systems
like Upstart (a Linux bootloader) and it's a garbage-collected
object-oriented C library.

ChrisA