Experiences/guidance on teaching Python as a first programming language

Steven D'Aprano steve+comp.lang.python at pearwood.info
Fri Dec 20 03:16:05 CET 2013

On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote:

> In article <52b328f7$0$6512$c3e8da3$5496439d at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> Correct. The *great deal of trouble* part is important. Things which
>> are the responsibility of the language and compiler in (say) Java, D,
>> Rust, Go, etc. are the responsibility of the programmer with C.
> Does anybody ever use D?  I looked at it a few years ago.  It seemed
> like a very good concept.  Sort of C++, with the worst of the crap torn
> out.  If nothing else, with the preprocessor torn out :-)
> Did it ever go anywhere?

There are still people using D. Like most niche languages, it's in a 
niche :-)

>> Now, I wish to be absolutely clear. There are certain programming areas
>> where squeezing out every last iota of performance is important, and to
>> find the C standard's position on undefined behaviour to be
>> irresponsible, but, hey, MAYBE IT IS JUSTIFIED on the basis that C is a
>> systems language intended for use in writing performance-critical
>> operating system kernels, device drivers and similar. It's fine for
>> Python to promise that nothing you do will ever cause a segfault, but
>> for a language used to write kernels and device drivers, you probably
>> want something more powerful and less constrained.

Emphasis added.

> I disagree entirely (but respectfully).  If you want to get down to the
> hardware where you can fiddle bits, you want as little getting between
> you and the silicon as possible.  Every time you add a safety feature,
> you put another layer of *stuff* between you and the machine.

I think that if you re-read what I wrote, you actually agree with me.

With the following two provisos:

1) There is a tendency among some programmers to premature optimization 
and coding machismo where correctness is a distant fourth place behind 
speed, memory use, and code size -- and security doesn't even place. For 
those programmers, "I want to get down to the hardware" often has nothing 
to do with *needing* to get down to the hardware. Screw 'em.

2) Even for kernel developers, I believe that systems languages should be 
safe by default. You ought to have to explicitly disable (say) bounds 
checking in critical sections of code, rather than explicitly enable it. 
Or worse, have to program your own bounds checking -- especially if the 
compiler is permitted to silently disregard it if you make one tiny 

> That's not to say it's the right language to be writing applications.

I find it interesting to note that the utter failure of C programmers to 
deal with the consequences of buffer overflows has lead Intel to put 
pointer safety into hardware.


There is little reason to believe that a safer language would necessarily be 
slower in practice. C has had 40 years of development to get to where it 
is now. With a fraction of the development of C, Scala code gets to 
within a factor of 2-3 of the equivalent C++ code, Go to within a factor 
of 5-7, and even Java to within a factor of 3-4. Okay, so Java has had 
oodles of optimization development too, so that's probably about as good 
as it will get. Imagine if newer languages like Go and Rust had even a 
quarter of the development effort as C and C++.



More information about the Python-list mailing list