So... When are you writing a book? Emil Madsen On 19 October 2010 13:49, bearophile <bearophileh...@lycos.com> wrote:
> 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 > -- // Yours sincerely // Emil 'Skeen' Madsen