The Next Big Language

[bearophile]

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