hancock at anansispaceworks.com
Mon Aug 5 20:10:10 CEST 2002
S. Gonzi wrote:
> Max M wrote:
> > Kyle Babich wrote:
> >> I know I want to learn C,
> > Postpone this as long as possible ... Not because c is bad, but because
> > it is hard. You will have a lot more fun developing in Python as you
> > will se results much faster. Python will also teach you the "right" way
> > of writing software much faster. Which can be transfered to c when that
> > time comes.
> Have to beg differ. I once read a comment (I think it was in a German
> newsgroup) from a 42 old developer (who wanted just to become a hobby
> programmer on Linux) that he found it much more straightforward to
> program in C than in Python. Note he was at that time a beginner and
> searched for help a few weeks ago in that specific newsgroup whether he
> should learn C or Python or Perl or Pascal or ... He wrote that
> everything in C makes sense to him.
> I did not follow the comments in the following but the post surprised me
> that one finds C more easily to grasp than Python, especially when he is
> a novice in programming.
Actually this doesn't completely surprise me -- C is
much "closer to the metal". So if you think like the
metal does, it's easier. If you're coming to computers
from the hardware side ("I understand what a CPU is,
memory storage, etc."), even if only at the analytical
level, then C will probably seem much more sensible.
It's possible, but very hard to make Python work in
terms of setting bits and bytes, for example. Also,
dispite Python's admirably minimalist design (compared
to Perl), it still has a lot of syntax to think about
compared to C (C++ is a different story). Things
like functional programming, lists, and dictionaries,
are incredibly useful, but much more complex than
arrays and structures.
This is why I wouldn't dream of writing a hardware
driver in Python (aside from performance issues).
Assembly does this too, but is obfuscated by a lot of
individual differences between machines and very close
details -- C is just enough abstraction to make the
hardware make sense. It's important to realize that
this very experienced developer (whether hardware or
software) would've had much more to drawn on than a
Learning Python first, you can skip a lot of that
hardware knowledge, and start from conceptual stuff.
But the main issue is that C has no "guard rails", which
can be really frustrating (I used to have reboot
regularly on DOS machines -- I think Linux gives you
more defenses against that, but it can still make you
have to log out and back in or reset your X windows).
Those problems are rare to non-existent with any
"high level" language, including Python. Pointer code
can do that to you in a hurry, though.
My favorite thing about Python is that my code has
fewer bugs. This is undoubtedly a consequence of
Python's visually simpler syntax -- I don't have to
read character-by-character to make it right. I don't
find that Perl has this advantage -- I still have
to read it character by character and try everything
over and over again. That may be because I'm inexperienced
with it, though.
One of the things I often do is write a function or
module once, and then try to compile and run without
checking it -- the compiler often finds trivial bugs
faster than I would've by inspection, and it occasionally
works. If it works exactly right, I'll usually give
it a visual inspection anyway, but it's a real boost
to get a "perfect delivery" like that, even though it
doesn't happen much. With C, I get maybe one of those
a year. With Python, about once a week.
Think about what this means in an environment where
compiling and running cycles are expensive (e.g.
developing a web application).
It's been close to a year sense I've felt the need
to use C, though I'll be back to it again within the
next year, I'm sure. It depends on the project.
hancock at anansispaceworks.com
P.O. Box 60583
Pasadena, CA 91116-6583
More information about the Python-list