Re: [TUHS] History of popularity of C

Re: [TUHS] History of popularity of C

[Noel Chiappa]

    > From: Tyler Adams

    > C is so prolific and influential because it's so easy to write a C
    > compiler.

I'm not sure the implied corollary ('it's _not_ easy to write compilers for
other languages') is correct.

As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off
the shelf, and it reveals that the Algol 60 compiler discussed there (for the
KDF9), using lessons from the Algol compiler for the Electrologica X1, was
3600 words (roughly 3 instructions/word). So it was small.

Now, small is not necessarily equivalent to easy, but it was clearly not a
mountainous job. I imagine early BCPL, etc compilers were roughly similar.
The only language from that era which I can think of which was a slog,
compiler-wise, was PL/I.


I suspect the real reason for C's sucess was the nature of the language.
When I first saw it (ca. 1976), it struck me as a quantum improvement over
its contemporaries.

    Noel

Re: [TUHS] History of popularity of C

[Thomas Paulsen]

>I suspect the real reason for C's sucess was the nature of the language.
it has most of the elements of structured programming as known in the 70the/80ths, and - most important - it produces small and fast performing binaries like no other high level language. Furthermore its syntax is relatively close to the system, and systems calls are easily adoptable. Thus for me it still is and ever will be the first choice. 

Re: [TUHS] History of popularity of C

[Paul Winalski]

On 5/21/20, Thomas Paulsen <thomas.paulsen@firemail.de> wrote:
>>I suspect the real reason for C's sucess was the nature of the language.
> it has most of the elements of structured programming as known in the
> 70the/80ths, and - most important - it produces small and fast performing
> binaries like no other high level language.

Sorry, but I can't agree with that statement (like no other high-level
language).  C is a decent language for systems programming but so are
other languages such as BLISS.  C is a terrible language if you have
to throw arrays around (which is why Fortran still rules the roost in
HPTC).

C, Pascsal, and other modern Algol-ish languages have well-behaved
grammars and were designed to be easy to lex and parse.  Fortran and
COBOL were designed before Chomsky's work on formal grammars became
well known, and as a consequence are bears to parse.  Fortran has
context-sensitive lexical analysis, for example.  But nobody knew any
better back then.

-Paul W.

Re: [TUHS] History of popularity of C

[Thomas Paulsen]

>Sorry, but I can't agree with that statement (like no other high-level
>language).  C is a decent language for systems programming but so are
>other languages such as BLISS.  C is a terrible language if you have
>to throw arrays around (which is why Fortran still rules the roost in
>HPTC).

BLISS is known to a very small number of persons, thus irrelevant, and with regards to arrays, first they are rarely used in advanced programming preferring lists, maps, trees, etc.. second I never had problems with pointers.

Re: [TUHS] History of popularity of C

[Tom Ivar Helbekkmo via TUHS]

Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:

> I suspect the real reason for C's sucess was the nature of the language.
> When I first saw it (ca. 1976), it struck me as a quantum improvement over
> its contemporaries.

Paul Graham expressed it like this:

"It seems to me that there have been two really clean, consistent
models of programming so far: the C model and the Lisp model. These
two seem points of high ground, with swampy lowlands between them."

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] History of popularity of C

[Tyler Adams]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Awesome, looks like my theory was completely wrong. Here's what it looks
like to me, please correct me as needed.

C's popularity has 2 distinct phases.

1972-1987 Unix drove C. Writing a functional PCC for a particular
architecture was easy, but not unusually so compared to other languages at
the time.

1987- gcc made C uniquely free to compile, so people chose to write C
because it was free and already popular.

Perl also came out in 1987, and afaik that was always free, but C still
took off because there was so much room for multiple languages.

So, now Im curious about embedded systems. In my limited experience, every
"embedded system" I programmed for from 2002-2011 had C as its primary
language. After 2011, I stopped programming embedded systems, so I don't
know after that. Why was C so dominant in this space? Is it because adding
a backend to gcc was free, C was already well known, and C was sufficiently
performant?

Tyler


On Fri, May 22, 2020, 11:53 Tom Ivar Helbekkmo <tih@hamartun.priv.no> wrote:

> Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:
>
> > I suspect the real reason for C's sucess was the nature of the language.
> > When I first saw it (ca. 1976), it struck me as a quantum improvement
> over
> > its contemporaries.
>
> Paul Graham expressed it like this:
>
> "It seems to me that there have been two really clean, consistent
> models of programming so far: the C model and the Lisp model. These
> two seem points of high ground, with swampy lowlands between them."
>
> -tih
> --
> Most people who graduate with CS degrees don't understand the significance
> of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
>

[-- Attachment #2: Type: text/html, Size: 2459 bytes --]

Re: [TUHS] History of popularity of C

[arnold]

Tyler Adams <coppero1237@gmail.com> wrote:

> So, now Im curious about embedded systems. In my limited experience, every
> "embedded system" I programmed for from 2002-2011 had C as its primary
> language. After 2011, I stopped programming embedded systems, so I don't
> know after that. Why was C so dominant in this space?

First of all, because C is the (almost) perfect language for embedded
systems - tight code generated, language close to the metal, etc. etc.

> Is it because adding
> a backend to gcc was free, C was already well known, and C was sufficiently
> performant?

Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
in porting GCC to different processors used in embedded systems and
provided support.

Arnold

Re: [TUHS] History of popularity of C

[Tyler Adams]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Doesn't C++ also generate tight code and is fairly close to the metal?
Today C++ is the high performant language for game developers and HFT shops.

But, I never found it on any of these embedded systems, it was straight C.

Tyler

On Fri, May 22, 2020, 14:09 <arnold@skeeve.com> wrote:

> Tyler Adams <coppero1237@gmail.com> wrote:
>
> > So, now Im curious about embedded systems. In my limited experience,
> every
> > "embedded system" I programmed for from 2002-2011 had C as its primary
> > language. After 2011, I stopped programming embedded systems, so I don't
> > know after that. Why was C so dominant in this space?
>
> First of all, because C is the (almost) perfect language for embedded
> systems - tight code generated, language close to the metal, etc. etc.
>
> > Is it because adding
> > a backend to gcc was free, C was already well known, and C was
> sufficiently
> > performant?
>
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1738 bytes --]

Re: [TUHS] History of popularity of C

[John Gilmore]

Tyler Adams <coppero1237@gmail.com> wrote:
> Doesn't C++ also generate tight code and is fairly close to the metal?
> Today C++ is the high performant language for game developers and HFT shops.
> 
> But, I never found it on any of these embedded systems, it was straight C.

My take on this is that programmers who understand the underlying
hardware architecture can easily intuit the code that would result from
what they write in C.  There are only a few late features (e.g. struct
parameters, longjmp) that require complex code to be generated, or
function calls to occur where no function call was written by the
programmer.

Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
generated code to do immense amounts of unexpected work.  Think of
string compares, hash table types, object initializers, or arbitrary
amounts of jumping through tables of pointers to different kinds of
objects.  Automated memory allocation.  Garbage collection.

This is both a blessing and a curse.  In C it was quite predictable how
well or badly typical sections of your code would perform.  If the
performance was bad, it was YOUR fault!  But at least YOU could fix it,
without learning to hack a compiler instead of your own application.

(I once found Berkeley SPICE code doing string compares in a triply
nested loop, just to look up the names of the signals.  In C.  Making
changes to a large state machine going into a custom chip was taking the
Sun hardware engineers multiple hours per change.  I spent weeks finding
the source code (Sun's tools group was dysfunctional; I got it from
UCB).  In half a day of profiling it and fixing it to cache the
result of the first string lookup on each signal name, four hour
rebuilds went down to under a minute.  A second day of profiling
and cacheing, just for fun, took it down to 10 seconds.)

	John

Re: [TUHS] History of popularity of C

[Toby Thain]

On 2020-05-22 2:40 PM, John Gilmore wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
>> Doesn't C++ also generate tight code and is fairly close to the metal?
>> Today C++ is the high performant language for game developers and HFT shops.
>>
>> But, I never found it on any of these embedded systems, it was straight C.
> 
> My take on this is that programmers who understand the underlying
> hardware architecture can easily intuit the code that would result from
> what they write in C.  There are only a few late features (e.g. struct

A short time playing with Godbolt should challenge that view :)

https://godbolt.org/


> parameters, longjmp) that require complex code to be generated, or
> function calls to occur where no function call was written by the
> programmer.
> 
> Whereas ...
> 
> 	John
> 

Re: [TUHS] History of popularity of C

[Larry McVoy]

On Fri, May 22, 2020 at 03:01:40PM -0400, Toby Thain wrote:
> On 2020-05-22 2:40 PM, John Gilmore wrote:
> > Tyler Adams <coppero1237@gmail.com> wrote:
> >> Doesn't C++ also generate tight code and is fairly close to the metal?
> >> Today C++ is the high performant language for game developers and HFT shops.
> >>
> >> But, I never found it on any of these embedded systems, it was straight C.
> > 
> > My take on this is that programmers who understand the underlying
> > hardware architecture can easily intuit the code that would result from
> > what they write in C.  There are only a few late features (e.g. struct
> 
> A short time playing with Godbolt should challenge that view :)
> 
> https://godbolt.org/
> 
> 
> > parameters, longjmp) that require complex code to be generated, or
> > function calls to occur where no function call was written by the
> > programmer.

What John didn't mention, he just assumes people know and everyone is
the same, is that he is an excellent C programmer, I could fix bugs
in his code.

You can always fine someone who will make a mess of any language.
That's not the point.  

Assume that you have decent programmers, you will be able to understand
and fix their C code.  If you have really good C programmers, like
my company did, you can start to predict what the bottom half of the
function looks like by reading the top half.  We wrote very stylized C,
were not afraid of gotos when used wisely.

Re: [TUHS] History of popularity of C

[Larry McVoy]

On Fri, May 22, 2020 at 11:40:11AM -0700, John Gilmore wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
> > Doesn't C++ also generate tight code and is fairly close to the metal?
> > Today C++ is the high performant language for game developers and HFT shops.
> > 
> > But, I never found it on any of these embedded systems, it was straight C.
> 
> My take on this is that programmers who understand the underlying
> hardware architecture can easily intuit the code that would result from
> what they write in C.  There are only a few late features (e.g. struct
> parameters, longjmp) that require complex code to be generated, or
> function calls to occur where no function call was written by the
> programmer.

Amen.

> Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
> generated code to do immense amounts of unexpected work.  Think of
> string compares, hash table types, object initializers, or arbitrary
> amounts of jumping through tables of pointers to different kinds of
> objects.  Automated memory allocation.  Garbage collection.

Double amen.

> This is both a blessing and a curse.  In C it was quite predictable how
> well or badly typical sections of your code would perform.  If the
> performance was bad, it was YOUR fault!  But at least YOU could fix it,
> without learning to hack a compiler instead of your own application.

Triple amen.

> (I once found Berkeley SPICE code doing string compares in a triply
> nested loop, just to look up the names of the signals.  In C.  Making
> changes to a large state machine going into a custom chip was taking the
> Sun hardware engineers multiple hours per change.  I spent weeks finding
> the source code (Sun's tools group was dysfunctional; I got it from
> UCB).  In half a day of profiling it and fixing it to cache the
> result of the first string lookup on each signal name, four hour
> rebuilds went down to under a minute.  A second day of profiling
> and cacheing, just for fun, took it down to 10 seconds.)

Gazillion amens (I especially loved the jab at Sun's tools group, I
wrote the SCM that Sun used for Solaris initially.  They tried to get
me to join the tools group to make my stuff "official" - it worked just
fine being "unofficial".  I took a look at the people in the tools group,
no offense, but it was a big step down from working with people like srk
and gingell and shannon, not to mention that all of my peers were smart.
Tools group, just say no.)

Re: [TUHS] History of popularity of C

[Michael Kjörling]

On 22 May 2020 11:40 -0700, from gnu@toad.com (John Gilmore):
> Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
> generated code to do immense amounts of unexpected work.  Think of
> string compares, hash table types, object initializers, or arbitrary
> amounts of jumping through tables of pointers to different kinds of
> objects.  Automated memory allocation.  Garbage collection.

What you wrote is pretty much my take on the subject as well.

However, part of me wants to say "let's not compare apples to
airplanes just because both start with 'a' and one can typically be
placed within the other".

C++ adds a ton of features on top of C, never mind early C, though for
the features that at least earlier C has (I'm honestly not sure about
the newer additions), C++ has very similar or downright identical
syntax compared to C.

As long as you stay with the basic C feature set, I strongly suspect
that most programmers who can follow along in the C to assembler to
machine code compilation process, can do much the same thing with C++.

It's when you start piling all the extras on top of it that things get
hairy from a code generation perspective.

Vectors? Function overloading? Exceptions? RAII? Try predicting the
execution order of destructors during exception handling for classes
with multiple inheritance where multiple inherited-from classes define
destructors. Anything else? :-)

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [TUHS] History of popularity of C

[Toby Thain]

On 2020-05-22 7:09 AM, arnold@skeeve.com wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
> 
>> So, now Im curious about embedded systems. In my limited experience, every
>> "embedded system" I programmed for from 2002-2011 had C as its primary
>> language. After 2011, I stopped programming embedded systems, so I don't
>> know after that. Why was C so dominant in this space?
> 
> First of all, because C is the (almost) perfect language for embedded
> systems - tight code generated, language close to the metal, etc. etc.

To my recollection, in 1985 C wasn't firstly considered an embedded
language; it was considered an applications language (so was assembly,
but we could say that was tapering off).

I believe the explosion in popularity was due to that lesson from Unix,
that you could have a single portable language for both "system" code
and applications code, with a modern looking syntax, that could be self
hosted and compiled to reasonably efficient machine code.

All those tradeoffs and definitions are very different 40 years later,
of course. (And C was far from the first or only language that met those
criteria before 1975. It just happened to take off.)

> 
>> Is it because adding
>> a backend to gcc was free, C was already well known, and C was sufficiently
>> performant?
> 
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.

Having to get a paid consultant doesn't exactly argue for the idea that
C compilers were "easy" - plus it's almost a decade after the period of
high growth. So this doesn't seem strong support for the thesis quoted
by OP.

--Toby

> 
> Arnold
> 

Re: [TUHS] History of popularity of C (GCC/Cygnus)

[John Gilmore]

Tyler Adams <coppero1237@gmail.com> wrote:
> > Is it because adding
> > a backend to gcc was free, C was already well known, and C was sufficiently
> > performant?

arnold@skeeve.com wrote:
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.

First things first.  When figuring out what happened and what became
popular, it's important to look at where money was flowing.  Economics
will tell you things about systems that you can't learn any other way.

Second, until the embedded market included 32-bit processors, gcc was
unknown in it.  32-bit was way less than 1% of the embedded market; only
in multi-thousand dollar things like laser printers (Adobe/Apple
LaserWriter) and network switches (3Com/Cisco/etc).  Cygnus ended up
with lots of those companies as support customers, because they were
sick of porting their code through a different compiler for each new
generation of hardware platforms.  But we had zero visibility into the
vast majority of the embedded market.  We went there because even our
tiny niche of it was huge, many times the size of the market for native
compilers, and with much more diversity of customers.

Early on, GCC had the slight advantage that because it was free (as in
both beer and speech) and had an email community of maintainers, many
people had started ports to different architectures.  Only a few of
those were production-quality, but they each offered at least a starting
point, and attracted interested users who might pay us to make them
real.

Cygnus was able to deliver production compilers for each new
architecture for significantly less than the other companies building
compilers for embedded systems.  I think that had more to do with our
pricing strategy than the actual cost of modifying the compiler.  Our
main competitors were half a dozen small, fat, lazy companies who
charged $10,000 PER SEAT for cross-compilers and charged the chipmaker
$1,000,000 and frequently more, to do a port to their latest chip.
Cygnus charged chipmakers $500K for a brand new architecture, and $0 per
seat, which caused us to eat our competitors' lunch over our first 3 to
5 years.  Then we hired someone who knew more about pricing, and raised
our own port price to a larger fraction of what the market would bear,
to get better margins while still winning deals.

We built the first 64-bit ports of GCC and the tools, for the SPARC when
SPARC-64 was still secret, and later for other architectures.  (Sun's
hardware diagnostics group funded our work.  They needed to be able to
compile their chip and system tests, a full year before Sun's compiler
group could deliver 64-bit compilers for customers.)

A lot of what got done to make GCC a standard, production worthy
compiler had little to do with the code generation.  For example, many
customers really wanted cross-compilers hosted on DOS and Windows, as
well as on various UNIX machines, so we ended up hiring the genius who
created djgpp, DJ Delorie, and making THAT into a commercial quality
supported product.  (We also hired the guy who made GCC run in the old
MacOS development environment (Stan Shebs) and one of the senior
developers and distributors for free Amiga applications (Fred Fish).)
We had to vastly improve the testing infrastructure for the compiler and
tools.  We designed and built DejaGnu (Rob Savoye's work), and with each
bug report, we added to a growingly serious free C and C++ compiler test
suite.  We automated enough of our build process that we could compare
the code produced by different host systems for the same target
platform.  (The "reproducible builds" teams are now trying to do that
for the whole Linux distribution code base.)  DejaGnu actually ran our
test suite on multiple target platforms with different target
architectures, downloading the binaries over serial ports and jumping to
them, and compared the tests' output so we could fix any discrepancies
that were target-dependent.  We hired full-time writers (initially
Roland Pesch, who had been a serious programmer earlier in life) to
write real manuals and other documentation.  We wrote an email-based bug
tracking system (PRMS), and the first working over-the-Internet version
control system (remote cvs).  Our customers all used different object
file formats, so we wrote new code for format independence (the BFD
library) in the assembler, linker, size, nm and ar and other tools
(e.g. we created objdump and objcopy).  Ultimately Steve Chamberlain
wrote us and GNU a brand-new linker which had the flexibility needed for
building embedded system binaries and putting code and data wherever the
hardware needed it to go.

We learned how to hire and manage remote employees, which meant we were
able to hire talented gcc and tools hackers from around the country and
the world, who jumped at the chance to turn their beloved hobby into a
full-time paying gig.  We started our own ISP in order to get ourselves
good, cheap commercial quality Internet access, and so we could teach
our remote employees how to buy and install solid 56kbit/sec Frame Relay
connections rather than flaky dialup access.

And because we didn't control the master source code for gcc, one of our
senior compiler hackers, Jim Wilson, spent a huge fraction of his time
merging our changes upstream into FSF GCC, and merging their changes
downstream into our product, keeping the ecosystem in sync.  We handled
that overhead for significant other tools by taking up the whole work of
maintenance and release engineering -- for example, I became FSF's
maintainer for gdb.  I would make an FSF GDB release two weeks before
Cygnus would make its own integrated toolchain releases.  If bug reports
didn't start streaming in within days from the free software community,
we knew we had made a solid release; and we had time to patch anything
that turned up, before our customers got it from us on cartridge tapes.

It wasn't just a compiler, it was a whole ecosystem that had to be built
or improved.  About half of our employees were software engineers, so by
the time our revenues grew from <$1M/year to $25M a year, we were
spending about $12M every year improving the free software ecosystem.
And because we avoided venture capital for six years, and shared the
stock ownership widely among the employees, when we got lucky after 10
years and were acquired by the second free software company to go public
(the first was VA Linux, the second Red Hat), all those hackers became
millionaires.  A case of doing well by doing good.

	John
	

Re: [TUHS] History of popularity of C (GCC/Cygnus)

[Thomas Paulsen]

>Early on, GCC had the slight advantage that because it was free (as in
>both beer and speech) and had an email community of maintainers
I remember that we started moving to gcc, gmake, etc,, because these tools 
performed simply spoken better than the native SNI ones.

Re: [TUHS] History of popularity of C

[A. P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Fri, May 22, 2020, 5:52 AM Tyler Adams <coppero1237@gmail.com> wrote:
<snip>

> So, now Im curious about embedded systems. In my limited experience, every
> "embedded system" I programmed for from 2002-2011 had C as its primary
> language. After 2011, I stopped programming embedded systems, so I don't
> know after that. Why was C so dominant in this space? Is it because adding
> a backend to gcc was free, C was already well known, and C was sufficiently
> performant?
>

I don't know how much gcc contributed to the success of C in the embedded
space. Microcontrollers are often programmed in assembly. They have memory
and speed constraints, much like the PDPs where C began. I think it goes
back to what Larry said about C being so close to the metal.

>
>

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]