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

[Steven D'Aprano]

On Fri, 25 Oct 2013 01:12:12 -0700, Peter Cacioppi wrote:

> On Monday, October 21, 2013 9:29:34 PM UTC-5, Steven D'Aprano wrote:
>> On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote:
>>
>> Challenge: give some examples of things which you can do in Python, but
>> cannot do *at all* in C, C++, C#, Java?
> 
> Please. No exceptions is huge. No garbage collection is huge.

You have over-trimmed and lost context. The context here is that I 
maintain that one of the reasons for inventing new languages is to 
provide useful programming idioms and techniques in a convenient, clean 
way, that is, with syntactic support and a minimum of needless 
boilerplate. You have objected to this view, and (if I understand you 
correctly) believe that there are certain idioms which are *impossible* 
in C, hence the invention of new languages.

I agree with you that garbage collection and exceptions are useful, 
powerful features. I agree with you that the difference between a 
language which supports them natively (like Python) and one which does 
not (like C) is huge. But beyond that I think you are mistaken.

C does not natively provide garbage collection, or exceptions, or many 
other features. But that doesn't make it *impossible* to use these 
features in C, it just makes them *inconvenient and difficult*. To get 
the advantage of such features, you have to build a framework that 
provides them, then exclusively use the framework, while avoiding 
dropping down into the underlying low-level C features that bypass the 
framework. This is inconvenient, error-prone, inelegant, and requires 
discipline, but it is *possible*.

Take the framework to the next level: add custom syntax, a parser, and a 
system for translating your custom syntax to (say) C, or machine code for 
some (real or virtual) machine. We call this *a programming language*. 
But that's just an incremental step beyond a framework, which in turn is 
just an incremental step beyond a library, which in turn is just an 
incremental step beyond an ad hoc system of useful wrapper functions and 
conventions.

In a very real sense, Python is "just" a convenience wrapper around a 
bunch of C functions to provide OOP idioms, garbage collection, dynamic 
typing, runtime introspection, exceptions, and similar.


> But you can do anything with a Turing machine. You can do anything in
> assembly. The point is to pick the appropriate tool for the job.

I agree! And building those tools is one of the reasons why people create 
new programming languages: to make useful techniques and idioms easier to 
use.


> I can build a house without a nail gun. I can probably even build a
> house without a hammer. But it's a waste of time to build things with
> the wrong tools.

I don't think the right analogy is with the nail gun versus hammer. Both 
result in the same finished product: two pieces of timber joined together 
with one or more pointy bits of steel. Sure, a nail gun is faster and 
easier, but the idiom is the same.

A better analogy is to consider the various ways to assemble timber: 
nails, screws, glue, dowels, biscuits, dovetail joints, etc. These are 
all *idioms and techniques* for getting the same result (two pieces of 
wood joined), rather than different tools for performing the same idiom 
(drive a nail using a nail gun, a hammer or a rock). Each idiom has 
different pros and cons: biscuits are good for joining chipwood edge-to-
edge, but lousy for load bearing structural timbers.

Like all analogies, it doesn't pay to take it too far, but essentially 
you can think of a language like Python as being like a machine shop with 
a dedicated biscuit joiner, while C is like one without such a device. 
You can use the same technique in both, but the ease of use, convenience 
and reliability is quite different:

* In Python, you use the biscuit joiner to quickly cut out a matching,
  nicely machined slot in both pieces of chipboard.

* In C, you have to manually and carefully drill out many thin holes in
  the chipboard, then laboriously cut through to make a slot, then file
  smooth by hand. Not only is this much more work, but the end result is
  likely to be less reliable.


For anyone who has no idea what I'm talking about when I talk about 
biscuit joiners:


http://en.wikipedia.org/wiki/Biscuit_joiner



-- 
Steven