One other possible reason for the C predominance

One other possible reason for the C predominance

[Yannick Duchêne (Hibou57)]

Reading at some stuff, I've just learned somethings about C's story, which  
make me think this may be one other possible reason for the C  
predominance. If you read it carefully, you may notice the same story  
could possibly occurs with Ada in turn in the future.

In a short summary, it makes the assumption C was not so badly designed at  
first and was even an abstraction, which became more and more suited as  
the time was going. Obviously, this is not the case anymore (not as much  
well suited as it was), but the author witness it reached an hight level  
of suitability, when the Intel's i386 came into life… just notice that  
this architecture is still actual, just think about all of those Unices or  
Linux application still built to target the i386 (Debian still do  
nowadays). So this “language of the past” was a language of the future,  
and just became a language of the past, “recently”. Yes, I know, this is  
not an excuse for its flaws about typing and tasking, but this is still  
worth reading to get a picture, and to see how possibly Ada could have the  
same story in the future (unless virtual machines are going to shadow it  
and be the next bad answer… I'm really afraid of that in the mean time).

Read this :
http://www.faqs.org/docs/artu/ch04s03.html
The last part titled “Case Study: C Considered as Thin Glue”

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: One other possible reason for the C predominance

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> Read this :http://www.faqs.org/docs/artu/ch04s03.html
> The last part titled “Case Study: C Considered as Thin Glue”

So in essence, C survived and thrived because it provided a layer of
abstraction that was not locked to contemporary hardware.  Big deal.
Lisp, Pascal and Ada did and still do the same (better, actually).

I don't think that was the driving factor for the dominance of C.  The
driving factors were: (1) ease of implementation; (2) availability of
no-cost, open source compilers that came with UNIX; and (3) bad
judgment by programmers who used C outside its intended application
domain (i.e. programmed entire applications instead of low-level OS
kernels and utilities).

Lisp failed to thrive because it is not easy to implement well (it
needs garbage collection, generics, tail call optimization, a large
library, an efficient virtual machine, etc.) and Ada because it lacked
both ease of implementation and no-cost compilers.

Pascal had both ingredients but still lost to C because its standard
library was less versatile.  And because of its use of bounded-length
strings, perhaps.

--
Ludovic Brenta.

Re: One other possible reason for the C predominance

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Mar 2011 14:09:01 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> So in essence, C survived and thrived because it provided a layer of
> abstraction that was not locked to contemporary hardware.  Big deal.
> Lisp, Pascal and Ada did and still do the same (better, actually).
These ones was not evaluated as such, for reasons this part of the history  
does not explain.

The excerpt makes me think about something else. You may have noticed it  
says since C raised, many of the investigations in platforms and hardware  
designed stopped :

   “It is not a coincidence that the experimental era in computer
    architectures ended in the mid-1980s at the same time that C”
    [quoted from the above link]

So C, as language, became something to which architectures adapted,  
instead of the opposite. 1) This means C was finally never proved to be  
good at expressing these layers 2) This means C was finally a precursor of  
the virtual-machines + abstract virtual-machines-dedicated-languages fever  
we actually have.

There is a trouble with that : at runtime, you are most likely to have  
only one architecture, while you may have applications designed in  
multiple language at a time, running on one architecture.

C was not designed with that in mind, this was not on purpose, but this  
may had an effect helping to drive “the world” this way.

> I don't think that was the driving factor for the dominance of C.  The
> driving factors were: (1) ease of implementation; (2) availability of
> no-cost, open source compilers that came with UNIX; and (3) bad
> judgment by programmers who used C outside its intended application
> domain (i.e. programmed entire applications instead of low-level OS
> kernels and utilities).
The latter, about abuse, is still true (with scripted languages used out  
of their scope).

> Lisp failed to thrive because it is not easy to implement well (it
> needs garbage collection, generics, tail call optimization, a large
> library, an efficient virtual machine, etc.) and Ada because it lacked
> both ease of implementation and no-cost compilers.
Plausible

> Pascal had both ingredients but still lost to C because its standard
> library was less versatile.  And because of its use of bounded-length
> strings, perhaps.
Bounded string length could be solved with dedicated objects (for Pascal  
Object) or even procedural libraries. I believe this was due to its  
learning language reputation. And may be because it was too much clean and  
easy (remember these “real men program in C” and “Pascal is a language for  
babies”).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: One other possible reason for the C predominance

[Hoàng Đình Long]

On Mar 22, 5:36 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> If you read it carefully, you may notice the same story  
> could possibly occurs with Ada in turn in the future.

What do you mean by "the same story"? Did you mean "Ada as glue
layer"?

Re: One other possible reason for the C predominance

[Hoàng Đình Long]

I think this post will give some ideas about programming languages of
the future.

http://www.infoq.com/presentations/Future-of-Programming-Languages

One of the presenter said that there were many programming languages
out there but they are not concentrated enough on security. Another
one said we had many approaches towards concurrent programming but
none proved to be the best.

Re: One other possible reason for the C predominance

[Ludovic Brenta]

Yannick Duchêne wrote:
> So C, as language, became something to which architectures adapted,  
> instead of the opposite.

Not sure about that.  I think the hardware architectures became
simpler and more orthogonal simply because the cost of memory was
dropping, such that compactness of executable code became less and
less of an issue.  The trend continued with RISC.

> 1) This means C was finally never proved to be good at expressing these
> layers

In fact, C is bad because it assumes a uniform memory architecture and
a flat address space.  These assumptions were OK for a few decades but
nowadays, GPUs with dedicated memory are a common case of non-uniform
memory architectures; the Cell processor and the rise of massively
parallel supercomputers is another.  Ada has storage pools to
represent this kind of thing.

> 2) This means C was finally a precursor of the virtual-machines + abstract
> virtual-machines-dedicated-languages fever we actually have.

No, C was not a precursor; Lisp ("discovered" in 1954) was.  Lisp even
produced a hardware architecture optimized for running Lisp bytecode,
see http://en.wikipedia.org/wiki/Lisp_machine.

I don't think C was a precursor at anything, really.  It was, and
still is, a hack.

--
Ludovic Brenta.

Re: One other possible reason for the C predominance

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Mar 2011 15:59:16 +0100, Hoàng Đình Long <long.hdi@gmail.com> a  
écrit:
> I don't understand the "same story" you mentioned. Did you mean "Ada
> as a glue layer"?
I meant, just like C was promoted because at some time in the past, it  
appeared to match the architectures in use, may be Ada in the future,  
gonna be recognized for the same purpose (as C does not any more, since at  
least about 15 years). But as I also said in a previous message, I am  
afraid virtual machines and their languages running only on these virtual  
machines, will not help to start thinking again (as it seems “we” have  
stopped thinking). Moreover, virtual machines offers to much opportunities  
to replay again and again, the same errors all the time, each time on a  
new virtual machine. That's not good ? Oh, just create a new virtual  
machine. Oh, the language fails ? Don't bother, let's create a new virtual  
machine, the language fails again ? etc, and so on. This offers two points  
(both acting as an exit point for the other), which is perfect to draw a  
loop, and I am afraid we gonna be trapped in this loop.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: One other possible reason for the C predominance

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Mar 2011 16:12:23 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:

> Yannick Duchêne wrote:
>> So C, as language, became something to which architectures adapted,  
>> instead of the opposite.
>
> Not sure about that.  I think the hardware architectures became
> simpler and more orthogonal simply because the cost of memory was
> dropping, such that compactness of executable code became less and
> less of an issue.  The trend continued with RISC.

Yes, I abused the interpretation here, you're right.

> No, C was not a precursor; Lisp ("discovered" in 1954) was.  Lisp even
> produced a hardware architecture optimized for running Lisp bytecode,
> see http://en.wikipedia.org/wiki/Lisp_machine.
That was not exactly what I was attempting to say (this was related to my  
above erroneous interpretation).



-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: One other possible reason for the C predominance

[Keith Thompson]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
[...]
> In fact, C is bad because it assumes a uniform memory architecture and
> a flat address space.  These assumptions were OK for a few decades but
> nowadays, GPUs with dedicated memory are a common case of non-uniform
> memory architectures; the Cell processor and the rise of massively
> parallel supercomputers is another.  Ada has storage pools to
> represent this kind of thing.
[...]

No, C doesn't assume this.

C provides arithmetic on pointers.  If p is a pointer and i is an
integer, then you have:
    p + i -> p
    i + p -> p
    p - i -> p
    p - p -> i
(Note that the result is the number of pointed-to objects, not
the number of bytes.)

C also provides comparison operations on pointers; p0 < p1 means
that p0 points to a lower memory address than p1 does.

But all of these operations have undefined behavior if the two
pointers don't point into the same object (or, as a special case,
just past the end of the object.)  Since the behavior is undefined,
an implementation could even check for out-of-bounds accesses,
though most don't do so.

For C implementations on systems with a flat address space, all
this tends to work as you'd expect (and it makes it very easy to
shoot yourself in the foot by accidentally going outside the bounds
of the object you're working with).  But it's entirely possible to
implement C on a system where distinct objects exist in distinct
address spaces.  This is by deliberate design.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: One other possible reason for the C predominance

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>> In fact, C is bad because it assumes a uniform memory architecture and
>> a flat address space. ...

> No, C doesn't assume this.

Right.  Some C programmers assume it, either by accident or on purpose.
I don't remember K&R C well enough to know whether K and/or R assumed
it.  But the C standard does not assume it.

...
> But all of these operations have undefined behavior if the two
> pointers don't point into the same object (or, as a special case,
> just past the end of the object.)  Since the behavior is undefined,
> an implementation could even check for out-of-bounds accesses,
> though most don't do so.

A C impl could, but it's somewhere between difficult and impossible to
do it efficiently.

> For C implementations on systems with a flat address space, all
> this tends to work as you'd expect (and it makes it very easy to
> shoot yourself in the foot by accidentally going outside the bounds
> of the object you're working with).  But it's entirely possible to
> implement C on a system where distinct objects exist in distinct
> address spaces.

Well, sort of.  C programmers on 8086 found it necessary to sprinkle
their programs with "near" and "far" all over the place -- which means
those programs weren't C.

>... This is by deliberate design.

Deliberate design by whom?  K&R, or later C-standards committees?

- Bob