Experiences/guidance on teaching Python as a first programming language
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
>> Now, I wish to be absolutely clear. There are certain programming areas
>> where squeezing out every last iota of performance is important, and to
>> do so MAY REQUIRE MAKING SOME COMPROMISES ON CORRECTNESS OR SAFETY. I
>> 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.
> 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