The Next Big Language

[Emil Madsen]

So... When are you writing a book?
Emil Madsen

On 19 October 2010 13:49, bearophile <bearophileHUGS at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101019/3cd86601/attachment.html>