Experiences/guidance on teaching Python as a first programminglanguage

[Neil Cerutti]

Very good question! I don't have an answer. There are a few
"maybe-answers", but they mostly come down to "programmer
didn't know of a viable alternative".

I believe it was Andrew Plotkin (glk, Glulxe, lots of other
stuff) who said that writing good C requires something like
brain-damage. Once you have acquired the brain-damage, writing C
code is no problem; in fact, it feels darn good.

And another thing: How many other languages have their very own
calling convention?

 

[Chris Angelico]

And another thing: How many other languages have their very own
calling convention?

Pascal does (sometimes called the Win32 convention).

ChrisA

 

[Gregory Ewing]

In fact, thinking of it, a really good language should imho *require*
verbosity (how about a *minimum* length - or maybe even a
dictionary-based sanity check - for identifiers?), since that already
keeps all those lazy morons away who think that "shortcuts are cool".

No, that wouldn't be a really good language, that
would be a language designed by someone with a
very shallow understanding of what makes programs
understandable.

A piece of code such as

for (i = 0; i < numThings; i++)
total += things;

is NOT improved by rewriting it as

for (theLoopIndex = 0; theLoopIndex < numThings; theLoopIndex++)
total[theLoopIndex] += things[theLoopIndex];

Quite the reverse, IMO.

 

[Chris Angelico]

A piece of code such as

for (i = 0; i < numThings; i++)
total += things;

is NOT improved by rewriting it as

for (theLoopIndex = 0; theLoopIndex < numThings; theLoopIndex++)
total[theLoopIndex] += things[theLoopIndex];

Quite the reverse, IMO.

Wholeheartedly agreed. The only improvement I would make would be to
declare i in the if block (valid in C++ and some of the more recent C
standards), to emphasize the locality of the variable.

ChrisA

 

[Roy Smith]

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?

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.

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

 

[Steven D'Aprano]

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



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
mistake.

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.

http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions


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++.

http://readwrite.com/2011/06/06/cpp-go-java-scala-performance-benchmark

 

[Dennis Lee Bieber]

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
mistake.

I wonder how BLISS falls into that... Have to read the rest of
http://en.wikipedia.org/wiki/BLISS (while I had 22 years on VMS, it was
mostly F77, a touch of F90, C, Pascal, and some DCL; but never used BLISS)

 

[Ned Batchelder]

I wonder how BLISS falls into that... Have to read the rest of
http://en.wikipedia.org/wiki/BLISS (while I had 22 years on VMS, it was
mostly F77, a touch of F90, C, Pascal, and some DCL; but never used BLISS)

Bliss is even lower-level than C. It made the too-consistent choice of
having names mean the same thing on the left-hand side of an assignment
as on the right-hand side. A name meant the address of a variable, so
to access the value of a variable, you had to dereference it with the
dot operator, much like the unary asterisk in C.

C: a = b
Bliss: a = .b

C: a = a + 1
Bliss: a = .a + 1

C: a = *b
Bliss: a = ..b

C: a = &b
Bliss: a = b

It was far too common to forget the dots...

 

[Steven D'Aprano]

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?

Apparently Facebook are now working with it:

http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it

 

[David Combs]

It's not just the abysmally appalling, hideously horrifying syntax. At
about everything about C is just *not* "made for human beings" imho.

It's just an un-language that gets at about everything wrong. Sort of
like Microsoft's products.

Sincerely,

Wolfgang

I don't see how you could create a better high-level LOW-LEVEL
language.

And that pointer "*" syntax is really ingenious. (After
all, the guys who created it and those who first used
it (at Bell Labs) WERE all geniuses!)

David

 

[David Combs]

I can't think of a reference, but I to recall that
bugs-per-line-of-code is nearly constant; it is not language
dependent. So, unscientifically, the more work you can get done
in a line of code, then the fewer bugs you'll have per amount of
work done.

Makes no sense to me.

I can't imagine that errors per 100 lines is anywhere
near as high with a language that has garbage collection
and type checking as with one that has neither.

David