Andrej Mitrovic:

> Knowing the syntax and knowing how to use a language are two very
> different things. If you're a newbie you can learn the C syntax in a
> couple of weeks, but you would be very wrong to assume that you know
> e.g. "70%" of C, and that you could read any C project and understand
> it well.

To become a fluent Python programmer, that knows the Python style well and uses 
well the standard library, you need quite more than one month, probably many 
months (the more you exercise daily the faster you get there, but there's often 
a speed limit), you may even need two years.

The point I was trying to express is that from what I have seen people are able 
to learn to program Python (this means quite more than just the syntax) in 
*much* less time it takes to learn C++/D. And this has precise causes.


Regarding C, it's a bit like learning Scheme, you need only few months to learn 
C syntax even if you don't know a prior language. Then you may need two years 
to write some bigger C programs. And then you have just started learning C. 
Learning to program in C feels a bit like a ladder of Initiation Levels, even 
after many years you are able to find more advanced ways to use C.

Few years ago I have found the good "C tips" (http://users.bestweb.net/~ctips/ 
) that I have shown in this newsgroup too. They have taught me that there are 
ways to write very large C programs that work. Those tips show ways to tame C 
and turn it into a more reliable language. But they require very rigorous C 
programmers.

Despite the advanced contents of those tips, later I have found ways to write 
good C programs less hairy too (see the C source code of the Python deque in 
the collections module, written by the very good Raymond Hettinger, that avoids 
many of the complexities seen in those C tips, designed for far bigger 
programs: 
http://svn.python.org/view/*checkout*/python/trunk/Modules/_collectionsmodule.c?content-type=text%2Fplain
 ). Along the way you probably understand why the classic C Unix tools are so 
small.

Later I have found the very good "performance engineering" lectures 
(http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2009/lecture-notes/
 ), plus I have heavily performance-tuned some small C programs, all this has 
shown me new ways to program in C. And thanks to dlibs1 (and std.algorithm of 
Phobos2) I've seen that while those optimizations are sometimes useful, you 
usually want to use them only in a small percentage of the code of a program, 
all the other parts of a C program are better written in a higher level. And 
yes, you may write higher level style code even in C. Recently I have even 
written C code in D-style. And I guess you may write C code composed just of 
pure functions that manage immutable data (despite I've never seen such C 
programs), or you may write quite pure OOP programs in C (I have seen a bit of 
this kind of code), just like you may use good structured programming in 
assembly.

So now I presume there is one even higher level of C programming that I'm not 
seeing yet :-)

In the end C is a computationally complete language, you may use it to encode 
any algorithm, so probably there's no end in the number of abstractions or ways 
to write programs in C. Two hundred years from now Alien people coming from a 
far away star may use a C-style language to write code in ways we can't even 
think about today :-)

Bye,
bearophile

Reply via email to